Most failed-payment recovery advice obsesses over how many times to retry a card. In our experience running recovery, the count matters far less than the calendar. A retry fired at the wrong moment teaches the issuer nothing new; the same retry fired at the right moment goes through — because something about the cardholder's situation actually changed in between.
Here is the timing logic we use, and why.
A decline is a sentence, not a verdict
Every failed charge comes back with a decline code, and the code tells you whether time can help at all:
- Hard declines (stolen card, closed account, do not honor) will not heal with time. Retrying them wastes attempts and can hurt your standing with the processor. These need a new card, full stop — the recovery move is a fast, clear card-update request.
- Soft declines (insufficient funds, temporary holds, issuer timeouts) are conditions, and conditions expire. The question is never whether to retry — it is when the condition is most likely to have changed.
Treating both classes with the same fixed schedule ("retry on days 1, 3, 5, 7") is how most dunning setups burn their best attempts before the money is actually there.
Insufficient funds runs on payday physics
The most common soft decline in subscription billing is insufficient funds. Accounts do not refill randomly — they refill on payroll cycles. That suggests a ladder, not a metronome:
- A first retry a day or two out catches the near-misses (a deposit that landed late).
- Subsequent retries should widen — spacing attempts so they land on different points of the pay cycle rather than hammering the same empty window three days running.
- Extending the ladder out toward ~day 25 covers monthly pay cycles without exceeding sensible attempt ceilings.
If your retry plan for insufficient funds fits inside a single week, it is structurally incapable of catching a monthly-paid customer whose card failed on day 2.
Coordinate with the platform's own retries
Modern billing platforms retry failed charges themselves. If your recovery layer fires on its own schedule without looking at the platform's, two bad things happen: you duplicate attempts (annoying the issuer and the customer), and you can collide with a native attempt that was about to succeed.
The approach that works is to weave, not to race:
- Before firing, re-read the live invoice state. If the platform has an attempt scheduled within roughly the next 24 hours, defer — let it run, then reassess.
- If the platform's schedule has a real gap, fire into the gap.
- Keep a combined ceiling across both systems, and reserve a few of your own attempts for late in the window rather than spending them all early.
This is the model we ship: our engine reads Stripe's attempt_count and next_payment_attempt before every decision, defers when a native attempt is imminent, and fires into gaps while holding attempts in reserve. (We wrote up the broader philosophy in how Swipe Again works; the Stripe-specific tuning notes live on our Stripe dunning page.)
The email is part of the timing system
Retries are invisible. The card-update email is what the customer sees — and its timing should be tied to the retry ladder, not sent on a separate fixed cadence. An update request that lands right after a decline, while the failure is still fresh, converts. The same email on day 9, after three silent retries, reads like a surprise cancellation notice.
One more practical point: whichever attempt succeeds — yours, the platform's, or a card update from the customer — everything downstream needs to reconcile to a single recovery event. Double-counted "recoveries" make for great dashboards and terrible decisions.
The short version
- Read the decline code before choosing a schedule.
- Never retry hard declines; route them to card update immediately.
- Space insufficient-funds retries across the pay cycle, out to roughly day 25.
- Weave around the platform's native retries instead of racing them.
- Tie customer emails to the ladder, and reconcile every recovery to exactly one event.
Retry count is a budget. Timing is how you spend it.
Top comments (0)