How to recover failed payments on Stripe subscriptions

To recover failed payments on Stripe subscriptions, measure how many first attempts fail and how many end up lost, switch on the retry and email tools you already have, ask the customer to update the card with a one-click link, and prove the result against a group you left alone. This is the order I would do it in, with the limits of each step.

What happens when a subscription payment fails?

Stripe tries to charge the invoice. If the charge fails, the invoice stays open and the subscription is flagged. What happens next depends on your own billing settings: how many retries, how far apart, and whether the subscription is eventually cancelled or left unpaid.

I am not going to quote Stripe's default schedule here. It changes, and you should read it in your own dashboard, under the billing and revenue recovery settings. The first job is to know what your account is actually set to do.

Why do cards fail in the first place?

Most card failures are one of three things: the card has expired, the customer is over their limit, or they are temporarily short of funds. Stripe reports a decline code on the failed charge, such as card_declined, generic_decline or expired_card.

The mix matters because the cause decides the cure. An expired card will never succeed on a retry; it needs the customer to give you a new one. A temporary shortfall often does succeed on a later retry. Pull the decline codes for your own failed charges from the last year and look at the top few. That is your own list, and it will not match anyone else's.

How do I measure the problem before I fix anything?

Count four things over the last 365 days:

1. Invoices whose first attempt failed.
2. Of those, how many were later paid (recovered).
3. How many ended up lost: uncollectible, void, or still open with no retry scheduled and older than 30 days.
4. How many are still in retry right now.

Then compute the recovery rate as recovered divided by recovered plus lost, using only invoices that are no longer in retry. Leave the in-retry ones out, otherwise this month's failures drag the rate down for no good reason.

Keep the value of each bucket in dollars too. A recovery rate of 60% means something very different on a $9 plan than on a $900 plan.

One rule keeps the count honest: if a failed invoice led to a cancelled subscription, count it as involuntary churn, not as a lost payment. I explain that in what involuntary churn is and how to measure it.

What should I turn on in Stripe first?

Check that automatic retries are enabled and that failed-payment emails to customers are switched on. These are built into Stripe, and it is easy to never open the settings page. Read what yours do, write it down, and compare it with the loss numbers from the step above.

Then check one more thing that is easy to miss: what happens at the end of the retry schedule. If the answer is that the subscription quietly ends and nobody is told, that is where the revenue goes.

How do I get the customer to update the card?

Ask them at the right moment, and make the action one click. A failed-payment email that says "your payment did not go through, update your card here" with a direct link to a page that does only that works better than a message that sends them to log in and hunt for billing.

A few details I would not skip:

• Say what happened in plain words, name the product and the amount, and say what will happen if nothing changes.
• Send it from your own domain and in your voice. A mail from an unknown sender looks like phishing, and it should not look like that.
• Do not send the same message five times. A second message should have a reason to exist, such as the date the access will end.
• Do not attach a discount to a failed payment. Customers whose card failed did not ask for a lower price.

Can I stop failures before they happen?

Partly. Cards have expiry dates, and Stripe knows them. Sending a card-update email before the card expires removes some failures at the source. This is the cheapest kind of recovery, because the customer is not yet in trouble.

It does not catch everything. Cards get replaced after fraud, lost cards and bank changes, and those do not announce themselves. So pre-expiry emails reduce the problem; they do not end it.

How do I time the retries?

Match the retry to the cause. If the decline is an expired card, more retries are noise; the message to the customer is the only thing that helps. If the decline looks like a temporary shortfall, spacing the retries over days gives the account time to refill.

I do not have a magic schedule to give you, and I would be wary of anyone who does without seeing your decline codes. What I can say is that a single rule for all failures leaves money behind, and that you should change one thing at a time so you can see what moved the rate.

How do I know that recovery actually improved?

Comparing this quarter with last quarter is weak evidence. Seasons, price changes and a different customer mix all move the number. The cleaner test is a holdout: leave a random share of customers out of your new messages and compare the two groups on the same definition.

In the pilot I run, 20% of customers are chosen by a stable hash of the customer id and get nothing from me. The rest get the fixes. The result is net revenue per customer, after the cost of any offers, and I report a group with fewer than 30 events as an early signal, not a verdict.

You can run your own version without me. Pick the split, write down the metric before you start, and do not peek and change the rules halfway.

What should the follow-up sequence look like?

Keep it short and give each message a job. The first one tells the customer what happened and gives the one-click link. A later one adds the date the access will end if nothing changes. The last one tells them it has ended and how to come back, which is also the start of your win-back flow.

Stop sending once the invoice is paid, and make sure the stop is instant. Few things look worse than a "your payment failed" message arriving after the customer has already fixed it.

What can Stripe not tell me?

Several things, and they change how you read the numbers:

• It cannot show a recovery that happened through a channel it does not see, like an email sent from another tool or a support conversation.
• List price times quantity is not what was actually collected after coupons.
• Cancellations handled in another billing system are invisible.
• History is limited to what Stripe holds for that account.

When is it worth paying for help?

If you have fewer than roughly 2,000 paying customers, I would do this by hand. You will not have enough failed invoices per month to see a clean result, and the cost of the work is better spent on something else.

With more customers, the counting is the slow part. The Revenue Leak Report is $490 and is delivered within 48 hours of receiving a restricted read-only Stripe key. It puts failed payments, trials, cancellations and downgrades in dollars per month and lists the top three fixes. It does not change anything in your account. You can look at a synthetic example first at the sample report.