Every Stripe decline code, what it actually means, and whether retrying will help

When a card payment fails in Stripe, you get a short string back — insufficient_funds, do_not_honor, authentication_required. Most teams glance at it and let Smart Retries hammer the card on a schedule.

That's the mistake. The right move depends entirely on the code:

• Some failures clear themselves if you retry in a few days.
• Some will never clear — and retrying them can get you fined by the card networks.
• Many need the customer to act, so retrying the same card is pointless.

A big slice of "failed" subscription payments are recoverable — but only if you act on the reason. Here's every code that matters and what to do about it.

First: code vs decline_code

Stripe returns two fields, and they're not the same:

• code — the high-level category, usually card_declined. Tells you almost nothing.
• decline_code — the granular reason from the issuing bank (insufficient_funds, lost_card, do_not_honor). This is the one you act on.

Caveat: issuers don't always report the true reason — anti-fraud blocks often hide behind a vague do_not_honor. The granular code is a strong hint, not gospel.

The mental model: five buckets

Every decline maps to one action: retry, email the customer, stop, or fix your checkout.

1 — Auto-recoverable (retry will likely work)

Timing problems. The card is fine; the money wasn't there that moment, or the network hiccuped.

This is the only bucket where blind retries earn their keep.

2 — Needs customer action (retrying is pointless)

The card can't complete the charge as-is. Email the customer with the specific ask.

The fix lives with the customer, not in your retry logic. A retry-only tool fails every one of these silently.

3 — Lost cause (stop retrying)

Card is dead, blocked, or flagged. Retrying won't help — and retrying network-flagged cards can trigger Visa/Mastercard penalties.

Action: stop. Ask for a different card, or let it churn.

4 — Hard declines (the ambiguous middle)

The bank declined without saying why — often deliberately.

Action: a couple of retries max, then email: "Your bank blocked this — a quick call to them, or a different card, usually fixes it." Many do_not_honor blocks lift in 30 seconds — if the customer knows to ask.

5 — Structural (fix checkout, not the payment)

Not about one customer — a recurring leak.

Fix it once, recover every future customer who'd hit the same wall.

The European trap: SCA and authentication_required

If you sell in Europe, this is what most US-built dunning tools get wrong.

• Under PSD2 / SCA, many recurring EU payments need the customer to authenticate via 3D Secure.
• When they don't, Stripe returns authentication_required.
• Most tools retry the card — which can never succeed without authentication.
• The fix: send a confirm-payment link (Stripe hosts the flow), not a retry.

For EU-facing SaaS, authentication_required is often a large, fully recoverable chunk that's silently written off.

One-page playbook

Takeaway

Blind retries only fix one of these five buckets. The rest need an email, a config fix, or a hard stop — so "just turn on Smart Retries" quietly leaves money on the table.

Try this: pull your last few months of failed payments and group them by decline_code. The split usually surprises people — especially how much is recoverable customer-action, not dead cards.

I'm building a tool that does this bucketing and routing automatically. Got war stories about declines, or opinions on what actually drives recovery? Drop them in the comments.