A subscriber's renewal fails and the processor hands you two words: generic decline. No reason, no sub-code worth trusting, nothing to act on. Most billing teams file it under "bank said no" and schedule the same retry they would schedule for any other failure. That is the expensive habit hiding inside the blandest decline code in the catalogue, because a generic decline is not one problem. It is at least three, and they respond to opposite treatments.
Problem one: the bank will not say, and will not be asked twice the same way
Some issuers return generic declines as a deliberate information policy, especially on card-not-present renewals where their risk models are twitchy. The underlying cause might be velocity checks, a mismatch between the transaction's shape and the cardholder's pattern, or a model score nobody outside the bank will ever see. The practical tell: the same card worked last month and works elsewhere. For this pile, the lever is presentation, not persistence — retrying with cleaner data (current network token, correct indicators, no stale credential artifacts) succeeds at a noticeably better rate than retrying the identical transaction and hoping the model feels differently.
Problem two: a soft no that hardens if you push it
A second pile is risk fatigue at the issuer: the first generic decline is a shrug, but the fifth identical attempt in a week reads as insistence, and insistence gets profiles flagged. Teams discover this pile only in hindsight, when a card that eventually pays on a competitor's platform never pays on theirs. There is a plain-language field guide to what a generic decline is actually telling you that walks the sub-cases; the operational summary is that attempt count is a budget, and generic declines spend it faster than honest soft declines do. Space the attempts, change something real between them, and let an email reach the subscriber before the budget runs out — a cardholder who confirms the charge with their bank converts a generic wall into an open door more reliably than any retry cadence.
Problem three: it was never the bank's decision to explain
The third pile is the uncomfortable one: the decline is generic because the transaction genuinely looks wrong from where the issuer sits — a descriptor the cardholder does not recognize, an amount that drifted from the established pattern after a price change, a billing country that no longer matches the account's life. These recover when the subscriber is brought into the loop early and told exactly what will appear on their statement and when. They do not recover from silent retries, because nothing about a silent retry fixes a recognition problem.
Sorting your own pile
You cannot split generic declines by asking the processor; you split them by experiment. Take a quarter's worth, divide them by what you did next — immediate identical retry, delayed changed retry, email-first — and compare recoveries at the subscription level thirty days later. The proportions will not match anyone's benchmark, including this essay's. They will, however, tell you which of the three problems your business actually has, and that is the difference between a dunning strategy and a superstition with a schedule.
The teams that get good at this stop treating decline codes as verdicts and start treating them as routing information: each code sends the failure down a different path, with a different clock and a different owner. Generic declines are just the code that forces the lesson, because they refuse to route themselves.
Notes on decline-code routing and retry design live at Swipe Again, where the recovery tooling described here is built.
Top comments (0)