Recovery Rate

20–35%

Hard Decline

Stripe Decline Code · Glossary

card_not_supported

Non-recoverable·20–35%·Updated May 2026

What It Means

What card_not_supported actually means.

card_not_supported fires when the customer's card type is not accepted for this specific type of transaction — the card is active and the account may be funded, but the card product itself is structurally incompatible with the transaction class being attempted. It is a hard, card-product-level decline that sits close to service_not_allowed in the taxonomy: where service_not_allowed blocks a service category, card_not_supported blocks a specific card product type from being used for your transaction type entirely — prepaid cards on subscription billing, virtual cards on recurring charges, or specific network card products not accepted by your merchant configuration.

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

1Prepaid card on a subscription/recurring charge — The single most common SaaS cause: prepaid cards are structurally incompatible with recurring MIT billing on many card networks and issuers — the card product itself doesn't support being stored and charged on a recurring basis, and the issuer returns card_not_supported rather than a generic decline
2Card network not supported by your Stripe configuration — Your Stripe account is not configured to accept a specific card network — Discover, UnionPay, Diners Club, or a regional network — and a customer presents a card on that network; Stripe or the acquirer returns card_not_supported at the merchant acceptance level
3Card type excluded from merchant category — Certain card products are programmatically excluded from specific merchant category codes — a benefits card, government-issued debit, or payroll card that is restricted to certain spend categories returns card_not_supported when used at a digital goods or SaaS MCC
4Virtual card product incompatibility — Virtual cards issued by corporate expense platforms (Brex, Ramp, Divvy) may have product-level restrictions that prevent them from being used for subscription billing or recurring charges — the card product specification itself blocks the transaction type
5HSA/FSA card used on non-qualifying merchant — Health Savings Account and Flexible Spending Account cards are restricted to IRS-approved healthcare MCCs — using one on a SaaS or digital goods merchant returns card_not_supported because the merchant category doesn't qualify for HSA/FSA spending

What NOT to Do

Common mistakes that make it worse.

✕ Don't retry — this is a permanent card product incompatibility

card_not_supported is not a timing issue, a funds issue, or a bank-contact-resolvable problem. The card product itself is incompatible with your transaction type — no retry interval or cardholder action changes this. Add it to your no-retry blocklist alongside service_not_allowed and restricted_card immediately.

✕ Don't ask the customer to contact their bank

Unlike call_issuer or security_violation, a bank call cannot override a card product specification. The incompatibility is baked into the card type at the product level — the bank's customer service team has no mechanism to make a prepaid card support recurring billing or make an HSA card work at a non-qualifying merchant. Sending customers on a bank call for card_not_supported wastes their time and destroys trust.

✕ Don't send a generic "update your credit card" email without specifying why

If the customer is using a prepaid card, virtual card, or restricted card product, asking them to "update their payment method" without explaining that their specific card type isn't supported leads to them re-entering the exact same incompatible card type — generating another card_not_supported failure. Your email must name the card type limitation explicitly and guide them to a compatible alternative.

Retry Timing

Optimal retry schedule.

Zero retries. The entire recovery path is a payment method replacement sequence — the card product is permanently incompatible.

Recovery Benchmark

What good looks like.

Metric	Result
Overall recovery rate	20–35%
Recovery with BIN-targeted email (card type specific)	35–50% of those who engage
Recovery with generic card update email	5–10%
Recovery via alternate payment method (PayPal, bank transfer)	+15–20% additional lift
Recovery with blind retries	~0%
Prevention via BIN check at checkout	Eliminates 55–65% of occurrences

A 30–35% overall recovery rate with BIN-targeted emails that name the exact card type issue and lead with a compatible alternative. The dominant ROI lever — identical to service_not_allowed — is checkout-level BIN detection that prevents incompatible cards from being saved in the first place.

At Scale

How to handle it at scale.

Automated

✓Webhook trigger: invoice.payment_failed → check failure_code === 'card_not_supported' → immediately run BIN lookup to classify the card product type before any downstream action
✓Zero retries — permanent blocklist: Add card_not_supported to your no-retry list alongside service_not_allowed, restricted_card, and pickup_card
✓BIN-segmented email copy:
✓Prepaid card → "Prepaid cards don't support subscription billing — here's how to add a debit or credit card"
✓Virtual/corporate card → "Your corporate card can't be used for recurring billing — we can set you up on ACH or invoicing instead"
✓Unsupported network → "We're unable to accept [network] cards — Visa, Mastercard, or bank transfer work great"
✓HSA/FSA card → "HSA/FSA cards are restricted to healthcare purchases — please add a personal card or bank account"
✓Non-card options prominent: PayPal, bank transfer, UPI, and ACH must be first-class options on your payment update page — not footnotes; for card_not_supported customers, these are often the most viable immediate alternative
✓Checkout BIN detection (preventive): Implement BIN API lookup at card entry in your checkout — flag incompatible card types with an inline, non-alarming message before signup completion; this is the highest-ROI engineering investment for this code
✓Network coverage audit: If card_not_supported is firing on specific networks — Discover, UnionPay, Diners Club — evaluate whether enabling those networks on your Stripe account is commercially warranted; enabling a missing network can eliminate an entire failure cohort

Manual Escalation

→High-ACV B2B accounts with corporate/virtual card limitations: Direct conversation about ACH, wire transfer, or Stripe Invoices as a permanent billing arrangement — many corporate accounts prefer invoice-based billing anyway; card_not_supported on a corporate card is often an opening to a better long-term billing relationship
→International customers on unsupported networks: Personal outreach to guide them to a local payment method — UnionPay customers in China, Elo customers in Brazil, RuPay customers in India — walk them through adding a supported local alternative one-on-one
→Recurring card_not_supported by geography or card type: Monthly cohort analysis — if a specific card product or network is generating consistent failures, it's a product gap signal; adding that network to your Stripe acceptance configuration or adding the relevant local payment method eliminates the cohort permanently

FAQs

Frequently asked questions.

What does the Stripe card_not_supported decline code mean?

card_not_supported means the customer's card product type is structurally incompatible with the transaction being attempted. The card may be active and funded, but the card type itself — prepaid, virtual, HSA/FSA, or an unsupported network — cannot be used for this merchant or transaction class. It is a permanent card product incompatibility, not a timing or funds issue.

What are the most common causes of a card_not_supported error in Stripe?

Common causes include prepaid cards being used for subscription or recurring billing, a card network not configured in your Stripe merchant account, benefits or government cards restricted to specific merchant categories, virtual or corporate cards with product-level recurring billing restrictions, and HSA/FSA cards used at non-qualifying merchant category codes.

Should I retry a payment after a card_not_supported decline?

Never. The card product itself is incompatible with your transaction type — no retry interval changes this outcome. Add card_not_supported to your permanent no-retry blocklist and focus all recovery effort on capturing a compatible payment method: a standard credit or debit card, PayPal, bank transfer, or a local payment method.

How do I prevent card_not_supported failures at checkout?

Implement a BIN API lookup at card entry in your checkout to identify incompatible card types — prepaid, virtual, HSA/FSA, unsupported networks — before the customer completes signup. An inline, non-alarming message at this stage eliminates 55–65% of card_not_supported failures before they reach your billing system. This is the highest-ROI engineering investment for this specific decline code.

What is the recovery rate for Stripe card_not_supported failures?

Overall recovery rates are 20–35%. BIN-targeted emails that name the specific card type incompatibility and lead with compatible alternatives recover 35–50% of customers who engage. Generic card update emails recover only 5–10%. Alternate payment method options like PayPal and bank transfer add 15–20% additional lift. Checkout-level BIN detection prevents 55–65% of occurrences entirely.

What to do next

You are here

card_not_supported

Decline code reference

↓→

Check recoverability

Stripe Failure Lookup

See what's recoverable — and what isn't →

↓→

Then

Automate recovery for every decline code →

Before you retry

Most card_not_supported failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.

See what card_not_supported costs me →

Stop leaving revenue on the table

card_not_supported can't be retried — but it can be caught earlier.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.

See what's leaking →All 30 decline codes →