Retry Timing Is a Discipline, Not a Setting

Every billing stack retries failed payments. The difference between recovering a quarter of failed value and recovering half of it is rarely the number of attempts — it is whether the attempts are scheduled by the reason the payment failed.

Consider what a decline code is: the issuer explaining itself. Insufficient funds says "not now" — and "now" has a calendar, because balances refill on paydays. An expired card says "wrong plastic" — no date on any calendar fixes that; a person has to act. A generic decline says "ask differently or not yet." A closed or stolen card says "never again." Software that reads those four messages and responds with one schedule — retry on days 1, 3, 5, and 7 regardless — is discarding the only information the issuer volunteered.

The costs of ignoring the signal run both ways. Under-retrying timing failures leaves the easiest recoveries uncollected. Over-retrying dead cards burns transaction fees, trains issuer risk models to like your traffic less, and teaches customers that your brand is the charge that would not stop. There is a ceiling worth respecting as well: attempts across every system touching the card — the platform's native retries plus any recovery layer — should be coordinated under one combined cap, because from the issuer's side there is only one merchant making all of them.

What good looks like in practice: classification the moment a failure lands, a first retry timed to the family, a payday ladder for funds failures that can stretch across the month, an immediate stop and a card-update request for hard declines, and outreach that asks the customer for exactly one action. None of that requires machine learning. It requires treating the retry schedule as a designed system instead of a default.

For a fuller treatment — the day-by-day shape of a decline-aware schedule, stop conditions, and how to compare tools on this dimension — see this overview of payment retry software. It is published by Swipe Again, which sells exactly that discipline as a service across eight billing platforms; the framework it uses to grade schedules, however, grades anyone's, including the one already running in your stack.