How to Recover Failed Payments in SaaS

When a subscription charge is declined, the revenue does not disappear because the customer decided to leave — it disappears because nobody followed up. Most failed payments come from temporary problems: a card that expired, a momentary lack of funds, or a bank that blocked an unfamiliar charge. To recover failed payments reliably, you need a repeatable process that diagnoses why each charge failed, retries it at the right moments, and prompts the customer to act when a retry alone cannot fix it. This playbook walks through that process step by step.

Step 1: Diagnose Why the Payment Failed

Recovery starts with the decline reason, because the right tactic is different for each one. Recurring-payment failures fall into a few buckets:

• Insufficient funds: Usually a short-lived problem that clears within days — recovered best by retrying.
• Expired or reissued cards: The card on file is no longer valid; the customer has to update it before any charge succeeds.
• Bank fraud blocks: The bank flagged the charge and the customer often needs to approve it.
• Processor or network errors: Transient failures that frequently succeed on an immediate retry.

The split that matters is soft versus hard failures. Soft failures (funds, transient errors) are recovered mostly by retrying. Hard failures (expired cards, fraud blocks) need the customer to do something, which is what your email sequence is for. For a deeper look at the underlying problem and what it costs, see how failed payments quietly drain SaaS revenue.

Step 2: Retry the Charge on a Smart Schedule

Most soft failures recover with no customer involvement at all — if you retry at the right time. Instead of hammering the card every 24 hours, time retries around when funds are most likely to be available. A practical pattern is to retry a few hours after the failure to catch transient declines, then again after one to two days, then space the remaining attempts across the next week, favoring early-morning and payday windows. Three to four well-timed attempts over roughly seven days recover the bulk of insufficient-funds and network failures automatically.

Step 3: Run a Recovery Email Sequence in Parallel

Retries cannot fix an expired or cancelled card, so you run an email sequence alongside them for failures that need the customer to act. The widely used pattern is three emails over seven days: a friendly heads-up on day 0, an urgency reminder on day 3, and a final notice on day 7 before the subscription is downgraded. Each email should carry one clear call to action — a direct, no-login link to update the payment method. The moment a payment succeeds, stop the sequence so nobody is chased after they have already paid. For the exact copy, timing, and subject lines, see our guide to dunning email best practices, and for how retries and emails are wired together end to end, the dunning automation setup guide.

Step 4: Make Updating a Card Effortless

The single biggest leak in recovery is friction on the update step. If a customer has to log in, find the billing page, and re-enter details, many simply will not. Point every recovery email at a tokenized, hosted page where they can update the card in one click without signing in. Keep service active during the recovery window — typically seven to fourteen days — so a paying customer is not locked out over a card that expired last week.

Step 5: Measure What You Recover

You cannot improve what you do not track. Watch your recovery rate (share of failed charges eventually collected), email open and click rates, and time to recovery, then tune retry timing and email copy from the data. Small timing changes often move recovery more than copy rewrites do. To estimate how much revenue is currently at stake in your own account, run the numbers through the recovery calculator.

Build It Yourself or Use Recovery Software?

Every step above can be built in-house with your processor's webhooks and a transactional email provider. It is achievable, but it means owning retry scheduling, email deliverability, tokenized update links, sequence-stop logic, and reporting — and maintaining all of it as billing edge cases pile up. Dedicated failed payment recovery software handles those pieces out of the box and connects to your processor in minutes, which is why most teams reach for it once recovery becomes a priority rather than a side project.

Frequently Asked Questions