Payment Retry Best Practices: Maximize Recovery Without Annoying Banks

Many billing systems default to retrying every 24 hours for 3-5 days. This simple approach recovers some charges, but it leaves money on the table by ignoring the mechanics of bank processing.

Banks process transactions in batches, typically overnight. A charge that fails at 3:00 PM may succeed at 6:00 AM the next day — not because anything changed on the customer's end, but because the bank's batch processing cleared a hold or updated a limit.

Insufficient funds declines follow payroll cycles. In the US, most people are paid bi-weekly on Fridays or semi-monthly on the 1st and 15th. A retry timed to land after a likely payday has a significantly higher success rate than one that lands mid-week.

Processing errors and network timeouts are the fastest to recover. These are infrastructure failures, not customer issues. Retrying within 1-4 hours almost always succeeds.

The takeaway: an intelligent retry schedule that adapts to decline codes and timing windows outperforms a fixed-interval schedule by 20-30% in recovery rate.

Based on aggregate recovery data from Stripe merchants, here is an optimized retry schedule.

Attempt 1 — 1 hour after failure. Catches processing errors, network issues, and quickly-resolved bank holds. Expected recovery: 15-20% of failures.

Attempt 2 — 24 hours after failure. Bank batch processing has completed. Daily spending limits have reset. Fraud checks have been reviewed. Expected recovery: 12-18% of remaining failures.

Attempt 3 — 3 days after failure. First payday window. Also gives time for card-not-present fraud alerts to be cleared by the cardholder through their banking app. Expected recovery: 8-12% of remaining.

Attempt 4 — 5 days after failure. Second payday window. Customers who saw a payment failure notification in their bank app have had time to add funds. Expected recovery: 5-8% of remaining.

Attempt 5 — 7 days after failure. Final retry before most dunning windows close. Recovery from customers who respond slowly or needed to contact their bank. Expected recovery: 3-5% of remaining.

Cumulative recovery from retries alone: 40-55%. This schedule forms the foundation of Revive's retry engine.

Not every decline should be retried the same way. Routing retries based on the specific Stripe decline code dramatically improves efficiency.

For insufficient_funds: maximize retries, focus on payday timing. This code has the highest recovery rate because the underlying cause (temporary low balance) resolves naturally.

For processing_error: retry quickly (within hours) and expect high success. This is a technical failure, not a customer issue.

For card_declined (generic): retry at the standard schedule. The generic code often masks a temporary hold that resolves within 24 hours.

For expired_card: do not retry. The card will never work again. Immediately send a recovery email asking the customer to update their payment method.

For stolen_card, lost_card, or fraudulent: do not retry under any circumstances. These cards are permanently blocked and retrying can flag your merchant account.

For authentication_required: do not retry — send a payment link that includes the 3D Secure authentication flow.

Revive handles all of this routing automatically. When a Stripe webhook delivers a payment failure, Revive reads the decline code and routes the charge to the appropriate recovery path without manual configuration.

Banks track authorization attempt rates and decline rates for every merchant. A merchant who repeatedly retries charges that banks have firmly declined risks reduced approval rates across all transactions — not just the retries.

Follow these rules to protect your merchant reputation.

Never retry stolen_card, lost_card, or fraudulent declines. These are hard declines and retrying signals suspicious behavior to the bank.

Limit total retries to 5-7 per charge. Beyond that, the probability of recovery is near zero and the risk of merchant flag increases.

Space retries at least 4 hours apart. Rapid-fire retries (every few minutes) look like a brute-force attack to bank fraud systems.

Honor do_not_honor codes after 2 attempts. If the bank has firmly declined twice with this code, further attempts are unlikely to succeed and may escalate to a merchant review.

Monitor your overall retry-to-success ratio. If fewer than 10% of retries are succeeding, your retry strategy is too aggressive. If more than 40% are succeeding, you may be under-retrying and leaving money on the table.

Retries alone recover 40-55% of failed charges. Adding customer-facing recovery emails pushes that to 60-75%. The emails catch the cases retries cannot fix — primarily expired cards and account changes.

The key is timing the email relative to retries. Send the first email after the second retry attempt (roughly 24 hours after failure). This ensures you are not emailing customers about problems that resolve silently through retries.

Do not email on every retry attempt. Customers who receive 5 'payment failed' emails in a week will unsubscribe, block your sender, or feel harassed. Two to three emails over the dunning window is the sweet spot.

Include a direct payment update link in every email. The fewer clicks between reading the email and entering a new card, the higher the conversion rate. Stripe's Customer Portal or a hosted payment page works well for this.

Revive coordinates retries and emails into a single sequence. Emails only send when retries have not resolved the issue, and they include a pre-built payment update flow that makes it effortless for customers to fix the problem.