Disclosure: we're the Swipe Again team. We build failed-payment recovery software, so we read decline codes the way mechanics read engine noises. Everything below is the taxonomy itself — check it against your own billing data; it either matches or it doesn't.
Ask most subscription businesses why a payment failed and you'll get one answer: "the card was declined." It sounds like a single event. It isn't. A decline code is your bank's compressed explanation of why a transaction didn't happen, and the major families of codes describe completely different situations — different causes, different fixes, different odds. Treating them as one problem, with one response, is the most common and most expensive mistake in payment recovery.
Here's the field guide we work from.
1. Insufficient funds: a timing problem
The most misunderstood decline in subscriptions. "Insufficient funds" rarely means the customer has no money. It usually means the money wasn't in that account at that moment — the charge ran before payday, before a transfer settled, on the wrong side of a rent payment.
The correct response is the one most default retry setups get wrong: wait, then retry. A funds decline retried in six hours is the same decline again. The same charge run days later, after the account's rhythm has moved, is a genuinely different attempt. This family rewards patience and punishes speed, and it's why retry timing should be set by the decline reason rather than by a fixed calendar cadence.
2. Do-not-honor and generic declines: the bank isn't saying
do_not_honor and the catch-all generic_decline are the issuer declining to explain itself. Behind the opacity there's usually something — a risk rule, an account restriction, a velocity limit, a pattern the bank doesn't like — but the bank deliberately doesn't tell you which, partly for fraud reasons.
We wrote up what a generic decline actually is and how to respond in more depth, but the short version: this family deserves a limited number of retries, spaced out. Some of these clear on a later attempt once whatever tripped the rule has passed. Some never will, and because the bank won't distinguish the two for you, the discipline is a hard ceiling — a few attempts, then stop and let the human route (a dunning email, a new card) take over. Unlimited retries against an opaque decline don't recover revenue; they just spend attempts and goodwill with the issuer.
3. Expired or replaced cards: the credential is gone
This is the family where retries are not merely wasteful — they're nonsensical. When a card expires, or a bank reissues it after a fraud alert and the new number never reaches you, the credential you're charging no longer exists. You could retry it hourly until the heat death of the universe and recover exactly nothing.
The only fix is a new card from the customer, which makes this a communication problem, not a scheduling problem: a clear email in your name, landing on a hosted card-update page with no login maze between the subscriber and the form. Every day a replaced-card failure sits in a retry queue instead of a customer's inbox is a day wasted — the system should recognize this family instantly and skip straight to asking for the new card.
4. Authentication required: the customer has a job to do
Some declines — common with Strong Customer Authentication regimes — mean the transaction needs the cardholder to confirm it's really them: approve a prompt, complete a challenge, verify with their bank. No retry succeeds on its own, because the missing ingredient is a human action only the customer can take.
The response is a prompt, fast and specific: tell the subscriber exactly what their bank is asking for and make it easy to complete. This family fails silently in a lot of setups because the failure looks identical to every other "payment failed" in the dashboard — while the actual remedy is sitting in the customer's banking app, waiting to be noticed.
5. Hard declines: stop means stop
Stolen card. Closed account. Fraud flags. A small set of codes mean the payment method is dead or dangerous, and the correct number of further attempts is zero. Retrying hard declines doesn't just fail — it can make things worse, training issuer risk systems to associate your charges with bad traffic and raising the odds that your legitimate renewals get scrutinized.
A recovery system that can't tell a hard decline from a timing problem isn't being thorough. It's being careless at scale.
The taxonomy is the strategy
Lay the five families side by side and the pattern is obvious:
| Family | Real cause | Correct response |
|---|---|---|
| Insufficient funds | Timing | Wait, then retry |
| Generic / do-not-honor | Bank opacity | Limited, spaced retries, then stop |
| Expired / replaced | Credential gone | Ask for a new card — don't retry |
| Authentication required | Customer action needed | Prompt the customer, fast |
| Hard decline | Dead or dangerous card | Zero further attempts |
Five causes, five different plays. A single fixed retry schedule — same attempts, same spacing, applied to everything — gets at most one of these right. This is why we built Swipe Again's retries to be decline-code-aware: up to six attempts over about 16 days for the failures worth retrying, timed to the reason, with the card-update route taking over the moment the code says the problem is the card and not the calendar.
But the tool matters less than the habit. Pull your last month of failed payments, group them by decline code, and look at what you've actually got. Most businesses find their failures concentrate in one or two families — and that the fix for their dominant family is different from the generic advice they've been following. Read the codes first. They're the cheapest diagnosis in your entire billing stack, and they're already sitting in your data, telling you exactly what's wrong.
