Designing a Payment Retry Schedule That Recovers More

Retry logic is the least glamorous part of a subscription business and one of the most consequential. Good retry design recovers a substantial share of failed renewals. Bad design irritates customers and can attract network-level penalties.

The default that works

Four attempts over roughly two weeks:

Attempt	When	Paired email
1	Day 0 — the scheduled charge	—
2	Day 2	Email 1: helpful notice
3	Day 6	Email 2: firmer
4	Day 13	Email 3: final attempt notice

Then a defined outcome: pause or cancel, with the customer told which.

Beyond four attempts the recovery curve is essentially flat, and continued retries increase your decline ratio — which some processors and networks care about.

Skip retries that cannot succeed

This is the highest-value refinement and the one most commonly missed.

Retry these: insufficient funds, do-not-honour, issuer temporarily unavailable, generic processing errors. The condition may change.

Do not retry these: expired card, invalid card number, card reported lost or stolen, closed account, revoked mandate. Nothing about a second attempt changes the outcome.

For the second group, go straight to the email. Retrying an expired card three times delays the fix by two weeks and teaches the customer that your system is broken.

Time around pay cycles

Insufficient-funds declines cluster before payday and clear after it.

If your subscribers are salaried and paid monthly — which in India is the strong default — a retry scheduled for the 1st or 2nd recovers materially better than the same retry on the 28th.

A simple version of this: if attempt 1 falls in the last week of the month, schedule attempt 2 for the 1st rather than at a fixed +2 day offset.

Do not retry everything at midnight

Two problems with a single nightly batch:

Gateway rate limits. A burst of thousands of charges can produce throttling errors that look like declines and pollute your data.

Concentrated support load. Every dunning email goes out simultaneously, so every reply arrives simultaneously.

Spreading retries across a window smooths both.

Mandate-aware retries

In India, a failure caused by the mandate — revoked, expired, or amount exceeded — is not a payment problem and no retry schedule will fix it. Those need re-authorisation.

A retry system that does not distinguish mandate failures from funds failures will burn its entire sequence on contracts that could never have succeeded, and then cancel a customer who would have happily re-authorised if asked. More.

What to do at the end

Pick one and be consistent:

Pause the subscription. Contract survives, customer can resume in one click, reporting stays clean if you count paused separately. Best default for consumer subscriptions.

Cancel with easy resubscribe. Cleaner, slightly lower recovery.

Never: leave it retrying indefinitely.

Instrument it

Record, for every failed renewal: the decline code, each attempt with its outcome, which emails were sent and opened, and the final state.

Without that you cannot tell whether a low recovery rate is a retry-timing problem or an email problem, and those have opposite fixes.

Super Subscription varies its retry behaviour by decline reason and separates mandate failures from funds failures in both retries and reporting. See how it works.