Merchant Category Codes: Classification, Acquiring and Merchant Responsibilities

An MCC describes a category. A merchant ID identifies a processing relationship or account within a provider’s system. A statement descriptor helps the cardholder recognise the charge. An incorporation activity code or a tax registration describes another administrative context. Keep these records together, but do not treat one as proof that the others are correct.

This distinction helps with support. A customer can recognise the statement name while the business classification is outdated. A correctly classified business can still have an unfamiliar descriptor and customer complaints. Changing the trading name alone does not tell the provider that a new product, seller relationship or payment flow has been introduced.

Create a route register with the legal entity, trading name, website, provider account reference, payment method, confirmed MCC and date checked. Record the source of confirmation. For multiple providers, maintain a separate entry for each relationship instead of assuming one configuration applies everywhere.

When a report contains a field you do not understand, ask the provider for its definition. A gateway’s internal industry label, a network category and a reporting group may look similar without representing the same data. Resolve that difference before using the field to explain a decline, a fee or a change to a merchant account.

Describe the item or service, customer, sales channel, fulfilment and merchant role in plain language. Include representative product pages and invoices. For a platform, explain whether it sells its own product, enables another seller or collects money for someone else. Subscription billing describes how payment repeats; it does not, by itself, explain what is being sold.

Use actual revenue or sales information for an established business and clearly labelled forecasts for a new activity. Ask the provider what period and measure it needs. Do not present turnover, net commission, customer deposits and transaction volume as interchangeable figures. The classification conversation becomes unreliable if the parties are describing different quantities.

Stripe’s Connect documentation supplies one implementation example: Stripe normally assigns connected-account MCCs automatically, and the industry information or website can inform the result. Its documentation says each Stripe account has one MCC and describes circumstances in which a controlling platform can set a code. Stripe can review an inaccurate assignment and change it. [2] Those are Stripe account rules, not proof that all providers use the same account structure.

Keep the declaration and the response. If a code appears to fit only part of the operation, explain the rest before integration. A provider can then address the classification and any separate eligibility question using the same facts.

Suppose a company records €350,000 of annual sales: €210,000 from software, €87,500 from implementation work and €52,500 from equipment. The shares are 60%, 25% and 15%. This is useful evidence about the business mix, but it does not assign the merchant an MCC by itself.

Now suppose next year’s forecast is €130,000 for software, €200,000 for implementation and €90,000 for equipment, totalling €420,000. Implementation becomes the largest forecast line at about 47.6%, even though it is less than half the total. That change should prompt a provider discussion; it does not establish a new classification or turn a forecast into processing history.

Visa’s manual has rules for multiple business lines and outlets, including circumstances requiring multiple MCCs. [1] Ask the acquirer how those rules apply rather than assuming that the largest sales line can always absorb every other transaction. A provider’s single-MCC account design may require a different configuration to represent activities correctly.

The table below keeps the calculation separate from the decision. Its purpose is to reveal a changing operation early. It cannot determine whether the provider accepts an activity, which network rule applies, or whether a business must use separate accounts. Those answers need the provider’s assessment of the complete arrangement.

Classification can matter beyond the onboarding form. Stripe notes that MCCs are used in interchange calculations, authorisation and fraud prevention. [2] That makes accurate data worth checking, but it does not let a merchant calculate its complete processing cost or diagnose an issuer decline from the MCC alone.

Adyen’s authorisation-adjustment documentation offers a concrete technical example. Card-scheme eligibility for adjusting an authorisation depends on MCC, and the supported classifications differ by scheme. It also shows how to view the MCC by payment method in the live merchant account. [3] A merchant planning an estimated amount followed by an adjustment should therefore confirm the actual scheme, method, account configuration and feature support before building the flow.

Treat a documentation example as a question to test with the contracted provider. Obtain the supported payment states, request fields and failure behaviour for the intended use case. Keep a record of what was tested and which configuration was used. A feature working on one account is not evidence that it is available on every route.

For pricing, request a complete quote or reconciliation explanation rather than guessing a saving from a code list. Transaction channel, card mix, country, currency, provider charges and other conditions still need to be understood. An inaccurate classification is a problem to correct, not a cost-optimisation strategy.

If the provider’s recorded category seems wrong, send a concise correction request. Include the current MCC, relevant account and website, the actual activity, supporting pages or invoices, and the change you want reviewed. Ask the provider to confirm its decision and whether any other configuration or agreement needs updating.

Do not change the business description merely to obtain a less restricted-looking code. The product, customer promise, funds flow and customer markets remain facts the provider needs to assess. A generic software description cannot answer questions about transactions that fund another activity.

Keep classification separate from legal permission and underwriting. An accurate code does not establish that an activity is lawful, that a licence covers a market or that a provider has approved the account. Visa’s public rules page also explains that regional and country-specific provisions apply within their stated scope and directs merchants to their acquirer agreement for additional requirements. [4] Use the current applicable rules and provider decision, rather than treating a code number as a global permission.

For a sensitive or regulated activity, bring the precise question to the relevant specialist and the acquiring provider. The merchant should supply facts and evidence, not invent an assignment or substitute an unrelated entity to avoid a difficult review.

A new sales channel, product line, seller arrangement or website can change the question the provider originally answered. Put classification on the business-change checklist alongside eligibility, customer terms, integration and settlement. A periodic review can also catch records that were never updated after a rebrand or acquisition.

Use a simple sequence: describe the change, identify affected processing routes, collect sales and product evidence, ask for the provider’s review, record the confirmed configuration and test affected features. Name an owner and keep unresolved items visible. Do not assume that changing a dropdown in a platform dashboard completes the acquiring review.

For a platform using Stripe Connect, include the documented account-update events in the operational design. Stripe describes notification when a review changes an MCC and limits subsequent platform changes to that reviewed value. [2] Map that event to a support or operations action so the recorded industry and actual setup do not silently diverge.

Retain the confirmation with the account record. If a later incident raises a classification question, the team should be able to identify who supplied the information, what activity was reviewed and which provider response applied at the time. This is more useful than a spreadsheet containing only a code and a company name.