Merchant payment services: PSPs, gateways and MCCs

The three merchant-side layers

For a merchant to let customers pay by card, three layers of infrastructure sit behind the scenes. They're often treated as one thing, but their responsibilities are clearly separated:

In day-to-day operations merchants usually deal only with the PSP layer, but the money responsibility sits with the acquirer layer.

These three layers may be provided by the same company or by different ones: which is why different people give different answers about the same merchant problem. The previous page, Payment participants: issuers, acquirers and card networks, covered the four-party model; here we're looking at the merchant-side breakdown.

MID: the merchant's ID on the acquiring side

The MID (Merchant ID) is the identifier the acquirer assigns to a merchant. It appears on statements, refund records, and dispute materials, and its purpose is to show “which of the merchant's collection channels is receiving this payment.”

• A single merchant can hold multiple MIDs: different stores, brands, currencies, or business lines each get their own MID;
• The same MID may also correspond to multiple terminals or online entry points;
• That “merchant name + a string of numbers” you see on your statement: the string is most likely the MID or an identifier related to it;
• When handling disputes and refunds, the MID is the key to locating which collection line a transaction belongs to.

For cardholders, the practical value of the MID is claiming transactions: when a charge you don't recognize appears on your statement, the merchant name and MID help you tell whether it's another business line of the same merchant or a completely unknown party. For where that string of text on your statement comes from, see Account verification, zero-amount authorizations and billing descriptors.

MCC: what this merchant is selling

The MCC (Merchant Category Code) is a 4-digit number assigned by the acquirer when the merchant is onboarded, based on its primary line of business. It isn't a label the merchant fills in itself: it's an onboarding configuration:

The full list is long and gets updated with network rules; only the categories most relevant to online subscriptions, software, and advertising.

MCC allocation rules and the exact assignment of categories are maintained by the card networks. For authoritative definitions, refer to Visa's merchant data standards manual: it also specifies how data elements must be recorded when merchants onboard.

The MCC affects your card in return

This is the part card users should care about most. The MCC isn't just something on the merchant's side: at the moment of the transaction it's sent to the issuer side and feeds into three kinds of decisions:

• Interchange pricing: different MCCs map to different interchange tiers, directly affecting the merchant's cost of acceptance;
• Risk-control rules: the issuer side and the card networks set different monitoring and restrictions by MCC;
• Acceptance restrictions: some cards (including certain prepaid and commercial cards) carry MCC-level allowlists or blocklists, and those cards are declined outright on restricted MCCs.

The third point explains that recurring puzzle: the same card works at merchant A but is declined outright at merchant B: it isn't a card problem or a merchant problem, but a restriction on the combination of this card and this MCC. Such restrictions usually surface at binding or the first transaction, not at the charging stage.

So the real answer to “which card suits which scenario” is to see which tier the merchant's MCC falls into: software and information services (e.g., 5734 / 7372) and advertising services (e.g., 7311) are the most common categories for online spending and the scenarios where prepaid virtual cards are used most; while categories with an in-person character, like dining, lodging, and transport, have different requirements on card form factor.

What happens when the codes don't match

If a merchant's MCC doesn't match what it actually sells (a mismatch), the consequences fall on the merchant: but the symptoms land on consumers:

The last row is what subscription users run into most: when a merchant changes its business or acquiring channel, the charge failure rate suddenly rises.

Merchant-side codes, in turn, decide how to pick a card

Putting the merchant-side code knowledge to use, card selection and troubleshooting follow this order:

1. First see what category the merchant belongs to: software, advertising, subscription, or retail. This step determines the BIN and card type to choose next;
2. Then confirm whether your card has acceptance restrictions in that category: prepaid and commercial cards commonly have MCC-level restrictions: asking the issuer gives the most accurate answer;
3. Keep a buffer beyond the recurring amount: a prepaid card's available balance is exactly the money you loaded, so subscription scenarios need more than one billing cycle's worth: see the pricing page for the current terms;
4. When a charge fails, first tell whether it's a category restriction or insufficient balance: the two have different decline codes and completely different fixes.

Our cards are complete on the element side: card number, expiry date, security code, and the matching billing address: all four present; the BINs cover the US, Hong Kong, Japan, Singapore, and Europe, on the Visa and Mastercard networks. The boundary should be stated plainly: we can't lift acceptance restrictions that a merchant sets by category or payment method, and we don't promise any merchant will accept our cards. What we're responsible for is on the card side: complete elements, selectable BINs, and a balance that's entirely under your control; the merchant-side decisions aren't part of it.

Check the merchant category before picking a card: once you've confirmed the MCC category and acceptance stance of the target merchant, choose a card type, and issue one when needed.

FAQ

Further reading