Issuer Decline: What It Means and What to Do About Each Type

An issuer decline means the customer's bank refused the charge. Not Stripe, not Visa, the bank that issued the card. That distinction matters because it tells you who holds the fix: either time and well-placed retries, or the customer calling their bank.

If you have ever stared at a failed payment in your Stripe dashboard and wondered who exactly said no, this post is for you. We will walk through the whole family of issuer-side declines, which ones you can retry, which ones need an email, and which ones are dead on arrival.

Who declines a charge, and why it matters

Every card payment passes through a chain: your checkout, your processor (Stripe), the card network (Visa, Mastercard, Amex), and finally the issuing bank. A decline can come from any link in that chain, but the overwhelming majority come from the last one. The issuer holds the account, sees the balance, runs the fraud model, and makes the final call.

This is why "the customer has money, why did it decline?" is the wrong question. The bank's decision has almost nothing to do with whether the money exists. It is a risk decision made by a model in milliseconds, and banks intentionally keep the reasons vague so fraudsters cannot reverse-engineer them. Your recovery strategy has to work despite that ambiguity, not wait for clarity that will never come.

The issuer decline family

Stripe normalizes hundreds of raw bank response codes into a manageable set of decline codes. The issuer-side ones you will actually see on subscription renewals:

• •do_not_honor: the catch-all. The bank said no and gave no reason. Soft, retryable, the most common vague code. I wrote a full recovery guide for this one separately.
• •generic_decline: same energy as do_not_honor, even less information. Treat it identically: spaced retries, then email.
• •insufficient_funds: the one specific soft code. The money is not there right now. Retry timing around paydays is everything.
• •try_again_later / issuer_not_available: the bank's systems hiccuped or asked you to wait. Soft. Retry within a day or two.
• •restricted_card: a standing block on the card (online purchases disabled, category block, security freeze). Hard in practice. Email immediately.
• •lost_card / stolen_card / pickup_card: the card is dead. Hard, never retry, email about a new card on day one.
• •fraudulent / blacklist-type responses: hard, and honestly a signal to look at whether you want this customer back at all.

Read that list once and the entire recovery strategy writes itself. The soft half (do_not_honor, generic, insufficient funds, try-again family) gets patient, spaced retries. The hard half gets a fast, human email. The only expensive mistake is mixing them up: emailing too early on soft codes annoys customers whose payment would have recovered silently, and retrying hard codes burns attempts and time on payments that were never coming back.

The decision table I actually use

When an issuer decline lands, run it through three questions:

• •Is the card still valid? If the code says lost, stolen, restricted, or expired, the card itself is the problem. Skip retries entirely, email about a new card.
• •Is it a timing problem? Insufficient funds and try-again codes are about when, not if. Schedule retries around paydays and bank-system resets.
• •Is it a mystery? Do_not_honor and generic declines get the patient treatment: 3 to 5 retries spaced over ten days, then email only if they all fail.

One boundary worth respecting on every retry path: the card networks cap total attempts (roughly 15 per 30 days for Visa, about 35 for Mastercard) and will fine merchants who hammer declined cards. Any sane cadence stays far under those limits, but it is a good reason not to let a misconfigured retry loop run wild.

What to tell the customer

When retries run out and you email, the message should match the code family. For mystery declines (do_not_honor, generic), the ask is "call your bank to approve us, or wait for our retry." For card-dead declines, the ask is "add a new card." Getting this right doubles your email recovery rate, because you are asking the customer to do the thing that actually fixes their specific problem instead of a generic card-update dance.

And send it like a person. The single biggest lever on issuer-decline recovery emails is that they come from a real address and read like a human who noticed a problem, not a billing robot demanding action. Reply rates tell the story: people reply to people.

The boring compounding part

Individually, each issuer decline is a $29 or $50 problem. Collectively, they are the biggest slice of involuntary churn for most subscription businesses, typically a few percent of renewals failing on first attempt every single month. The founders who win this game are not doing anything clever. They just refuse to let a recoverable bank decision quietly become a cancelled subscription.

Two Stripe settings worth checking today

While you are thinking about issuer declines, two configuration checks pay for themselves. First, confirm Smart Retries is actually enabled; Stripe's machine-learning retry scheduling is decent at soft issuer codes, and some founders turned it off years ago while debugging something and never turned it back on. Second, look at what happens after retries exhaust: whether the subscription is set to cancel, pause, or stay past due. That default decides whether a recoverable issuer decline becomes a cancellation automatically or stays a live account while your emails do their work. Ten minutes, both settings, real money.

What your decline mix is telling you

Individual declines are incidents; your decline mix is a diagnostic. Once a month, group your issuer declines by code and ask what changed. A spike in do_not_honor often means a new audience segment with cautious banks or an influx of prepaid cards. A spike in try_again_later can mean your billing run lands at a bad hour for a big customer's bank. A growing restricted_card share often tracks international expansion into markets where cross-border blocks are the default.

You do not need fancy tooling for this. Stripe's dashboard breaks declines down by code, and a spreadsheet pivot on a CSV export does the rest. The founders who catch problems early are not smarter; they just look at the mix before it shows up as churn.

And if you only take one idea from this whole post, take this: the decline code is the diagnosis, not the verdict. Every issuer decline is the bank telling you which play to run. Founders who read the code recover the payment; founders who treat all failures the same lose customers the bank never really rejected.

A last word on tone, because it decides more recoveries than timing does. The moment your email reads like a collections notice, you have told the customer this relationship is transactional. The founders with the best recovery numbers write like the person who built the thing, because they are. Banks may be faceless; you do not have to be.

That refusal is exactly what I built StayPaid to automate: it reads the decline code, runs the right play (patient retries for soft, immediate personal email for hard), and sends everything from your actual address with the kind of tone that gets replies. You approve the flow once, and the issuer declines stop being a monthly leak you find in a spreadsheet three months too late.