Retry logic

Retry logic is the rule set that decides whether a declined payment is attempted again, when, how often, and at what point to stop. It is the scheduling engine inside a wider decline recovery program, and it works off the response code returned with the failed authorization.

16 October 20253 min read

Retry logic is the rule set that decides whether a declined payment is attempted again, when, how often, and at what point to stop. It is the scheduling engine inside a wider decline recovery program, and it works off the response code returned with the failed authorization.

One rule per decline code

A single interval applied to everything is not retry logic. Each code earns its own treatment. A network timeout is retried within minutes, because nothing was wrong with the card. An insufficient-funds decline is retried when the account is likely to hold money again. A do-not-honor response is spaced over days, since issuer behavior shifts slowly and repeated attempts inside one day look like probing. Codes marked final are never retried at all.

A ladder, not a loop

A workable schedule for a monthly charge is four attempts across two weeks: day one, day three, day seven, day fourteen, then stop. Widening gaps give balances time to change and keep the attempt count inside scheme limits. Anchoring one attempt to common salary dates lifts recovery on insufficient-funds codes more than adding further attempts does.

The stop matters as much as the schedule. Every ladder needs a terminal state that moves the account into cancellation or manual collection, which is why subscription billing systems pair retries with a dunning end date.

Scheme caps and the fines behind them

The card networks limit how many times the same declined transaction may be re-presented, with the limit varying by decline reason, and they fine acquirers for excess attempts. Those fines reach the merchant. Compliant retry logic counts attempts against the original transaction rather than against the invoice, resets the counter only when the amount or the credential actually changes, and refuses to submit past the cap.

Retrying a payment that already succeeded

The costliest failure is not a missed recovery but a duplicate charge: a response lost in transit, read as a decline, retried, and taken twice. Idempotency keys on every attempt and reconciliation against the provider's record rather than the local one prevent it. A customer charged twice disputes both charges, and the dispute flow costs more than the recovery was ever worth.

Retries the customer can see

Each failed attempt can trigger a notification from the customer's own bank, so a silent five-attempt ladder reads as a run of unexplained failures. Pairing retries with one clear message, covering what will be charged, when the next attempt runs and how to update the payment method, recovers more than the attempts alone. Replacing a dead credential always beats hammering it.

Comments

Related terms