What is the average recovery rate for failed Stripe payments?

Stripe's Smart Retries alone recover about 35% of failed payments. Adding a multi-email dunning sequence brings recovery to around 55%. The best-performing SaaS companies layer on pre-dunning alerts and in-app banners to reach 60-70% recovery rates.

Why do subscription payments fail on Stripe?

The most common reasons are expired cards (25-30% of failures), insufficient funds (20-25%), generic bank declines (15-20%), and processing errors (5-10%). Expired cards are the most recoverable since the customer just needs to enter new card details. Insufficient funds often resolve on retry a few days later.

How many dunning emails should I send for a failed payment?

Send at least 4 emails over 14 days: day 0 (friendly notice), day 3 (reminder with urgency), day 7 (account pause warning), and day 14 (final notice signed by the founder). Each email should include a direct link to update the payment method via Stripe's Billing Portal. This 4-email sequence recovers 15-25% more than Stripe's single default email.

How do I create a card update link for dunning emails?

Use Stripe's Billing Portal API: call stripe.billingPortal.sessions.create() with the customer ID and a return URL. The resulting session.url is a hosted page where the customer can update their card. After updating, Stripe automatically retries the failed invoice with no additional code needed on your end.

Can I recover failed payments manually in Stripe Dashboard?

Yes. Go to Payments > All payments, filter by 'Failed,' click the failed payment to see the decline reason, then retry the invoice or send the customer a payment link. This works for small volumes under 10 failures per month, but does not scale. For anything beyond that, you need automated dunning via webhooks or a dedicated tool.

Recover Failed Payments on Stripe

Recover failed payments on Stripe by combining Smart Retries with a dunning email sequence, in-app banners, and pre-expiry card update reminders. Stripe retries alone recover about 35%. Adding multi-channel customer outreach within the first 7 days pushes recovery to 55%. Most failed payments are recoverable if you contact the customer quickly.

Every month, 5-10% of subscription payments on Stripe fail. For a SaaS at $15K MRR, that's $750-$1,500 in charges that didn't go through. Stripe's automatic retries recover about 35% of those. The other 65% becomes involuntary churn. revenue lost not because customers wanted to leave, but because a payment method broke. Use our failed payment recovery calculator to see how much you could save. This guide covers every method to recover those failed payments using dunning, from Stripe's built-in tools to DIY webhook sequences to dedicated recovery software. Also read about card expiry reminders for prevention.

Why payments fail on Stripe

Understanding why payments fail helps you choose the right recovery strategy. Stripe categorizes failures by decline code in the invoice.payment_failed webhook event. The most common reasons:

Expired card (25-30%); the card passed its expiration date. The customer needs to enter new card details. This is the most recoverable failure type.
Insufficient funds (20-25%); the customer's account balance is too low. A retry a few days later often succeeds when the customer gets paid.
Generic decline (15-20%); the bank declined the transaction without a specific reason. Could be fraud detection, velocity limits, or temporary holds.
Card not supported (5-10%); the card type doesn't support recurring charges. Rare with major card networks but happens with some prepaid and regional cards.
Processing errors (5-10%). temporary failures in the payment network. Usually resolve on retry.
Lost or stolen card (5%); the bank flagged the card. The customer must use a different card entirely.

Stripe's automatic retries

Stripe retries failed payments automatically when you enable Smart Retries in Dashboard > Settings > Subscriptions and emails > Manage failed payments. Smart Retries uses machine learning trained on Stripe's network-wide data to pick the optimal retry time for each individual charge. It considers factors like day of week, time of day, card type, and historical success patterns.

You can configure the retry window (up to 4 weeks) and the number of retry attempts (up to 4). The recommended setting is maximum window, maximum retries. This gives Stripe the most flexibility.

Recovery rate with Smart Retries alone: approximately 35% of failed payments. That's your baseline. Everything else in this guide is about recovering the remaining 65%.

Manual recovery steps

If you don't want to build automation yet, you can manually recover failed payments through the Stripe Dashboard:

Go to Payments > All payments and filter by status "Failed"
Click on a failed payment to see the decline reason and customer details
Click the customer's name to go to their profile
From there, you can manually retry the invoice, send the customer a payment link, or update their payment method
To retry: go to the failed invoice and click "Retry payment"
To send a payment link: create a new invoice or send the customer a hosted invoice link

This works for small volumes (under 10 failures/month) but doesn't scale. For anything beyond that, you need automation.

Build a dunning email sequence

The single highest-impact recovery method beyond Smart Retries is a multi-email dunning sequence. Stripe sends one email. You should send at least four. Here's a proven sequence:

Email 1: Day 0 (payment fails)

Subject: "Your payment didn't go through"
Tone: Friendly and matter-of-fact. No urgency yet.
Content: Let them know the payment failed. Include a direct link to update their card. Mention what they'll lose access to if not resolved. Keep it short. 3-4 sentences max.

Email 2: Day 3

Subject: "Quick reminder: update your payment method"
Tone: Helpful, slightly more urgent.
Content: Remind them the payment is still outstanding. Reference specific features they use (if you have that data). Include the card update link prominently. Mention you've paused retries to avoid multiple charges (even if Stripe is retrying in the background; the customer doesn't need to know the details).

Email 3: Day 7

Subject: "Your account will be paused in 7 days"
Tone: Urgent but empathetic.
Content: Create a deadline. Mention that their data and settings will be preserved but access will be restricted. Include the card update link. Offer to help if they're having issues with the update process.

Email 4: Day 14

Subject: "Final notice: your subscription will be cancelled tomorrow"
Tone: Direct, personal.
Content: This is the last chance email. Sign it from the founder or CEO for a personal touch. Mention how long they've been a customer and the value they've gotten. Include the card update link one final time. Make it clear this is the last email before cancellation.

Hosted card update page

Every dunning email needs a link where the customer can update their card. The fastest way to create this is using Stripe's Billing Portal:

// Create a Billing Portal session for card update
const session = await stripe.billingPortal.sessions.create({
  customer: 'cus_1234567890',
  return_url: 'https://yourapp.com/settings',
});

// session.url is the hosted card update page
// Include this URL in your dunning emails

The Billing Portal gives the customer a Stripe-hosted page where they can update their payment method. After updating, Stripe automatically retries the failed invoice. No additional code needed on your end.

Webhook events for recovery

To build automated recovery, you need to listen for these Stripe webhook events:

invoice.payment_failed. fires on each failed attempt. Check data.object.attempt_count to know which attempt it is. Start your dunning sequence on the first failure.
invoice.payment_succeeded. fires when a payment is recovered. Stop your dunning sequence immediately. Send a "Welcome back" email.
customer.subscription.updated. fires when the subscription status changes. Watch for transitions to past_due or unpaid.
customer.subscription.deleted. fires when the subscription is cancelled. This is your signal that recovery failed.
payment_method.attached. fires when a customer adds a new payment method. You can proactively retry the failed invoice when this happens.

Recovery rate benchmarks

Based on data from SaaS companies at $5K-$50K MRR, here's what you can expect from each recovery layer:

Stripe Smart Retries only: ~35% recovery rate
Smart Retries + 1 email (Stripe default): ~40% recovery rate
Smart Retries + multi-email dunning sequence: ~55% recovery rate
Smart Retries + dunning + pre-dunning + in-app banners: ~60-70% recovery rate

The jump from 35% to 55% is the dunning emails alone. That's the single biggest ROI improvement you can make. Pre-dunning and in-app banners push you even higher.

Tool-assisted recovery

Building a complete recovery system (webhooks, email sequences, card update pages, pre-dunning, in-app banners, analytics) takes 40-60 hours. If your time is better spent on product, a dedicated recovery tool handles all of this for you.

SaveMRR's Revenue Rescue engine connects to your Stripe account and immediately starts recovering failed payments. It runs a 4-email dunning sequence with proven copy, monitors card expiry dates for pre-dunning alerts, provides a JavaScript widget for in-app payment banners, and tracks recovery rates in a dashboard. The integration is a Stripe API key paste. No webhook endpoints to manage, no email service to configure, no cron jobs to maintain.

SaveMRR works alongside Stripe's Smart Retries. It doesn't replace them. It adds the email, pre-dunning, and in-app layers that Stripe doesn't provide. Pricing starts at $19/month for the Starter plan.

Next step

Start by measuring the problem. SaveMRR's free Revenue Scan connects to your Stripe account (read-only) and shows your exact failed payment volume, current recovery rate, and how much additional revenue you could recover with proper dunning. It takes 2 minutes, requires no code changes, and gives you the numbers you need to justify building or buying a recovery solution.