Retry logic is the rule set that decides whether a declined payment is attempted again, when, how often and when to stop, acting as the scheduling engine inside a decline recovery program driven by authorization response codes. Each code gets its own treatment: timeouts retry within minutes, insufficient funds when the account is likely refilled, do-not-honor over days, and final codes never. A monthly charge might use four attempts across two weeks, ending in cancellation or manual collection. Card networks cap re-presentments per declined transaction and fine acquirers for excess, costs that reach merchants. Idempotency keys prevent duplicate charges from lost responses, and a clear customer message about the next attempt recovers more than extra retries.
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.