foxhound
Sign in

Decline code

Card Not Supported

`card_not_supported` is Stripe's decline code for a card that doesn't support the type of purchase being attempted. In practice this shows up on some prepaid cards, certain international card products, or card types that aren't set up to handle recurring or subscription billing at all. The card itself may work fine for other kinds of purchases, it just isn't built for this particular transaction type.

Back to decline codes
card_not_supportedRetries automatically
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

This one is worth calling out because it behaves a little differently from the purely technical declines above. Recurring billing is a specific transaction type, and not every card product is provisioned to support it. Some prepaid cards are issued only for one-time point-of-sale purchases and reject recurring authorization attempts by design. Certain cards issued outside the merchant's primary market carry network restrictions that block subscription-style charges even though the card works for standard purchases. And some card products, regardless of country, are simply configured by the issuing bank to not permit recurring charges. Foxhound's classifier still routes this code into the network bucket, since it is not a fraud signal and not a closed-account signal, but it's useful to recognize that the underlying cause here is closer to a card capability limitation than a bank outage.

How to fix it

It's classified as retryable, and an immediate retry can occasionally succeed if the original attempt hit a temporary network-level restriction rather than a hard capability limit. That said, if the same card keeps producing this decline across multiple retries, it's a signal that the card product itself doesn't support recurring charges, and no amount of retrying will change that. At that point, switching payment methods is the real fix. Give it the standard early retry window, a few hours out, then a second attempt around a day later. If both retries fail with the same code, treat that as a strong signal to move to customer outreach rather than continuing to retry indefinitely. The ask to the customer should be specific: this card doesn't support recurring charges, please add a different card, rather than a generic "your payment failed" message that doesn't explain what's actually needed.

How Foxhound recovers it

A Foxhound-scheduled silent retry runs first, timed for the specific decline pattern rather than an immediate repeat. If the retry succeeds, the customer never sees anything happened. If it does not, Foxhound moves to a dunning email sequence across the following weeks, written in the merchant's own brand voice, with a hosted card-update link on every email as a passive fallback channel.

Questions

  • The card product itself may not be provisioned for recurring or subscription-style charges, even though it works fine for one-time purchases. This is common with certain prepaid and international cards.

  • No. It's a capability limitation on the card product, unrelated to fraud screening or the legitimacy of the transaction.

  • Sometimes, if the block was a temporary network-level restriction. But if the card product structurally doesn't support recurring billing, retries will keep failing and a different payment method is needed.

  • It should be specific: explain that the card doesn't support recurring charges and ask for an alternative payment method, rather than a generic payment failure notice.

  • Yes, both sit in the network bucket and get the same automated background retry treatment before any customer email goes out.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit