Why Are Crypto Cards Declined at Certain Merchants? MCC Restrictions and Payment Declines Explained

A crypto payment card may work without issue at supermarkets, restaurants, and ordinary online retailers, yet be declined by certain financial services, digital platforms, or specialized merchants. Even with sufficient funds and successful 3D Secure authentication, a transaction can still be rejected.

One possible reason is merchant category restrictions. Card transactions generally carry a Merchant Category Code (MCC), which issuers can use to restrict certain types of business activity. Some card programs prohibit transactions involving cryptocurrency purchases, money transfers, gambling, or other categories.

But a payment can also fail during merchant acceptance, authentication, or other stages of authorization. Understanding where MCC restrictions fit into the payment process is essential before attributing a decline to them.

1. Why Do Crypto Cards Decline Transactions at Certain Merchants?

An MCC is a four-digit code used within the payment card system to identify a merchant's business activity or a particular transaction category. Supermarkets, for example, generally use MCC 5411, restaurants typically use 5812, and securities brokers may use 6211. The code usually reflects the merchant's business rather than every individual item purchased. A supermarket selling gift cards does not mean that each such transaction automatically receives a different MCC.

MCCs are assigned and managed by acquirers or other acquiring service providers under payment network rules. Cardholders do not choose them. Different activities at the same business location, or transactions that require separate identification, may also need different MCCs under the applicable rules. Visa's Merchant Data Standards Manual sets out requirements for merchant information and category assignment.

When a customer pays, the merchant submits an authorization request through a payment gateway or processor, the acquirer, and the card network. The issuer, or its authorization processing system, then decides whether to approve the transaction. Information such as merchant category, transaction amount, location, currency, and payment method may all factor into that decision.

Consider a card program that prohibits cryptocurrency purchases using payment cards. If the MCC associated with an authorization request triggers that program's restrictions, the issuer may decline the transaction. This type of control is already supported by payment infrastructure. Visa's Commercial Payment Controls supports transaction controls based on merchant category, while Adyen's issuing authorization rule examples show how rules can be configured by country and MCC.

An MCC is only one factor in an authorization decision. It does not determine the outcome by itself. Card status, available balance, transaction limits, and other risk controls may still determine whether a payment is approved.

2. Which MCCs Are Commonly Subject to Crypto Card Restrictions?

Money transfers, financial account funding, cryptocurrency purchases, gambling, and securities transactions are among the categories that warrant closer examination. The table below lists six representative MCCs. It is not a universal list of prohibited categories applicable to every crypto payment card.

The category names are simplified for readability. Actual classification is governed by the applicable payment network rules.

Buying Cryptocurrency Is Not the Same Transaction as Funding a Card Account

When a user deposits USDT into a crypto card account, the transfer may take place onchain, without passing through the payment card acquiring network. In that case, the deposit itself does not generate a card transaction MCC. A subsequent purchase of ordinary goods using the card, however, enters the card authorization process.

If the same user instead uses the card to purchase BTC or USDT on a trading platform, the nature of the transaction changes. Under Visa's merchant classification rules, cryptocurrency purchases may fall under MCC 6012 or 6051, depending on the merchant entity and transaction arrangement. Other transactions involving the acquisition of non-traditional fiat currency, as specified in the applicable rules, may also involve codes such as 4829 or 6540. It would therefore be incorrect to classify every cryptocurrency purchase as MCC 6051.

Issuers may restrict such transactions to control cash equivalents, circular movement of funds, or payments that fall outside the intended use of a card program. Allowing users to fund a spending balance with crypto assets does not necessarily mean they can use the card network to purchase more crypto assets.

Money Transfers, Account Funding, and Specialized Financial Services

MCC 4829 primarily covers money transfer activities. MCCs 6012, 6051, and 6540 may apply to account funding, stored-value products, and other related services provided by financial or non-financial institutions. These codes are not interchangeable simply because a transaction involves adding funds to an account. Classification also depends on the merchant's business, the underlying transaction, and applicable processing rules.

Some cashback cards apply particularly strict controls to money transfers because repeated transfers could be used to generate rewards outside the program's intended policy. Gambling and securities transactions may also be subject to issuer policies, acquiring requirements, and local laws. Cardholders should review their programs' specific provisions on Prohibited Transactions, Account Funding, Money Transfer, and related activities.

3. Real-World Card Policies: Crypto.com and Coinbase

Crypto.com USD Card: Explicit MCC restrictions in official guidance.

In its article Why was my transaction with the Crypto.com USD Card declined?, Crypto.com identifies a merchant MCC that does not comply with card usage policies as one possible reason for a declined transaction. The page also lists other circumstances, including a locked card, insufficient USD balance, incorrect PIN or online card details, unsupported payment methods, and installment payments that are not supported.

These decline reasons apply to the USD Card product covered by that particular official guidance.

Coinbase Card: Publicly disclosed prohibited merchant activities.

Coinbase's Card usage guidance identifies prohibited categories including securities brokerage, gambling, money transfers, remittance services, and cryptocurrency businesses. It also states that transfers or withdrawals to platforms such as Venmo, PayPal, and Cash App are not supported in the United States.

The page describes business restrictions for a specific card product. It does not publish a corresponding MCC blocking code for every prohibited activity. Those business descriptions alone are not enough to construct a complete MCC blacklist for Coinbase Card.

4. Why Can the Same Card Work at One Merchant but Fail at Another?

Two websites may sell similar products while presenting different merchant information to the payment card network. One software company might process payments directly, while another provides subscriptions through a Merchant of Record, which assumes the relevant sales and payment collection responsibilities. Differences in the merchant entity, acquiring arrangement, and business model can affect the merchant name, location, and MCC associated with a transaction.

Even when customers see the same brand, a major platform may process cloud services, software subscriptions, and digital content through separate merchant accounts. Using a Merchant of Record does not automatically change the MCC, however. Classification still depends on the underlying business and the acquirer's assignment.

Using the same payment gateway does not mean using the same MCC. Payment service providers such as Stripe and Adyen serve merchants across many different industries. If a card works at one website using Stripe but fails at another, that is not evidence that Stripe categorically refuses the card.

Different transactions at the same merchant may also produce different outcomes. An initial card verification might involve only a small authorization, while the actual charge is for a different amount. A one-time purchase and a merchant-initiated recurring payment may also be subject to different authentication and authorization conditions. Account funding transactions can involve specialized processing arrangements or merchant configurations.

A transaction can therefore be declined because of the amount, location, payment method, available balance, or risk controls even when the MCC remains unchanged. Successfully adding a card but failing to complete a subsequent payment is not, by itself, evidence of a prohibited merchant category.

5. How Do MCC Transaction Restrictions Differ from Cashback Exclusions?

MCCs can be used for both authorization controls and rewards calculations, but these rules serve different purposes. Authorization restrictions determine whether a transaction can be approved. Rewards exclusions determine whether a completed transaction qualifies for benefits.

Crypto.com's prepaid card CRO rewards exclusion policy lists multiple MCCs that do not qualify for rewards, including certain money transfer, financial services, and utility categories. That document concerns CRO rewards eligibility. Its exclusions should not be interpreted as a prohibition on making card payments.

When comparing cards, it is important to review Card Usage Restrictions, Prohibited Transactions, Rewards Exclusions, and fee terms separately. A transaction that earns no cashback is not necessarily a transaction that cannot be paid for.

6. How Can You Tell Whether an MCC Restriction Caused a Payment Decline?

Most checkout pages display only a general message such as Declined or Payment Failed. The detailed response received by the merchant or acquiring service provider may not be passed on to the cardholder. The following checks can help narrow down the cause:

1. Identify where the payment failed. If Card Not Supported appears immediately after entering the card number, the merchant or payment service provider may have rejected the card before submitting an issuer authorization request. If 3D Secure (3DS) authentication fails, address that issue first. 3DS is used to authenticate cardholders in online payments; successful authentication does not guarantee issuer authorization.

2. Check the card app. Look for a corresponding failed transaction or authorization record. The absence of a record does not, by itself, prove that the issuer never received the request. Ask the card provider to verify.

3. Rule out common causes. Check the available balance, currency, frozen or locked card status, online payment settings, and per-transaction or cumulative limits. Some merchants request a preauthorization amount higher than the final purchase amount.

4. Review official restrictions. Look for terms such as Merchant Category Restrictions, Prohibited Transactions, and Restricted Merchants in the cardholder rules. Pay particular attention to money transfers, financial account funding, and cryptocurrency purchases.

5. Contact the card provider. Supply the transaction time and time zone, merchant name, amount, currency, last four digits of the card, and a screenshot of the error with sensitive information redacted. Ask the provider to locate the authorization record and determine whether an MCC restriction or another rule caused the decline.

What Do Common Decline Messages Actually Mean?

Adyen's raw acquirer response documentation illustrates different authorization decline responses and how they are mapped. For example, response code 57 commonly indicates "Transaction Not Permitted to Cardholder," but the code alone does not establish that an MCC restriction was responsible.

When contacting the card provider, you can ask:

Could you review the authorization record for this transaction and confirm whether it was declined because the Merchant Category Code (MCC) triggered a card program restriction? If not, please identify the actual decline reason and, if available, provide the MCC used for the transaction.

A card's Bank Identification Number (BIN) identifies its issuing origin and related card attributes. It serves a different purpose from an MCC, which classifies merchants. A merchant may reject a card based on its BIN, country of issuance, or prepaid card type before submitting an authorization request. Such a rejection should not automatically be attributed to the issuer's MCC rules.

7. Can You Look Up a Merchant's MCC Before Making a Payment?

Some card apps display merchant categories in transaction details, but it is generally not possible to determine the exact MCC of a future transaction from a website's name alone. A merchant may operate through multiple acquiring entities, merchant accounts, or regional configurations.

For a specific transaction, authorization records confirmed by the issuer or acquirer should take priority. Third-party MCC databases can provide useful reference information, but their sources, update dates, and the merchant entities they cover need to be checked. A brand name or another customer's payment experience is not enough to establish which MCC a particular transaction actually used.

Even if another cardholder successfully pays on the same website, a transaction involving a different region, merchant account, or card program may not use the same classification.

For an information platform such as UCard Radar, publicly available merchant classifications, card program restrictions, and evidence of actual payment compatibility should be recorded separately. Without verifiable transaction information, an MCC should not be presented as confirmed.

8. Can MCC Restrictions Be Resolved? Will Switching Cards Help?

If an issuer explicitly prohibits a transaction category, customer support generally cannot override the card program's policy for an individual payment at its discretion. Rules differ among issuers, so a lawful transaction that meets another card's terms may succeed with that card.

Changing cards will not resolve every issue, however. Merchant refusal of prepaid or virtual cards, unsupported regions, authentication failures, and legal or compliance restrictions each require separate attention. If a merchant has genuinely been assigned an incorrect MCC, the merchant should contact its acquirer to request a review under the applicable rules rather than changing the classification through an inaccurate transaction description.

For users who regularly pay for cloud services, software subscriptions, or other specific expenses, card selection should involve more than fees, card networks, and spending limits. It is also worth examining prohibited transaction categories, actual usage records, and whether the provider can investigate authorization declines. When payments are repeatedly rejected, establish the actual authorization reason before deciding whether to address an account issue, contact the merchant, or switch to a payment method better suited to the intended use.