Payment retries are the most concrete recovery mechanism in subscription billing. Smart retry logic typically recovers 30–50% of failed payments without any other intervention. Poor retry logic — or no retry at all — quietly lets the same revenue slip away.
Fixed vs. smart retries
- Fixed retries — same schedule for every failure (e.g., retry at day 1, 3, 7). Simple to implement, leaves significant recovery on the table.
- Smart retries — schedule varies by decline code, card brand, time of day, and historical success rates. Recovers 15–40% more than fixed retries.
- Time-of-day awareness — retrying at 10 AM weekday outperforms 3 AM weekend. Banks process differently across windows.
- Decline-code awareness — insufficient funds retries align with payday; expired card skips retries entirely and triggers card-updater.
How many retries is the right number
The right answer is 3–4 retry attempts over 7–14 days. More attempts produce diminishing returns and risk triggering card-issuer fraud flags (issuers can flag merchants who repeatedly hammer the same card). Fewer than 3 attempts leaves recoverable revenue uncaptured. The exact number should be tuned per decline code — expired cards should not be retried at all; insufficient funds can support 4 attempts.
The retry-and-recover workflow
- Day 0 — initial charge fails. System reads decline code, classifies failure.
- Day 1 — customer notification email sent. First retry scheduled based on decline code.
- Day 3 — first retry attempt. Often succeeds for insufficient-funds declines as paychecks land.
- Day 7 — second retry attempt. Card-updater service queried if not already done.
- Day 11 — third retry attempt. Second customer notification email.
- Day 14 — final retry attempt. Final notification email with clear consequence.
- Day 14–21 — subscription enters paused state if still unrecovered. Some operators send a win-back offer here.
What to monitor
Track recovery rate (% of failed payments collected within the retry window), time-to-recovery (how fast on average), and retry-attempt success rate (which attempt produces most of the recoveries). The pattern reveals whether your schedule is well-tuned. If most recoveries happen on attempt one, you might be retrying too soon for some decline codes. If most happen on attempt three or four, your early-attempt scheduling is suboptimal. See automated smart retries for the algorithm side and failed recovery for the broader workflow.