MCC 5967 tells a Visa issuer that the merchant sells adult content. In Mastercard's latest public code booklet, dated April 2024, the same four digits still mean inbound telemarketing. Visa renamed the code between its April 2024 and April 2025 manuals, and this month it moved escort services into it too.
The merchant category code rides on every card authorisation. It sets US interchange, decides whether a UK credit card prices the payment as a cash advance and whether a bank's gambling block fires, and can leave an acquirer owing Visa USD 100,000 a month. The pages ranking for "merchant category code" are code lists and glossaries. Most get wrong who assigns the code, and none maps it to the API fields that carry it. Rules here were checked against Visa's Merchant Data Standards Manual (October 2026), the Visa Core Rules (18 April 2026) and PSP OpenAPI specs on 28 October 2026.
What Is a Merchant Category Code (MCC)?
An MCC is a four-digit number that classifies a merchant outlet by what it mainly sells: 5411 for grocery stores, 5812 for restaurants, 4511 for airlines. It travels with every card transaction. In the authorisation request it sits in ISO 8583 data element 18 (Merchant Type). In Mastercard's clearing file it goes in DE 26 (Card Acceptor Business Code), and an invalid value gets the presentment rejected with error 0531. The ISO 20022 card messages carry it as MrchntCtgyCd in cain.001, typed ISO18245MerchantCategoryCode with the pattern [0-9]{4}.
Of the few merchant fields an issuer sees on an authorisation, the MCC is the only one built for software to reason about. Fraud models, spend controls and rewards engines all lean on it.
Who Assigns a Merchant Category Code?
The acquirer. Not the merchant, not the card issuer and not the scheme. Visa Core Rules section 1.5.1.11 says an acquirer "must assign to a Merchant Outlet the MCC that most accurately describes its business". Mastercard Rules 5.8.1 requires the code to reflect the primary business and gives Mastercard the final word in a dispute.
Public explanations drift here, including from banks. Nationwide's gambling-support page says gambling companies assign their own codes. A Financial Ombudsman decision describes the code as applied by the merchant. Santander's cashback terms say Mastercard assigns them. What actually happens: the merchant describes its business at onboarding, and the acquirer, or a payment facilitator acting for it, picks the code and answers for it.
Read the full article on tomcn.uk →
About the Author
I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.
Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.
Top comments (1)
The 5967 example is a good pick because MCC drift between the two networks is a live operational problem, not documentation trivia. I have seen authorizations priced as cash advances on one network and standard e-commerce on the other purely from MCC mismatches, and it only surfaces later as chargebacks nobody can explain. One thing worth adding for anyone building on this: the same merchant can carry different MCCs per MID, so matching on a single code in reconciliation logic breaks the moment an acquirer re-registers a location. Reading the right network's version of the table matters as much as parsing the field.