How to reduce churn in SaaS with failed-payment recovery, a cancel flow and save offers

Reduce churn in a software as a service (SaaS) product by splitting it into involuntary churn from failed payments and voluntary churn from chosen cancels, then fixing the payment side first. Stripe puts failed payments at 20% to 40% of total churn for subscription businesses. Turn on automatic retries, dunning emails and a card updater. Then build a cancel flow with a reason question, a pause option and one matched save offer.

How do you reduce churn in a SaaS product?

Reduce churn in a SaaS product by splitting it in two and fixing the cheaper half first. Involuntary churn is the customer who wanted to stay but whose payment failed. Voluntary churn is the customer who chose to cancel. They need different fixes, so measure them separately from day one.

Start with involuntary churn. Stripe puts failed payments at 20% to 40% of total churn for subscription businesses. Recurly states that 53% of all customer attrition is involuntary churn. The two figures differ. In our reading they point the same way: a large share of lost customers never decided to leave, and winning them back takes billing settings and email, not product work.

Then build a cancel flow for the customers who do choose to go.

Small monthly rates compound. ChartMogul calculates that a monthly churn rate of 5% corresponds to an annual churn rate of 46%. Its data shows a median monthly customer churn rate of 6.1% for companies with ARPA per month under $25, where ARPA means average revenue per account, falling to 2.2% as ARPA per month increases to >$500. Compare your own rate against our monthly churn benchmarks.

The order to work in this week

1. Tag every lost customer in your billing data as either a payment failure or a chosen cancel.
2. Turn on automatic payment retries and a card updater. Recurly notes that automating transaction retries can help you recover soft declines.
3. Send dunning emails, the reminders that ask a customer to fix a failed payment, and link each one straight to the page where they update their card.
4. Add a cancel flow: one question about the reason, a pause option, and a save offer matched to that reason.

Worked example

These are example inputs, not a benchmark. Take 1000 customers at 5% monthly churn, and you lose 50 customers a month. If 30% of those 50 losses are failed payments, 15 customers a month are involuntary churn. That leaves 35 chosen cancels, which is 50 minus 15.

The 15 are the first target, because none of them asked to leave. The 35 are where the cancel flow and save offers do their work. Track both counts monthly so you can see which fix moved your retention.

Voluntary and involuntary churn are two different problems

Both types end with a lost customer, but they start in different places. One is a decision. The other is a billing event the customer may never notice. Report them as one number and you cannot tell whether the fix belongs in your product or in your payment stack.

Recurly defines voluntary churn as when a customer cancels on purpose, and involuntary churn as loss that happens when the customer does not want to cancel, usually from an unprocessed payment. Inside voluntary churn sits a subset ChartMogul calls happy churn: people who leave because the job they hired the product for is done.

Type	Usual causes
Voluntary	No room to personalize plans, billing and payments; decisions not driven by customer satisfaction; no easy way to cancel
Involuntary	Outdated payment information; unsuccessful payment retries; weak dunning (payment reminder) sequences

The causes in the table come from Recurly's list of the top three reasons for each type.

The formula, with the two clean-up adjustments

ChartMogul's customer churn rate subtracts two groups from the raw count of lost customers: those who both joined and churned or churned and reactivated in the same period. Both groups distort the rate if you leave them in. Count paying customers only: free trial customers should be excluded, along with free-plan users.

Customer churn rate =
  (customers churned
   - customers who joined and churned in the period
   - customers who churned and reactivated in the period)
  / paying customers at start of period

Voluntary churn rate   = adjusted voluntary losses   / paying customers at start
Involuntary churn rate = adjusted involuntary losses / paying customers at start
Overall churn rate     = voluntary rate + involuntary rate

ChartMogul's own example starts a month with 100 customers and 12 churned, one of whom reactivated and one of whom joined that month: "Your customer churn rate is 10%: (12 − 2) ÷ 100."

Splitting the number

Here is an illustration, not a benchmark. Start with 1000 paying customers and a 0.05 adjusted churn rate, which means 50 customers lost. If a 0.3 share of those 50 left through failed payments, then 15 were involuntary and 35 chose to cancel. On the starting base of 1000, 15 losses is a 1.5% involuntary rate and 35 losses is a 3.5% voluntary rate.

Tag every loss at the moment it happens. A billing system that records why a subscription ended makes this simple: Recurly's dashboard, for example, logs non-payment when a failed transaction leaves an invoice unrecovered, and a separate reason when the customer initiated the cancellation. Report the two rates as separate lines each month and track them by cohort.

What share of churn is involuntary?

Published estimates put involuntary churn at a large share of the total. The range cited earlier in this piece is one anchor.

Treat these as a reason to measure, not as your number. Your split depends on who pays you, how they pay and how your billing system handles a decline. In our reading, a product billed annually on corporate cards will see a different mix than a monthly consumer plan.

Expired cards show why the share varies. Stripe notes that card expiration can trigger a hard decline from the issuing bank, so retrying the same card will not fix it. It also notes that credit cards typically expire every two to five years, so the older your subscriber base, the more of these declines you will hit.

Pull your own split from billing data

1. Export every subscription that ended in a closed month from your billing system.
2. Tag each one by how it ended: the customer canceled, or the subscription lapsed after a failed payment and the end of your retry and reminder sequence.
3. Count each group and divide by total churned subscriptions.
4. Repeat for three months before you set a target, so one bad billing month does not set your baseline.

Here is a worked example with round inputs, not a benchmark. Take 1000 active customers at the start of a month and 0.05 monthly churn: 1000 × 0.05 = 50 churned customers. If 0.3 of those ended through failed payments, 50 × 0.3 = 15 are involuntary and 50 minus 15 = 35 are voluntary.

Group (example inputs)	Customers
Active at start of month	1000
Churned in month	50
Involuntary (failed payment)	15
Voluntary (canceled)	35

In this example, a recovery program aims at 15 customers a month and a cancel flow aims at 35. We think that ratio, not the published estimates, should decide where your first quarter of work goes.

Use a simple sheet to keep the count consistent each month:

Month:
Active subscriptions at start (A):
Subscriptions ended in month (C):
  Ended after failed payment, retries exhausted (I):
  Ended by customer cancellation (V):
Check: I + V = C
Monthly churn rate = C / A
Involuntary share = I / C
Voluntary share = V / C
Notes (billing changes, price changes, outages):

Once you have three months, compare your involuntary share with the monthly churn benchmarks for context, then set a target against your own baseline.

What is dunning and how do you set up failed-payment recovery?

Dunning is how you turn a failed charge back into a paid one. Stripe defines it as the system you use to communicate with customers to collect accounts receivable (AR), built from a mix of automated retries, customer reminders, and grace periods. Set it up in this order.

1. Turn on automatic retries. Stripe Billing offers Smart Retries or a custom schedule. Smart Retries can run over 1 week, 2 weeks, 3 weeks, 1 month, or 2 months, and the recommended default setting is 8 tries within 2 weeks. A custom schedule lets you configure up to three retries, with a set number of days between attempts.
2. Know when retries are skipped. Stripe does not retry when no payment methods are available or when the issuer returned a hard decline code. After a hard decline, the charge only runs once the customer adds a new payment method. Retrying alone will not fix it.
3. Check the payment method order. On a retry, Stripe uses the first available payment method in this list, in this order, starting with the subscription default. When a customer adds a new card, update the field where the previous payment failed. Otherwise retries keep hitting the old card.
4. Pick the end state. If recovery fails, the subscription transitions according to your settings: cancel, mark unpaid, leave past due or pause.
5. Send failed-payment emails. Many businesses use failed payment and 3D Secure emails so customers can fix a card right away. One cadence Stripe describes is a sequence of reminders (e.g., after three days, then again after five more). For open and click rates to plan against, see our lifecycle email benchmarks.
6. Send expiry notices. Your billing system should flag cards that are set to expire in the next 30 to 60 days. Then email a one-click update link before the renewal date.
7. Turn on a card updater and a backup method. Stripe's card account updater requests updated card details from the networks and issuing banks. It has gaps: updates can fail if the customer switches banks or closes their account. You can also let customers add a secondary card or bank account to their profiles as a fallback.

Local bank debits need their own switch. By default, Stripe doesn’t automatically retry failed payments made with local payment methods.

Failure type	What the processor does	Action that fits (our reading)
Soft decline, such as insufficient funds	Retries on schedule	Let Smart Retries or your custom schedule run, and send one email
Hard decline	Waits for a new payment method	Email at once with an update link, and charge the backup method if one is on file
Card about to expire	Nothing until the charge fails	Card updater plus an expiry notice before renewal
No payment method on file	No retry	Email asking the customer to add a card
Local bank debit failure	No retry unless enabled	Turn on local payment method retries

How a cancel flow works, step by step

A cancel flow is the short sequence a paying customer sees after clicking the cancel button. It has four steps, in this order: ask why they are leaving, ask what they valued, make one save attempt that fits their answers, and offer a discount only if that attempt fails.

Step 1: Ask for the reason

Paddle describes its Retain Cancellation Flows this way: when a customer clicks cancel, "we start by asking them to provide a cancellation reason and a satisfaction insight". Keep the reason list short and fixed so you can count answers each week.

Step 2: Ask what they valued

The second question is what the customer liked. Paddle bases this on what it calls "the psychological phenomenon of the nostalgia effect". Its example response opens with "Since you liked our support so much, how about a 1:1 account review".

In Paddle's design, the save offer is "based on the survey’s satisfaction insight (what you liked), and not the cancellation insight (what you didn’t like)." We think this is the step most homemade flows skip.

Step 3: Make one matched save attempt

Paddle routes customers to one of three salvage attempts: pause the subscription, switch plan, or contact support. A pause fits when "your business is more seasonal". For the support route, Paddle passes along the survey responses so your team does not ask the same questions twice.

Step 4: Discount last

Paddle's developer docs put it plainly: "As a last resort, you can offer customers a discount to incentivize them to stick around." In our reading, leading with a discount teaches customers that clicking cancel gets them a lower price.

Three setup details to check this week:

• Paddle's flows run only for paying customers, not trial or free users.
• Plan switches and discounts take effect immediately, so finance needs to know.
• Paddle offers a weekly CSV (comma-separated values) report of flow activity. Use whatever log you have to track saves by reason.

Template: reasons and save attempts

Copy this, then edit the wording to match your plans.

CANCEL FLOW TEMPLATE

Q1. Why are you canceling?
  a) Too expensive
  b) Not using it enough right now
  c) Missing a feature I need
  d) Hard to set up or learn
  e) Switching to another product
  f) Project or season ended
  g) Other (free text)

Q2. What did you value most?
  a) The support team
  b) A specific feature
  c) Saved time
  d) Price
  e) Nothing in particular

SAVE ATTEMPT (route on Q2 first, then Q1)
  Valued support + any reason      -> Offer a 1:1 account review
  Valued a feature + too expensive -> Offer switch to a lower plan
  Not using it / season ended      -> Offer pause subscription
  Hard to set up                   -> Offer a setup call with support
  Missing feature / switching      -> Ask which feature, log it, offer support call

IF SAVE ATTEMPT DECLINED
  -> Show one discount offer
  -> If declined, confirm cancellation in one click

Should customers pause, downgrade or get a discount instead of canceling?

Each save offer fits a different reason for leaving. The cancel reason the customer picks tells you which one to show, and a mismatch reads as a stall. CloudBlue lists the patterns behind most of these reasons: on price, customers leave if pricing is misaligned with the perceived value or lacks flexibility. On adoption, a warning sign is when customers struggle to adopt key functionalities. On experience, users who hit usability issues, a steep learning curve, or a lack of timely support look for alternatives.

Save option	Cancel reason it fits	What to set up first (our reading)
Pause	Seasonal use, as covered in the cancel flow section	A clear restart date shown on the confirmation screen
Plan switch	Price	A cheaper tier, or a maintenance plan where customers don't have feature access but can save their data/preferences with you at a low cost
Account review	Low adoption, from customers who like your support but don't seem to be getting value	A booking link or ticket route for support
Discount	Price, offered last, as noted earlier	A fixed term so the discount ends on a known date

For the account review, Paddle's Retain tool can let customers book meetings with your support team via Calendly or open a ticket. A poor experience has no row of its own. In our reading, a customer who says the product let them down is better served by a support conversation than by a coupon, and if they decline that, by a clean exit.

As an example, not a benchmark: if 1000 customers open the flow in a quarter and 0.3 of them accept a pause or plan switch, 1000 × 0.3 = 300 accounts stay. The other 700 still need to leave without friction.

Keep the exit easy to finish

We think one offer, then a visible confirm button, is the right shape. Every extra screen you add after a "no" costs goodwill with customers who may come back later, or who will tell peers how leaving felt.

Check the plumbing too. If you run the flow on a third-party billing setup, you will need to cancel the customer on your payment platform. If you skip that step, a customer who canceled keeps getting charged. Brand-new customers may not see the flow at all, since a period of 3-6 hrs is needed for the customer to be ingested into the database. Where no flow is configured, the customer portal shows a dialog to confirm the cancellation instead.

This week, map each cancel reason in your survey to one row of the table. Then click through your own cancel path and count the screens between "cancel" and "confirmed."

A worked example with 400 customers at $60 a month

This is our own arithmetic, built on example inputs rather than benchmarks. Swap in your own numbers before you show it to anyone. For where a $60 average revenue per account (ARPA) sits against peers, see the monthly churn benchmarks. The compounding effect of monthly churn over a year was covered earlier on this page.

The starting point

At 400 customers paying $60, monthly recurring revenue (MRR) is $24,000. A 5% monthly churn on 400 customers is 20 customers lost each month, and 20 customers at $60 is $1,200 of MRR gone.

Stripe puts failed payments at 20%, 40% of total churn for subscription businesses. We use the top of that range here. At 40% of 20 lost customers, 8 leave through failed payments, worth $480 of MRR at $60 each. The remaining 20 minus 8, or 12 customers, cancel on purpose, worth $1,200 minus $480, or $720.

What each fix is worth

In this example, dunning recovers 30% and the cancel flow saves 5%.

Monthly loss before fixes:    20 customers   $1,200 MRR
  Failed payments (40%):       8 customers     $480 MRR
  Voluntary cancels:          12 customers     $720 MRR

Recover 30% of failed:       2.4 customers     $144 MRR / month
Save 5% of cancels:          0.6 customers      $36 MRR / month
Total kept per month:        3.0 customers     $180 MRR / month

Churn after fixes: 17 / 400 = 4.25% a month

12-month gain (base held at 400 by new signups):
  3.0 x 12 = 36 customers     $180 x 12 = $2,160 MRR

Sensitivity on the recovery rate (save rate stays 5%):
  Half (15%):   1.8 kept / month   21.6 over 12 months   $1,296 MRR
  Double (60%): 5.4 kept / month   64.8 over 12 months   $3,888 MRR

Losing 17 instead of 20 customers out of 400 brings monthly churn to 4.25%. Over 12 months, 3 kept customers a month adds up to 36 customers, and $180 a month adds up to $2,160 of MRR.

In our reading, failed-payment recovery carries most of the gain because those customers never chose to leave. Saving 5% of 12 cancels moves the number far less than recovering 30% of 8 failed payments. The sensitivity lines show the result swings mostly on the recovery rate, so measure that one first.

What to do with this

1. Replace the example inputs with your own customer count, ARPA and last quarter's churn. Count it the way ChartMogul does, excluding any customers who both joined & churned in the same month.
2. Pull your actual involuntary share from billing records. If it sits near the low end of Stripe's range, recovery is worth less and the cancel flow worth more.
3. Track your recovery rate and save rate as two separate monthly numbers. The block above needs both.
4. Drop the result into the growth model template to see the effect alongside acquisition.

The 60-day churn plan and the metrics that show it is working

Run the plan in order. Each phase produces something the next one needs, and each has one number that tells you whether it worked.

Weeks	Step	Owner	What it produces	Success metric
1	Baseline split	Founder or analyst	Churn split into voluntary and involuntary, by signup cohort	Both rates recorded for the last three months
1 to 2	Retries and dunning emails	Billing or engineering owner	Retry schedule plus a failed-payment email sequence	Recovered payment rate

Week 1: get a clean baseline

Count paying customers only. ChartMogul's guidance is that free trial customers should be excluded, as well as those on a free plan (if you use a freemium model). Then tag every loss by reason. Recurly's churn dashboard uses reason codes such as Non-payment: The subscription churned due to a failed transaction and an unrecovered invoice and Canceled: The customer initiated the cancellation. Copy that split even if you track it in a spreadsheet. Group results by signup month so you can read them as retention curves.

Define your two working metrics before you ship anything:

Recovered payment rate = failed invoices later paid / all failed invoices (same period)
Save rate = customers who entered the cancel flow and stayed / all who entered the cancel flow

Recurly describes involuntary churn as Subscribers lost due to payment issues, showing how effective your payment recovery efforts are, so it serves as your check on weeks 1 to 2.

Test one save offer at a time and log each test in the growth experiment backlog template. Follow the method in how to run a growth experiment.

At the same time, set alerts on falling usage. Satisfaction surveys flag risk later, for three reasons Revenera sets out:

• These surveys measure sentiment, not actual usage patterns.
• Surveys are usually conducted periodically (quarterly or annually), missing real-time signals of dissatisfaction.
• Responses often come from engaged customers, while disengaged or unhappy users may ignore surveys altogether.

In our reading, a drop in logins or core actions shows up weeks before a low score would. Have customer success contact the account the week the alert fires.

At day 60, compare each cohort's voluntary and involuntary churn with your week 1 baseline. Keep the steps that moved their own metric and cut the ones that did not.

What this page does not cover

This page covers customer churn from failed payments and chosen cancels. It does not cover pricing strategy, onboarding or product changes that reduce churn before a customer reaches the cancel button, and it does not cover acquisition. It is not financial or legal advice, including on billing or cancellation rules that may apply to your business.