Every failed Stripe charge comes back carrying a small piece of language: a decline code. Most teams glance at it the way you glance at a weather icon, register that it is bad, and move on to the retry button. That is a waste. The code is the one place where the issuer tells you, in its own compressed vocabulary, what it thinks happened — and different sentences call for completely different replies.
Start with the codes that are really about timing. Insufficient funds is the obvious one, but it has quieter cousins: a charge that lands the day before a salary does, a card pressed against a daily limit, an account briefly frozen by a travel hold. None of these customers are gone. Their money exists; it is simply not standing in the right place on the day you asked for it. The correct response is patience with a plan — a retry placed after the calendar turns, and a message that does not make a temporary shortfall sound like a character flaw.
Then there are the codes about information. Expired card, incorrect number, invalid expiry: the account is healthy and the details are stale. Issuers reissue cards constantly, for fraud sweeps and wear and bank mergers, and the new plastic rarely announces itself to your billing system. Retrying stale details harder does not fix them; it just teaches the issuer to trust your charges less. These customers need one clean, unembarrassing route to hand over fresh details, ideally before the renewal date rather than after the failure.
A third group is about identity checks: authentication required, incorrect CVC, a challenge the customer never saw. Here the charge did not fail because the customer refused — it failed because a step in the middle never completed. The fix is a nudge that explains exactly what will happen when they click through, not a generic "payment failed" alarm that leaves them guessing whether they have been charged twice.
And then there are the codes that mean stop. Stolen card, lost card, do not honor paired with a fraud signal: these are not recovery opportunities, they are instructions. Every extra attempt after one of these is wasted motion at best and a compliance problem at worst. A triage habit that cannot tell "wait" from "never" will burn its credibility on the accounts that were never coming back, and have less left for the ones that were.
One habit makes all of this easier: log the code, not just the failure. A surprising number of billing setups record that a charge failed and discard the reason, which means every later review is working from a pile of identical red marks. Keep the code attached to the attempt, and a month later you can answer questions that actually change policy — which family grew, which retry window earned its place, which message produced card updates instead of unsubscribes. Without the codes, every argument about dunning strategy is two opinions and no evidence.
The practical move is to sort before you sequence. Group this week's failures by code family, count each family separately, and let the family sizes set the work: calendar cases get scheduling, information cases get an update path, identity cases get a guided step, and stop cases get closed the same day. Teams that do this once are usually surprised by the shape of the pile — the dramatic codes are rare, and the boring, fixable families do most of the damage.
Codes are the vocabulary, but the system that answers them is the discipline: a practical guide to stripe dunning shows how each family should change the retry, the message, and the moment automation stops — the reference I keep open during a billing review.
Reading the sentence before answering it is the whole discipline at Swipe Again: sort by cause, retry only what a retry can fix, and let a firm no end the conversation immediately.
Top comments (0)