The Best Time to Retry Failed Payments (Based on Data)

A failed payment retried at the wrong time stays failed. The same payment retried at the right time often succeeds. The difference isn't luck. It's understanding why the payment failed and when the conditions that caused the failure are most likely to change.

Retry timing is one of the highest-leverage variables in payment recovery. You're not changing the product, the price, or the customer relationship. You're just changing when you ask for the money. And that alone can swing recovery rates by 20-30 percentage points.

Why timing matters

Most payment failures are temporary. Recurly's data shows that 60-70% of declines are soft declines: insufficient funds, bank fraud flags, processing errors, velocity limits. These are all conditions that change with time.

A customer whose checking account is low on the 28th of the month likely has funds on the 1st after payday. A bank's fraud detection that flagged an unusual charge at 2 AM often clears by business hours. A processing error during peak traffic resolves when load drops.

The question isn't whether to retry. It's when.

Time of day

Payment success rates aren't uniform across the 24-hour cycle. Bank systems, fraud algorithms, and customer account balances all have daily patterns.

Morning retries outperform evening retries by a meaningful margin. The 9 AM to noon window consistently shows the highest success rates across multiple data sets. This aligns with when banks are fully staffed, fraud review teams are active, and daily transaction limits have freshly reset.

For B2B SaaS specifically, morning retries (9-11 AM in the customer's timezone) perform even better because corporate card systems tend to have more robust processing during business hours.

One practical consideration: if your customers span multiple timezones, a single retry time won't be optimal for everyone. Stripe's Smart Retries account for this. If you're building custom retry logic, segment by timezone when possible.

Day of week

Weekly patterns exist, though they're less pronounced than daily patterns.

Weekdays outperform weekends, with Tuesday showing the strongest results. The weekend dip isn't dramatic, but it's consistent. If you have flexibility in scheduling a retry, pushing a Saturday retry to Monday morning tends to perform better.

The weekend effect is more pronounced for international payments. Some banking systems in certain regions have reduced weekend processing capabilities, and cross-border transactions that require manual fraud review get delayed.

Payday cycles and monthly patterns

This is where the data gets most actionable, especially for insufficient_funds declines.

US payday patterns

Most US employees are paid on one of these schedules:

• Bi-weekly (every two weeks): 36% of workers
• Weekly: 32% of workers
• Semi-monthly (1st and 15th): 19% of workers
• Monthly: 13% of workers

This means the 1st-5th and the 15th-20th of each month are when the most bank accounts have fresh deposits. Retry attempts during these windows see measurably higher success rates for insufficient funds declines.

The end of the month (26th-31st) is the worst time to retry an insufficient funds decline. Accounts are at their lowest, bills have been paid, and payday hasn't arrived yet. If a payment fails on the 27th, waiting until the 1st or 2nd to retry can double the success rate for this decline type.

For non-US customers

Payday patterns vary by country. In the UK, monthly pay on the last working day of the month is most common. In many European countries, salaries arrive around the 25th-28th. In Australia, bi-weekly and monthly pay cycles are standard.

If you have a geographically diverse customer base, analyzing your own retry success data by day of month will reveal the patterns specific to your audience.

Optimal spacing between retries

How long should you wait between retry attempts? Too short and you're hitting the same problem. Too long and you're leaving money on the table.

First retry

The key insight: match retry timing to the decline reason. A processing error that gets retried in 3 hours has a much higher success rate than one retried in 3 days (by which point the customer may have moved on). An insufficient funds decline retried 3 hours later will almost certainly fail again.

Full retry sequence

Here's a retry schedule that balances speed with strategic timing, assuming a soft decline:

Four retries over two weeks captures most of the recoverable payments. Adding retries beyond this point yields diminishing returns (1-2% additional recovery per attempt) and risks excessive failed charge fees from some processors.

Stripe Smart Retries: what they do and don't do

Stripe's Smart Retries use machine learning across their entire payment network to determine optimal retry timing. They analyze patterns from billions of transactions to predict when a specific decline type, card network, and issuing bank combination is most likely to succeed.

What Smart Retries handle well:

• Optimal retry timing based on card network signals
• Day-of-week and time-of-day optimization
• Decline code-specific retry logic
• Network-level data that individual merchants can't access
• Automatic adjustment for regional banking patterns

What Smart Retries don't handle:

• Customer communication (no emails or SMS)
• Payment method updates (can't ask for a new card)
• Hard declines (retrying an expired card won't help)
• Custom business logic (your specific billing cycle insights)
• Transparency (you can't see or override the retry schedule)

Smart Retries recover roughly 10-15% of failed payments automatically. That's meaningful, and it's essentially free since it's built into Stripe's subscription billing. But it leaves 40-50% of recoverable revenue on the table because it can't communicate with customers or collect new payment information.

The best approach: use Smart Retries as your baseline and layer dunning on top. Smart Retries handle the automated retry timing. Dunning handles everything else: customer notification, payment link delivery, SMS reminders, and the human side of recovery.

When custom timing beats automated

There are scenarios where you know more than the algorithm.

You know your billing cycle. If you bill on the 1st and a payment fails, you know the customer might have already been charged by other subscriptions that day. Retrying on the 3rd or 4th, when the account has recovered, may outperform a generic model.

You know your customer segment. Enterprise customers with corporate cards almost never have insufficient funds issues. Their failures are more likely fraud flags or card updates. Retrying quickly (within hours) works better than waiting for payday.

You know seasonal patterns. If your business has a seasonal revenue cycle (tax season for accounting tools, back-to-school for edtech), you can anticipate when customers are more or less likely to have funds available.

You know about external events. Major holidays, bank holidays, and payroll cycles specific to your customer base are information advantages. The algorithm learns these patterns eventually, but slowly.

For most SaaS businesses, relying on Smart Retries for timing and adding your own dunning layer for communication is the right balance. But if you have strong data on when your specific customers are most likely to pay, building that into your retry logic can add 5-10% on top.

Putting it together: a practical retry + dunning schedule

Here's how retry timing and dunning work together in an effective recovery sequence:

The retries and dunning emails interleave so that each retry attempt happens after a dunning touch. The customer may update their card in response to an email (making the next retry succeed on a new card), or the retry may succeed on the original card (making the next dunning email unnecessary).

This parallel approach of retrying while dunning consistently outperforms either strategy alone. The data across Recurly and Baremetrics benchmarks shows a 60-80% total recovery rate for combined retry + dunning, compared to 40-55% for retries alone and 35-50% for dunning alone.

What to measure

Track these metrics to evaluate and improve your retry timing:

• Recovery rate by retry attempt. How much does each retry add? If retry 3 and 4 are contributing less than 2% each, you may not need them.
• Recovery rate by decline code. Your insufficient_funds retries should recover at 50%+ over the full sequence. If they don't, your timing is off.
• Recovery rate by time of day. If you're retrying at a fixed time, test shifting it to morning.
• Days to recovery. The shorter the better. If most recoveries happen on retry 1 (day 1-2), your first retry timing is good.

Small adjustments to retry timing add up. A 5% improvement in retry success across thousands of monthly failures translates directly to MRR saved.