A decline code is the bank telling you, in compressed language, what kind of problem you have. Treating every code with the same retry schedule is like treating every support ticket with the same reply: efficient to configure, wrong in most individual cases. An insufficient-funds decline is a timing problem. An expired card is a data problem that no amount of retrying will solve. A do-not-honor is a shrug that sometimes clears on a later attempt and sometimes never does. Schedules built per category outperform a single ladder because they spend attempts where attempts can work.
Start by sorting your own failures. Most subscription businesses discover that three or four codes account for the overwhelming majority of their declines, which means the matrix that matters is small. For each major code, decide three things: how soon the first retry happens, how the later attempts are spaced, and what human outreach runs alongside. Insufficient funds argues for payday-aware spacing and patience. A generic decline argues for a prompt first retry, then widening gaps. Expired and replaced cards argue for almost no blind retries at all — the winning move is the update request, sent early, while retries continue quietly in the background only where the platform's account updater may resolve the problem on its own.
A worked matrix lays the categories side by side; on Stripe, where a native schedule is already running underneath yours, how stripe dunning keeps two retry schedules from stacking attempts on the same card is the useful version of that shape to argue with — your own code mix, price point, and subscriber base will move the numbers, but the discipline of deciding per category transfers intact.
There is also a ceiling worth respecting. Beyond a certain number of attempts, additional retries stop recovering subscribers and start generating complaints, disputes, and processor scrutiny. The exact ceiling varies, but the pattern does not: recovery curves flatten hard, and the last attempts in a long ladder cost reputation for almost no revenue. A schedule that ends deliberately — with a clear final notice and a clean cancellation — beats one that trails off because nobody decided where it stops.
Coordination with your billing platform matters here. If the platform also retries on its own schedule, two uncoordinated ladders can stack attempts on the same day, which looks to a bank like a merchant hammering a card. One schedule should own the timing — either the platform's native retries with your outreach layered on top, or your own schedule with native retries handed over. What you cannot have is both systems improvising independently.
A note on where the data for the matrix comes from, because teams often stall here waiting for perfect reporting. Your billing platform already records the decline code on every failed attempt, even if its dashboard does not foreground it. Export a quarter of failures and count the codes by hand if you must; an afternoon with a spreadsheet is enough to learn which three codes dominate and roughly how each one behaves across attempts — which codes clear on the second try, which never clear at all, and which clear only after a card update. That observed behaviour, from your own subscribers, is worth more than any published benchmark, because code mixes differ sharply by price point, geography, and audience. Build the first matrix from that export, mark it as a draft, and let the next quarter's numbers revise it.
Finally, measure per category, not just in aggregate. A change that lifts insufficient-funds recovery while hurting expired-card outcomes can read as a wash in the blended number while being two clear decisions wearing a disguise. The matrix is not a one-time design exercise; it is the table you revisit each quarter, when the code mix has shifted and last season's sensible spacing has quietly become this season's habit. Schedules age. The categories do not.
Published by Swipe Again, the flat-fee failed payment recovery service for subscription businesses.
Top comments (0)