When is the right time
to retry a failed
payment?

What is a recovery window?

A recovery window is the span of time — and the sequence of attempts inside it — during which a failed payment can still be collected before the subscription is cancelled or the customer is written off as churned. It starts the moment a charge is declined and typically closes somewhere between day 21 and day 30, depending on the failure code. Inside that window sit two separate levers: the retry calendar (when the processor or your billing system tries the card again) and the dunning calendar (when you email the customer to update their payment method). Get either one wrong — retry too soon and you waste an attempt on a card that hasn't refilled; retry too late and the customer has already moved on — and the window closes with money still on the table.

How retry timing affects recovery rate

The same decline code, retried at the wrong moment, recovers at a fraction of its potential rate. An insufficient-funds decline retried within hours of the original failure succeeds less often than the same decline retried on day 3 — because the underlying cause (no funds in the account) hasn't changed yet. Retry it on day 3–5, near a typical payday cycle, and the success rate roughly doubles. The inverse is also true: a processing-error decline that would resolve itself within hours loses nothing by waiting a day or two — so retrying it instantly, while the issue is still live, captures revenue that a slower fixed schedule would let lapse. Timing isn't a minor optimization on top of the retry — for soft declines, it is the retry strategy.

Optimal retry schedule by decline reason

• • Insufficient funds — first retry day 3, then day 7, day 14, day 21. Spaced to land near payday cycles; success rate falls off sharply after day 21.
• • Do not honor — first retry day 1, then day 3, day 7, day 14. Often a temporary issuer flag that clears within a week, so early retries work better than waiting.
• • Generic decline / processing error — retry within hours, not days. These resolve quickly or not at all, so a fast retry catches the recoverable share before it's gone.
• • Authentication required (3DS) — skip the retry, send an authentication link immediately. No amount of retrying clears a bank-mandated verification step.
• • Expired card / fraudulent — hard stops. No retry schedule applies; the path forward is a card-update request or, for fraud flags, a verified-channel conversation with the customer.

Why most recovery happens in the first 7 days

Across the failure codes that can be retried at all, somewhere around 60–70% of the total recoverable amount typically clears within the first week. There are two reasons for this. First, the easiest-to-fix codes — processing errors, velocity limits, temporary issuer flags — resolve in hours or days, not weeks, so their recovery is front-loaded by nature. Second, customer attention decays: a payment-failure email opened on day 2 gets acted on far more often than the same email read (if it's read at all) on day 18, by which point the customer has often found a workaround or stopped noticing the product is still billing them. The practical implication is that the first week of the window carries disproportionate weight — a schedule that nails the early retries and the first dunning email captures most of what's recoverable; a schedule that's slow out of the gate is trying to make up ground that's already gone.