Best Time to Retry a Failed Payment (Data-Backed)

The optimal retry schedule

Most payment recovery tools use a one-size-fits-all retry schedule. The data shows that's leaving money on the table. The timing of your retry matters almost as much as whether you retry at all.

Here's the retry schedule that maximizes recovery across thousands of SaaS subscriptions:

• First retry: 24-48 hours after initial failure. This catches temporary holds, daily balance resets, and processing glitches. Success rate: 25-35%.
• Second retry: Day 3-5. This aligns with paycheck deposit cycles. Customers who were short on funds often have money by mid-week. Success rate: 15-25%.
• Third retry: Day 7. The final high-value window. Catches weekly pay cycles and gives customers who received your dunning email time to add funds. Success rate: 10-15%.
• Fourth retry (optional): Day 10-14. Diminishing returns, but still recovers 5-8% of remaining failures. Beyond day 14, retry success drops below 3%.

The compounding effect matters. A 3-retry schedule at these intervals recovers 45-60% of all failed payments automatically. before a single customer service interaction. If you're only retrying once (or letting Stripe handle it with default settings), you're recovering 20-30% less than you could be. See how your current rate compares to the [failed payment recovery benchmarks](/failed-payment-recovery-benchmark).

Timing the first retry is critical. Retrying within the first 4 hours almost never works; the same conditions that caused the failure are still present. Waiting 24-48 hours gives bank systems time to clear holds and customers time to notice the failure notification.

For a deeper look at what happens when Stripe's built-in retries aren't recovering enough, see our guide on [why Stripe Smart Retries may not be working](/stripe-smart-retries-not-working) for your business.

Retry timing by decline type

Not all declines are equal. The reason a payment failed should dictate when and whether you retry. Here's the breakdown:

The key insight: insufficient funds is the most common decline type (40-50% of all failures) and the most recoverable, but only if you wait long enough. Retrying an insufficient funds decline at 24 hours recovers roughly 15%. Waiting 3-5 days bumps that to 35-40% on the first retry alone.

Expired cards and lost/stolen cards should never be retried. Every retry attempt against a known-dead card wastes one of your limited retry windows and can trigger fraud monitoring at the card network level. Instead, send an immediate card update email. Learn [how to send card expiry reminders in Stripe](/how-to-send-card-expiry-reminders-stripe). For a full recovery playbook, see [how to recover failed payments in Stripe](/how-to-recover-failed-payments-stripe).

Processor errors are the exception to the "wait 24 hours" rule. These are usually transient infrastructure issues on the bank or processor side. A retry in 4-6 hours often succeeds because the underlying issue has already resolved.

Day of week matters

Aggregated retry data across SaaS billing platforms reveals a consistent pattern: the day you retry impacts success rates by 15-20%.

Tuesday and Wednesday are the sweet spot. There are two likely reasons: (1) many employers process payroll Monday-Tuesday, so accounts are freshest mid-week, and (2) customers are more engaged with email and notifications on business days, making them more likely to manually resolve issues.

If your retry schedule lands on a weekend, consider shifting it forward to Monday or Tuesday. A 48-hour delay to hit a Tuesday retry is worth more than an on-schedule Saturday retry that's 15% less likely to succeed.

This also affects your dunning email timing. If you send a "your payment failed" email on a Wednesday and retry on Thursday, the customer has time to see the email, check their bank, and ensure funds are available before the retry hits. For guidance on what to do after a failure, see [Stripe payment failed: what to do next](/stripe-payment-failed-what-to-do).

Stripe's retry logic vs custom retry timing

Stripe offers built-in Smart Retries that use machine learning to determine retry timing. Here's what Stripe does automatically and where the gaps are:

What Stripe Smart Retries does:

• Uses ML to pick optimal retry times based on card type, bank, and historical patterns
• Retries up to 4 times over approximately 7-8 days (configurable in billing settings)
• Considers time of day and card network patterns
• Works automatically with no code required

Where Stripe's retries fall short:

• No coordination with dunning emails. Stripe retries independently of your email sequence, so a retry might hit before or after the customer has seen your notification. or at the same time, creating confusion.
• No decline-type differentiation in timing. Stripe's ML optimizes globally, but it doesn't expose per-decline-type scheduling that you can tune for your customer base.
• Limited visibility. You can see retry results in the dashboard, but you can't easily correlate which retry timing worked for which decline types across your subscriber base.
• No day-of-week optimization you control. While Stripe's ML may factor this in, you can't explicitly tell it "always retry on Tuesday."

The hybrid approach works best. Use Stripe's Smart Retries as your baseline, then layer custom retry logic for specific scenarios: pause retries on expired cards, add an extra retry at day 10 for high-value subscriptions, and sync retry timing with your dunning email schedule.

SaveMRR's [Revenue Scan](https://app.savemrr.co) combines intelligent retry scheduling with dunning email coordination. retries fire after the customer has received and (ideally) opened the dunning email, maximizing the chance they've already resolved the issue before the card is charged again.

The retry + email combo

Retries alone recover 30-40% of failed payments. Dunning emails alone recover 15-25%. But the combination. timed correctly. recovers 55-70%. The multiplier effect comes from coordination.

Here's the optimal paired schedule:

• Hour 0: Payment fails. Send dunning email #1 immediately (subject: "Your payment didn't go through").
• Hour 24-48: First retry fires. If the customer read email #1 and added funds, this catches it. If not, no harm.
• Day 3: Send dunning email #2 (subject: "Action needed. update your card"). Include a direct link to update payment method.
• Day 3-5: Second retry fires. Catches paycheck-cycle recoveries and customers who updated their card after email #2.
• Day 7: Send dunning email #3 (subject: "Your subscription will be cancelled"). Urgency framing.
• Day 7: Third retry fires same day or next morning. Final high-probability window.
• Day 10-14: Optional final retry + final warning email. Last chance before cancellation.

The critical rule: always send the email before the retry. Give the customer 12-24 hours to see the email and take action before the retry charges their card. If the retry fires first and fails again, the customer sees two failure notifications, which feels broken and erodes trust.

If your retries are firing but recovery rates are still low, the problem is almost always one of three things: (1) retries aren't synced with emails, (2) card update links are broken or require too many steps, or (3) you're retrying decline types that can't succeed (expired cards, lost/stolen). Start by auditing your decline-type mix. That alone can shift recovery rates by 10-15%.

For a comprehensive walkthrough of the full recovery process, see [how to recover failed payments in Stripe](/how-to-recover-failed-payments-stripe) and use the free [Revenue Scan](https://app.savemrr.co) to see exactly where your retry + email combo is leaking revenue. Calculate the dollar impact with the [failed payment recovery calculator](/failed-payment-recovery-calculator) and the [dunning ROI calculator](/dunning-roi-calculator). Compare the [best dunning software for Stripe](/best-dunning-software-stripe) and see how [SaveMRR differs from Stripe Smart Retries](/savemrr-vs-stripe-smart-retries) for a complete picture. Understanding [what involuntary churn is](/what-is-involuntary-churn) will help you contextualize why retry timing matters so much to your [MRR](/what-is-mrr).

Sources: Stripe billing documentation (2025), Recurly State of Subscriptions report, Chargebee retry benchmarks, Baremetrics aggregate SaaS data, SaveMRR internal recovery analytics.