Best Payment Retry Schedule for Stripe (Data-Backed)

Stripe's Smart Retries feature uses machine learning to determine retry timing. It is a significant improvement over the old fixed-schedule retries, and for businesses that do not want to think about retry logic at all, it is a reasonable default. But it has structural limitations that cap its effectiveness.

First, Smart Retries optimizes for Stripe's overall retry success rate across all their merchants, not specifically for your business. The model is trained on aggregate data, which means it applies population-level timing to your individual customers. If your customer base has unusual payday patterns (contractors who get paid weekly, international customers in different economic cycles, or enterprise clients who process payments on specific accounting schedules), the aggregate model may not serve you well.

Second, Smart Retries operates within the constraints of your billing settings. If you have configured 4 retries over 3 weeks, Smart Retries will pick the best times within that window. But it cannot extend the window, add more retries, or coordinate with your recovery emails. The retry and the email are independent systems in Stripe — there is no built-in logic to suppress an email when a retry is about to fire, or to accelerate an email when all retries have failed.

Third, Smart Retries does not differentiate by decline code as aggressively as the data suggests it should. A processing_error retry should fire within hours — the card is fine, the bank had a hiccup. An insufficient_funds retry should fire days later, aligned with payday cycles. A generic card_declined retry might benefit from a 48-hour cool-off period where bank fraud flags clear. Smart Retries makes some of these distinctions, but a custom schedule can be more precise.

The data from payment recovery platforms (including aggregated benchmarks from Baremetrics, ProfitWell, and Churnbuster) consistently shows that custom retry schedules outperform Smart Retries by 10-20% in total recovery rate. For a business with $100K MRR and 5% monthly payment failure rate, that is $500-1,000/month in additional recovered revenue.

Here is the decline-code-specific retry schedule that maximizes recovery based on aggregate data from SaaS payment recovery.

insufficient_funds / card_velocity_exceeded: Retry 1: 3-5 days after failure (aligned with the next payday cycle — targeting Monday or Friday for US customers). Retry 2: 7-8 days after failure (next payday cycle if biweekly). Retry 3: 12-14 days after failure. Expected recovery: 50-65% across all retries.

The key insight for insufficient funds is that same-day or next-day retries almost never work. The customer's bank balance was too low today and will likely be too low tomorrow. You need to wait for income to hit the account. US payroll cycles cluster on the 1st and 15th of each month (for salaried employees) and on Fridays (for hourly/weekly employees). Timing your retry to land on or just after these dates significantly improves success rates.

processing_error / try_again_later / reenter_transaction: Retry 1: 2-6 hours after failure. Retry 2: 24 hours after failure. Retry 3: 48 hours after failure. Expected recovery: 80-95% across all retries.

These are infrastructure failures, not card or account problems. The faster you retry, the better. Most processing errors clear within hours. Waiting days to retry a processing error is leaving easy money on the table.

card_declined (generic) / do_not_honor: Retry 1: 24-48 hours after failure. Retry 2: 5-7 days after failure. Retry 3: 10-12 days after failure. Expected recovery: 30-45% across all retries.

Generic declines are unpredictable because the bank will not tell you why the charge was blocked. A 24-48 hour gap before the first retry allows any temporary fraud flags to clear. The subsequent retries are spaced to catch both short-term holds and payday-cycle recoveries.

authentication_required: Do not retry automatically. Send a payment link with embedded 3DS challenge instead. Recovery through payment link: 55-70%. Blind retries without authentication: under 5%.

expired_card / stolen_card / lost_card: Do not retry. These are hard declines. Send a recovery email with a payment update link instead. Recovery through email: 25-40%.

Beyond spacing retries correctly, the specific time and day you retry matters more than most founders realize. Aggregate data shows consistent patterns that can add 5-15% to your retry success rate.

Best time of day for retries: 6-10 AM in the cardholder's timezone. Morning retries outperform afternoon and evening retries by 8-12%. The likely explanation is a combination of factors: bank fraud systems are less sensitive during normal business hours, customers are more likely to have recently interacted with their bank (checking balances, reviewing alerts), and any overnight holds or flags have had time to process.

The worst time for retries is 1-4 AM. Bank batch processing often runs during these hours, and fraud detection systems tend to be more aggressive with off-hours transactions. If your cron job fires retries at 2 AM UTC and your customers are in the US, you are retrying at the worst possible time.

Best days for retries: Tuesday through Thursday. Weekday retries outperform weekend retries by 5-10%. Monday can be volatile — some banks process weekend backlogs on Monday morning, which can temporarily tighten fraud filters. Friday is decent but runs into the risk of weekends delaying any customer-side actions.

Payday alignment for the US market: The 1st, 15th, and every other Friday are common paydays. If your customer base is primarily US-based, targeting these dates for insufficient_funds retries adds 10-20% to your recovery rate for that specific decline code. This is the single most impactful timing optimization available.

International considerations: Payday patterns vary by country. UK paydays tend to cluster at the end of the month (25th-28th). Germany commonly pays on the 1st. Australia pays biweekly on varying days. If you have a multinational customer base, you either need timezone and country-aware retry logic, or you accept that a US-optimized schedule will be suboptimal for international customers.

Practical implementation: If you are building custom retry logic, use the customer's billing address (available through Stripe's Customer object) to determine timezone and likely payday patterns. If you are using a recovery tool like Revive, this optimization is built in and applied automatically.

A retry schedule is not something you set once and forget. Payment patterns shift with economic conditions, card network policy changes, and your own customer base evolution. Measuring retry performance and iterating is essential.

Key metrics to track:

Recovery rate by retry number: What percentage of charges are recovered on the 1st retry, 2nd retry, 3rd retry, and 4th retry? Healthy patterns show 30-40% recovery on the first retry, 20-30% on the second, 10-15% on the third, and 5-10% on the fourth. If your first retry is recovering less than 25%, your timing is off. If your fourth retry is recovering more than 10%, you might benefit from adding a fifth.

Recovery rate by decline code: Track recovery rates separately for each decline code. If your insufficient_funds recovery is under 45%, your payday alignment is probably wrong. If your processing_error recovery is under 75%, you are waiting too long for the first retry.

Time-to-recovery distribution: How many hours/days after the initial failure does the average recovery occur? If the distribution is bimodal (peaks at day 1 and day 5, for example), your retry schedule should align with those peaks. If the distribution is smooth and declining, your spacing is reasonable.

False negative rate: How often does a retry fail on the second-to-last attempt but succeed on the final attempt? If this happens frequently, your earlier retries may be too early, and adding a later retry would recover more.

Decline rate trend: Monitor your overall decline rate month over month. If it is increasing, something external has changed — a card network policy update, a new fraud detection algorithm at a major bank, or a shift in your customer demographics. Seasonal effects also matter: decline rates typically rise in January (post-holiday spending) and in late summer.

A/B testing retry schedules: If you have enough volume (1,000+ failed payments per month), you can A/B test retry timing. Split your failed payments into cohorts and apply different retry schedules. After 4-6 weeks, compare recovery rates. Even small improvements (2-3 percentage points) compound significantly over time.

Building and maintaining a custom retry schedule requires webhook handling, cron job management, decline code parsing, timezone-aware scheduling, and ongoing performance monitoring. It is the kind of infrastructure that is critical for revenue but does not differentiate your product.

Revive handles all of it. When a payment fails, Revive reads the decline code, determines the optimal retry timing based on the code type and the customer's billing profile, and schedules retries accordingly. Processing errors get retried within hours. Insufficient funds get retried on the next payday-aligned date. Hard declines skip the retry queue and go straight to recovery emails.

Revive also coordinates retries with email outreach. If a retry is scheduled for tomorrow, Revive holds the recovery email until the retry result is known. If the retry succeeds, the email never sends. If it fails, the email goes out immediately. This prevents the frustrating experience of receiving a 'please update your card' email for a charge that was successfully retried.

The retry schedule adapts over time based on your specific recovery data. As Revive accumulates performance data for your account, it fine-tunes timing to match your customer base's patterns.

Connect Stripe at [/api/connect](/api/connect) and Revive applies the optimal retry schedule to your next failed payment.