When to Retry Failed Stripe Payments: Optimal Timing by Decline Type

The question isn't whether to retry a failed Stripe payment. The question is when — and the answer depends entirely on why it failed.

Retry an insufficient_funds decline too early and you catch the customer at the same low-balance point. Wait too long and you lose the window before they churn. Retry an expired_card at all and you're burning attempts on a dead card. These are fundamentally different problems, and the optimal timing for each looks nothing alike.

Most SaaS companies set up Stripe Smart Retries, maybe tweak the schedule once, and move on. Smart Retries are better than fixed schedules, but they're a black box — you can't customize behavior by decline type, and they don't coordinate with your dunning emails. Once you're at the volume where a few percentage points of recovery rate means real money, you need more precision.

Understanding the Decline Type Distribution

Before getting into timing, worth knowing what you're working with. Most subscription payment failures cluster into a few buckets:

Insufficient funds — roughly 40-50% of all failures in most SaaS billing setups
Card-related issues (expired, replaced, wrong CVV) — 25-30%
Issuer/bank declines (fraud flags, velocity limits, regional restrictions) — 15-20%
Processing errors and other — 5-10%

insufficient_funds is the most common code we see across RetryKit's connected accounts. That's the good news — it's highly retriable. The challenge is timing.

Insufficient Funds: The 24-Hour Window Matters Most

insufficient_funds is recoverable because the customer wants to pay. The card is valid. They just didn't have the balance at the moment of charge.

Recovery rates for this decline type vary significantly by timing:

4-6 hours after failure: ~15% recovery. Some customers get a direct deposit or transfer that clears quickly.
24 hours after failure: ~35% recovery. Best single-retry window. Daily balance resets, pending transfers, and payday deposits all converge here.
48-72 hours after failure: ~20% recovery. Still worth attempting, but declining returns.
7+ days: Below 10%. At this point, retries alone aren't going to move this. You need the customer to take action.

We run our retry schedule at RetryKit on: 1 day, 3 days, 5 days, 7 days, 14 days. The 24-hour first retry catches the overnight balance reset. The 3-day retry targets Friday if the initial failure was on Tuesday (payday proximity). The 5-day and 7-day attempts extend coverage for monthly payroll cycles.

A $5.99 invoice we recovered is a good illustration: insufficient_funds on the initial attempt, three retries over 5 days, went through on the 4th attempt. That's the schedule working as intended — not brute-forcing the same window over and over, but spacing attempts to hit different balance moments.

The worst pattern for insufficient_funds is retrying every 24 hours for two weeks straight. After the first 72 hours, flat daily retries have diminishing returns. Beyond day 3, the customer needs to either have received a deposit or be prompted to manually fix the billing. Your dunning emails should be running by then.

Expired and Replaced Cards: Mostly Don't Retry, But Wait 48 Hours First

Retrying an expired card is almost always pointless. The number is dead.

The important caveat: Stripe's Account Updater can propagate new card details from the card network, but there's a propagation lag of roughly 24-48 hours. One retry at 48 hours is worth doing just to capture cards that were auto-updated after the failure. Recovery rate on that first retry: ~25-30%.

After that, stop retrying. Move to email-based recovery immediately.

Here's why that works: card-related failures have some of the highest email conversion rates in dunning. These customers didn't cancel. Their card expired. They didn't know. A clear, direct email with a one-click update link converts at extraordinary rates — 60-75% is achievable here when the email is sent quickly and removes all friction.

Second retry at 5-7 days catches slower bank updates and customers who received a new physical card and activated it after the initial failure. But beyond that, you're chasing diminishing returns when the email path is more effective.

The pre-expiration approach is even better: Stripe fires a customer.source.expiring webhook 30 days before a card expires. If you send a proactive "your card expires soon" email at that point, many of these failures never happen at all.

Issuer Declines: The Velocity Trap

Issuer declines are the hardest category because the reason is often opaque. generic_decline or do_not_honor tells you the bank said no, but not why. Could be a fraud flag, a daily spending limit, a geographic restriction, or something bank-specific that'll clear tomorrow.

Recovery timing:

First retry at 24 hours: ~18-22% recovery. Fraud flags reset. Daily limits reset. Temporary holds clear.
Second retry at 72 hours: ~12% recovery. Catches holds that take longer.
Third retry at 7 days: ~8% recovery. Last automated attempt before purely manual intervention.

After three failures across seven days, further retries start creating a real problem: velocity flags. If a bank sees the same merchant hitting the same card 5+ times in a week, it may start declining charges from your entire merchant account — not just the problematic card. This is a meaningful risk most teams don't think about until it's causing them headaches.

Space it out. Three attempts over seven days maximum for issuer declines.

Processing Errors: Hit Them Fast

Processing errors — processing_error, network timeouts, transient Stripe issues — are different from the above. These are infrastructure hiccups, not customer-side problems.

Aggressive retry timing:

1 hour after failure: ~30% recovery
6 hours: ~20% additional recovery
24 hours: ~10% additional

These should be cleared fast because they're usually resolved quickly. If three fast retries don't work, the problem has likely shifted from transient to something else — escalate to the normal dunning path.

The Practical Retry Schedule

| Decline Type | Retry 1 | Retry 2 | Retry 3 | After That | |---|---|---|---|---| | Insufficient funds | 24 hours | 3 days | 5 days | Dunning email + retry at 7/14 days | | Expired/replaced card | 48 hours (Account Updater window) | 5 days | — | Dunning email; stop retrying | | Issuer decline | 24 hours | 72 hours | 7 days | Dunning email; flag if still open | | Processing error | 1 hour | 6 hours | 24 hours | Dunning email |

Coordinating Retries with Dunning Emails

The highest-performing recovery systems don't choose between retries and emails — they run them together, with retries informing when emails fire.

At RetryKit, we send dunning emails at retry 2 and retry 4. Not at a fixed time offset from the original failure, but timed relative to actual retry attempts. This matters because:

If retry 1 succeeds, no email should fire. Emailing about a problem that's already resolved creates confusion.
If retry 2 fails, the customer now has two data points that suggest they need to act. That's when the first email is warranted.
By retry 4, if you're still failing, the problem is almost certainly not going to resolve on its own. That's the second dunning email — more urgent, with a clear deadline.

The silent retry window is typically the first 24-48 hours. Most customers never need to know a payment failed because it recovers on its own. Only surface the issue in email once the automated system has genuinely exhausted the quick wins.

Track Your Own Numbers

The timing data above reflects industry patterns and what we observe across RetryKit's connected accounts. Your actual recovery rates depend on your customer base, pricing, card mix, and geography. One connected account we have in France shows different insufficient_funds recovery timing than our UK-based account — payroll cycles differ, banking systems differ.

The only way to actually optimize is to log every failure with its decline code, every retry with its outcome, and every email with its conversion rate. Segment by decline type. Iterate on timing per bucket. Industry averages are a starting point, not a ceiling.

If building and maintaining this infrastructure doesn't sound like a good use of your engineering time, that's exactly what RetryKit handles — automatic decline classification, timing-optimized retries, coordinated dunning emails, and a dashboard to track recovery rates by decline type. It connects to Stripe in minutes and starts recovering revenue immediately, including a scan of your historical failed invoices to surface what's been sitting unrecovered.

Treat different failures differently. The recovery rate difference is the difference between paying for your tools out of recovered revenue and watching that revenue evaporate.