Restricted Card Processing: How it Works in Practice

The Role of Merchant Category Codes

Every merchant that accepts card payments is assigned a four-digit Merchant Category Code (MCC) by the card networks. MCCs classify the type of business — pharmacies, transit operators, gyms, dental offices, fuel retailers, restaurants, and hundreds more. This classification is often the first filter in any restricted card authorization flow.

Program administrators configure how MCCs behave within their card program. The three primary configurations are:

• Allowlists define the MCCs where funds can be spent. A card tied to a transit benefit, for example, might only approve transactions at merchants coded as transit and commuter-related. Any other MCC results in a decline.
• Blocklists define MCCs that are always declined, regardless of other rules. A wellness stipend program might block MCCs associated with tobacco retailers, casinos, or liquor stores since these categories are outside program intent.
• Program-level rules allow different MCC sets to apply to different spending purposes on the same card. A multi-purse card might permit a commuter MCC set for one account balance and a medical MCC set for another, selecting the correct purse based on which set applies to the transaction.

MCCs are necessary but not always sufficient. A large-format retailer. For example, a large retailer may carry a general merchandise MCC that doesn’t reflect whether a specific purchase involves an eligible item. That limitation requires a second layer of control.

Merchant-Level Overrides and Exceptions

MCC-level controls operate on merchant type. Merchant-level overrides operate on specific merchants or terminal configurations. This layer allows program administrators to refine decisions that MCC logic alone would either over-restrict or under-restrict.

Practical examples include:

• Approving only the pharmacy or vision center terminals within a broader general merchandise retailer
• Blocking a merchant globally for most purses but permitting access for a specific program account
• Enabling specialty providers — such as an acupuncture clinic or a specialty lab — whose assigned MCC falls outside the standard allowlist but who qualify under program rules

This granularity reduces false declines or cases where a valid transaction would otherwise be rejected because MCC logic doesn’t capture the specific use.

Item-Level Eligibility: IIAS Validation

Where MCC controls classify merchants, item-level eligibility controls classify purchases within mixed-product merchants. The Inventory Information Approval System (IIAS) is the industry-standard mechanism for this.

IIAS is used by major retailers that sell both eligible and ineligible items. At point of sale, the retailer’s system identifies which items in the transaction qualify as eligible medical expenses under IRS §213(d). The authorization request distinguishes eligible from non-eligible amounts, enabling the processor to approve only the eligible portion against the appropriate account.

This enables two important outcomes. First, it allows split-tender logic: the eligible portion is charged to the benefits account while the remainder routes to another form of payment. Second, it reduces the need for post-transaction substantiation — the documentation process that IRS-regulated benefits programs would otherwise require to verify that FSA, HSA, or HRA funds were used appropriately.

IIAS is not optional for mixed merchants in regulated benefits programs. It is the compliance mechanism that makes accurate authorization possible where MCC classification cannot.

Spending Limits and Balance Controls

Beyond merchant and category controls, restricted card programs enforce financial boundaries at the transaction and account level.

The authorization layer evaluates several conditions before approving any transaction:

• Real-time balance verification ensures the account has sufficient funds at the moment of authorization, not at the end of the day. In multi-purse programs, this check occurs per eligible purse, in the order of configured priority.
• Spending limits can be set at the transaction level (a single purchase cap or percent of transaction), the daily level, or within a defined plan period. Additionally, program administrators define whether partial approvals are supported — allowing the eligible amount to be approved even when it is less than the total transaction.
• Temporal eligibility enforces plan-year rules: whether a transaction date falls within an eligible coverage period, whether grace periods apply, or whether rollover funds remain available. These constraints are common in FSA and commuter benefit programs where eligibility is tied to enrollment dates and tax-year boundaries.
• Purse priority sequencing governs which account is drawn against when multiple purses are eligible. Administrators configure the order explicitly — for example, use FSA funds before HRA, or apply a wellness stipend only as a fallback when HSA funds are not applicable. This sequencing must be deterministic, auditable, and aligned with plan design.

Real-Time Authorization Logic

The authorization decision in a restricted card program follows a defined sequence, executed within the response time required by card network standards, typically under two seconds.

1. The merchant sends a transaction request that includes the MCC, merchant ID, and requested amount.
2. The processor evaluates whether the MCC is permitted under the program’s configured rules.
3. If merchant-level overrides apply, they are resolved at this step.
4. Where item-level eligibility is required, IIAS data from the merchant’s POS system is incorporated.
5. The system identifies which purses are eligible for this transaction.
6. Balances and spending limits are checked across those purses.
7. If multiple purses qualify, purse priority rules determine the draw order.
8. The system returns one of three outcomes: approve, partially approve (if configured), or decline with a reason code.

The ledger updates in real time upon approval. Pending holds are placed immediately to prevent overspending through concurrent transactions. When the transaction clears, the ledger reflects the finalized amount, and any adjustment from a reversal or return is applied to the originating purse.