How to Recover Failed Stripe Payments: A Practical Guide for Small SaaS

Every subscription business on Stripe loses some revenue to cards that fail. The customer did not decide to leave. Their card expired, their bank flagged the charge, or they ran short that week. If nobody follows up, that customer quietly churns.

This guide walks through what actually works, in the order we would do it. Some of it you can set up yourself this afternoon for free. Some of it is where a tool like ours (or a competitor) earns its keep. We will be clear about which is which.

Step 1: Find out how big your leak is

Before you change anything, measure. Look at your failed invoices for the last 90 days in your Stripe dashboard and answer three questions:

1. How many invoices failed on the first attempt?
2. How many of those were eventually paid?
3. How much money is still sitting in invoices that never got paid?

The third number is the one that matters. It is your leak. It tells you whether this problem is worth an hour of your time or a paid tool.

How big is this problem in general? Third party numbers exist, but most come from vendors who sell recovery tools, so read them with that in mind. One analysis by Churnkey of 5.4 million failed payments put 22% of subscription cancellations down to failed payments, as reported by Gymdesk. That is vendor sourced data. Your own number is the only one that should drive your decision.

If you would rather not dig through invoices by hand, our free Leak Check does the math for you from a few totals in your Stripe Dashboard, in your browser, with no access to your account. It is free whether or not you ever use the paid service.

Step 2: Understand why the payments failed

Not all failures are the same, and they need different fixes. Roughly, you will see three kinds:

• Expired or replaced cards. The card number is no longer valid. Retrying will not help. The customer has to enter a new card.
• Insufficient funds or temporary declines. The card is fine, but the charge did not go through today. A later retry often works.
• Authentication required. The bank wants the cardholder to confirm the payment (for example with 3D Secure). No retry will ever succeed on its own, because the customer must take an action.

That last group is easy to miss. A founder writing on Indie Hackers described treating "authentication required" failures as their own case as part of the changes that improved his recovery (Indie Hackers). Note that he sells a competing tool, so treat his numbers as one person's experience.

Step 3: Turn on what Stripe already gives you

Stripe has built in retries and can send reminder emails to customers whose payments fail. These settings live in your Stripe Billing settings. Check Stripe's own documentation for the current options, because they change over time.

Our opinion: every Stripe business should turn these on before paying anyone for recovery. They are free with Stripe Billing, and they catch a real share of temporary declines. Anyone who tells you Stripe does nothing here is wrong.

What Stripe's defaults do not do well, in our view:

• The reminder emails look like system notices, not like a note from a person.
• Retries cannot fix an expired card or an authentication request.
• You get little reporting on how many dollars came back and why.

That is the gap the next steps fill.

Step 4: Send short, plain text emails with one clear link

The single most useful change most small SaaS companies can make is a short email sequence that sounds like it came from a person. Here is the pattern we use and recommend:

• Plain text, not a designed template. It reads like a note from the founder, not a marketing blast.
• One link that goes straight to a page where the customer can update their card or pay the invoice. Stripe's hosted invoice page or customer billing portal both work.
• Three or four emails over about ten days. Friendly first, a little more direct later, and a final note before access changes.
• No upsells or promotions. Keep these emails strictly about the payment. Mixing in promotional content can change how email rules treat them, as the Fungies comparison notes.

The Indie Hackers founder mentioned above reported that switching to plain text emails with a one click update link took his recovery from 35% to 65% (Indie Hackers). That is an anecdote, not a benchmark. Your results will vary.

Here is a sample first email you can copy:

Subject: Quick note about your [Product] payment

Hi [First name],

Your last payment for [Product] did not go through. It happens, usually an expired card or a bank check.

You can update your card here in about a minute: [link]

If something else is going on, just reply and I will help.

[Your name]

Step 5: Handle "authentication required" on its own track

For authentication failures, the email should say plainly that the bank needs the customer to confirm the payment, and the link should take them to the page where they can do that. Do not tell them their card was declined. It was not, and that confuses people.

Step 6: Get the timing right

Timing matters more than most founders expect. Data from Recurly, cited by Gymdesk, showed better retry timing raising recovery from about 53% to 71%. Again, that is vendor sourced.

Our opinion on a simple starting schedule:

• Email 1: the day of the failure.
• Email 2: two or three days later.
• Email 3: about a week after the failure.
• Email 4: the day before access changes.

Stop the sequence the moment the invoice is paid. Nothing annoys a customer more than a "your payment failed" email after they fixed it.

Step 7: Read the replies

Some customers will reply. A few will be confused, a few will want to cancel, and a few will have a real billing problem. Someone has to read these. Set aside a short weekly block for it.

Step 8: Measure dollars recovered, not emails sent

Track one number each week: dollars that came back from invoices that had failed. Split it by what caused the recovery (a Stripe retry versus a customer clicking your link) so you know what is actually working.

If you want a cleaner answer, hold out a random 10 to 15% of failed invoices from your emails and compare recovery rates between the two groups. The difference is what your emails add on top of Stripe. It is the same idea behind our own monthly proof report.

Doing it yourself versus using a tool

You can build all of this yourself with Stripe webhooks and a transactional email service. If you have the time, that is a fine choice.

If you would rather not, there are paid tools. Prices reported by the Fungies comparison include Churn Buster from $249 a month, Churnkey from $300 a month, and Baremetrics Recover at $169 a month, with Gravy and FlyCode listed as success based options. These prices are as of October 2026; check their sites for current pricing.

Our service, Renewvane, costs $49 a month. We start with a free Leak Check, and only if your numbers show the plan would likely pay for itself (about $2,500 a month or more of failed payments, across 20 or more failed payments a month) do we offer a 30 day free trial. From about $1,500 to $2,500 a month you can still try it, with a plain warning that payback is uncertain. Cancel anytime. A random 15% of failed invoices get no emails from us, and every month our proof report credits us only with recovery above that holdout group's rate, minus a safety margin for chance, so payments Stripe's own retries would have recovered are not counted. We also only count payments the subscriber made through the Stripe page our link opened, with a new card or a bank confirmation.

Quick checklist

1. Measure your 90 day leak.
2. Sort failures by type.
3. Turn on Stripe's built in retries and reminders.
4. Add a short plain text email sequence with one update link.
5. Give "authentication required" its own email.
6. Stop emails the moment the invoice is paid.
7. Read replies weekly.
8. Track recovered dollars every week.

Want to see your number first? Run the free Leak Check. It takes a few totals from your own Stripe Dashboard and shows how much failed in the last 90 days and how much never came back. It runs in your browser, with no access to your account.