Does this code mean the card has been used too many times?

Not according to Stripe's own definition. Despite the name, it refers to the balance or credit limit available on the card being exceeded by the charge amount, not a transaction count.

Is this decline more common on certain card types?

Yes. It shows up more on prepaid and debit cards, which carry hard balance ceilings, than on standard credit cards.

Should a merchant retry immediately after this decline?

No. An immediate retry usually hits the same limit. Timing the retry around a likely balance replenishment (payday, reload, statement cycle) gives it a real chance.

What if the same card keeps failing with this code every billing cycle?

That's a sign the card's limit may be structurally too low for the subscription amount, and it's worth prompting the customer directly to switch to a different card.

Does Foxhound notify the customer right away when this code appears?

No. It runs a silent background retry first and only sends the merchant's branded recovery email if the retry schedule doesn't recover the charge.

Decline code

Withdrawal Count Limit Exceeded

`withdrawal_count_limit_exceeded` is a decline Stripe returns when, per its official definition, the customer has exceeded the balance or credit limit available on their card. The name is a holdover from debit and prepaid card terminology, where issuers track a count or limit on withdrawal-style transactions, but functionally it lands the charge in the same place as a plain limit-exceeded decline: the customer's card can't cover the charge right now. It's a soft decline.

Back to decline codes

withdrawal_count_limit_exceededRetries 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

The naming is a common source of confusion. It sounds like it's about how many times a card has been used, but Stripe's stated definition ties it to balance and credit limit, not a literal transaction count. For subscription billing, this shows up in the same situations that produce other limit-related declines: a prepaid or debit card with a preset balance that a recurring charge exceeds, or a credit card sitting close to its limit when a monthly renewal comes due. Because the code is more common on prepaid and debit cards than traditional credit cards, subscription businesses with a customer base skewing toward those card types see it somewhat more often than businesses whose customers pay mostly with standard credit cards.

How to fix it

Yes. Since the underlying issue is a balance or limit constraint, the same logic that applies to `insufficient_funds` applies here: a retry timed after a likely balance replenishment (a payday, a prepaid card reload, a statement cycle reset) has real odds of succeeding, while an immediate retry right after the decline usually just hits the same limit again. Retry on a delay rather than immediately, and where possible bias the retry timing toward common income or reload cycles the same way you would for a straightforward insufficient-funds decline. If retries keep failing over multiple cycles, that's a signal the card's limit may be permanently too low for the subscription amount, at which point a direct message asking the customer to add a different card is more useful than continuing to retry indefinitely.

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

Not according to Stripe's own definition. Despite the name, it refers to the balance or credit limit available on the card being exceeded by the charge amount, not a transaction count.
Yes. It shows up more on prepaid and debit cards, which carry hard balance ceilings, than on standard credit cards.
No. An immediate retry usually hits the same limit. Timing the retry around a likely balance replenishment (payday, reload, statement cycle) gives it a real chance.
That's a sign the card's limit may be structurally too low for the subscription amount, and it's worth prompting the customer directly to switch to a different card.
No. It runs a silent background retry first and only sends the merchant's branded recovery email if the retry schedule doesn't recover the charge.

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