Retention 6 min read · · Last updated:
By Mark Ashworth · Founder, ChurnTools

Stripe Charges Expired Cards Automatically. Is That Fixing Churn or Hiding It?

People hated the idea of automatically updating expired cards. They were right. A lapsing card is often a quiet cancellation, and when you silently pull the new number and keep charging, you override a decision the customer thought they had made. Here is the one-line test I use before I recover any failed payment, and how to keep the real accidents without re-billing the leavers.

📊

Want a personalized score for your situation?

Take the free 60-second Churn Health Check

Score me →

TLDR: I made a video about Stripe's automatic card updates. People hated the concept, and they were right. A lapsing card is a cancellation method. Plenty of people never hunt for your cancel button, they just let the card die and assume it is handled. So when you silently pull their new number from the network and keep charging, you override a decision they thought they had made. The test I use before recovering any failed payment: would the customer say yes if you asked them? Recover the accidents. Let the leavers leave.

A lapsing card is a cancellation method

Here is the part that makes automatic card updates uncomfortable. Not everyone cancels the way your product analytics assume they do. A lot of people never open the settings page and never find the cancel button. They just let the card expire and quietly assume the whole thing is handled. In their head, they already left.

The card updater does not see it that way. When a card expires or gets reissued, the networks push the new details to Stripe behind the scenes, Stripe swaps the number on file, and the charge goes through like nothing happened. For a customer who wanted to stay, that is close to free money and a real involuntary churn save. For the customer who let the card die on purpose, you just re-billed them for something they thought they had cancelled.

The test I use: would they say yes if you asked?

I do not decide this on gut feel anymore. I run one question against every involuntary-churn tactic before I ship it.

Would the customer say yes if you asked them? If yes, fix it. If you would rather they never found out, that is not retention. That is friction with better marketing.

It is a clean line because it is about consent, not cleverness. Email a customer whose card just expired and ask "want to keep your subscription?" If they would happily click yes, then recovering that payment is exactly what they wanted, so go recover it. If the honest answer is that you are hoping they never notice the charge, you already know the recovery is not a save. It is a delay on a refund.

Every involuntary churn tactic either removes an accident or removes an exit A failed payment splits into two cases. On the left, removing an accident: the card died by mistake and the customer still wants you, caused by an expired card or bank reissue, so recover it with dunning and the card updater because it is a genuine save. On the right, removing an exit: the customer let the card lapse on purpose as a quiet cancel, so let them leave because re-billing only defers churn and comes back as refunds. The test underneath: would the customer say yes if you asked them? Every tactic does one of two things A failed payment is either an accident to fix or an exit to respect. A PAYMENT FAILED Accident or exit? Removing an accident The card died by mistake. They still want you. CAUSE Expired card or bank reissue. THE CALL • Recover it with dunning • Card updater is fair here • This is a genuine save Fix it. They would say yes. Removing an exit They let it lapse on purpose. The card was the cancel. CAUSE Done. Chose not to update. THE CALL • Let them walk • Re-billing defers churn • Comes back as refunds Don't. They would say no. The test: would the customer say yes if you asked them?

Same failed charge, two opposite calls. The card updater fires on both without knowing which is which.

Every involuntary churn tactic does one of two things

Once you see the split, every dunning email, retry schedule, and card-update feature sorts into one of two jobs. It is either removing an accident or removing an exit. That is the whole taxonomy.

Removing an accident is unambiguously good. A card expired, a bank reissued plastic, a one-off decline happened at 2am, and a customer who loves your product would have been booted for a reason that has nothing to do with your product. Recover that all day. Removing an exit is the sketchy one. The customer used a lapsing card as their quiet resignation letter, and you tore it up and kept billing.

Recover the accidents. Let the leavers leave.

Accident vs exit, side by side

Here is the same idea as a table. The only thing these two share is the row on your dashboard: a failed payment.

  Removing an accident Removing an exit
What happened The card failed by mistake They let the card lapse on purpose
Did they mean to leave? No. They wanted to stay Yes. This was the cancel
Consent test They would say yes if you asked They would say no if you asked
Recovering the payment is A real save A deferred refund
Shows up later as Retained revenue Chargebacks and bad reviews
The right move Recover it Let them go

How many of your "saves" are actually real?

Recovery rate is not the same as save quality. You can win back 60% of failed payments and still be manufacturing future refunds if a chunk of those cards were quiet exits. The widget below splits the recoveries you are already booking into the ones you should be proud of and the ones that come back to bite you.

How many of your saves are real?

Split the failed payments you recover into accidents and exits. The last slider is the one nobody wants to move off zero.

Real saves
$1,800
23 accidents recovered / mo
Deferred refunds
$600
8 leavers re-billed / mo

A quarter of what you recover is people who meant to leave. That revenue does not stay. It comes back as refunds, chargebacks, and reviews. Make intent explicit before you re-bill.

Over a year, the phantom saves you are chasing are worth $7,200, and every dollar of it is a customer who will be angrier at you than if you had just let them go.
See your real involuntary churn split →

Where these numbers come from: there is no public benchmark for the share of lapsed cards that were intentional exits, and that is the entire problem. The customer never told you they were leaving, so nobody measures it and everyone silently assumes it is zero. You have to estimate it with the consent test. The recovery side is better documented: Stripe smart retries plus a card updater win back a large majority of genuinely failed payments, and Recurly and Chargebee report similar recovery ranges. High recovery is great. Just remember recovery rate measures how many payments you re-collect, never how many customers actually wanted you to.

How do you keep the upside without the sketchy part?

You do not have to choose between recovering accidents and respecting exits. You just have to make intent obvious so the mechanism stops guessing. Three moves do most of the work:

  • Send a pre-expiry heads-up email before the card dies, so continuing is an active choice instead of a silent default. This alone converts a lot of "phantom saves" into either real yeses or clean goodbyes.
  • Run smart dunning with plain update-or-cancel messaging rather than silent retries that go on forever. Give people a visible off-ramp inside the same flow that asks them to stay.
  • Make cancelling a genuine one-click action. The easier you make leaving, the more your recovered payments belong to people who meant to stay, which is also the direction the FTC's negative-option rules are pushing every subscription business anyway.

None of this slows down the good recoveries. It just stops you from booking revenue you will have to refund and apologise for later. If you want the wider frame on why this leak stays invisible, here is why involuntary churn gets silence, and if you are still sorting the two kinds apart, start with voluntary vs involuntary churn.

Diagnose it before you automate it

Automatic card updates are a good feature aimed at a real problem. They only turn sketchy when you point them at people who were trying to leave. So do the recovery, but recover the accidents on purpose and let the leavers leave on purpose. If you are not sure how much of your churn is involuntary versus voluntary, or how many of your recoveries would pass the consent test, the free Churn Health Check gives you the split in about 60 seconds, and the MRR Impact Simulator puts a dollar figure on the accidents that are genuinely worth recovering. Diagnose first. Then automate.

Free interactive tool

Score your retention setup in 60 seconds

8 questions. Get your tier (Critical to Best-in-Class), your weakest spots, and 3 specific things to fix next.

Take the Health Check

Frequently asked questions

Answers to the questions I get most often about this topic.

What is Stripe automatic card updates?

It is a Stripe feature where the card networks (Visa Account Updater, Mastercard Automatic Billing Updater) push new card details after an expiry or reissue straight to Stripe, which swaps the number on file and keeps billing the subscription without the customer re-entering anything. It is built to cut involuntary churn, where a customer who wanted to stay gets dropped because their card silently failed.

Is a lapsing card really a form of cancellation?

For a real slice of customers, yes. Not everyone hunts for the cancel button. Some just let the card expire and assume the subscription dies with it, because that is the lowest-effort way to leave. So when the card updater silently pulls the new number and keeps charging, you have overridden a decision that person thought they had already made. The card lapse was the cancel.

What is the consent test for involuntary churn?

One question: would the customer say yes if you asked them? If you emailed "your card expired, want to keep your subscription?" and they would click yes, then recovering the payment is a genuine save, so fix it. If you would rather they never found out you re-billed them, that is not retention. That is friction with better marketing, and it comes back later as refunds and chargebacks.

Does the card updater reduce churn or just hide it?

It reduces involuntary churn when the recovered customer genuinely meant to stay, which is most of the time. It hides churn when it re-bills someone who let the card lapse on purpose. Those recoveries are not real saves; they show up later as refund requests, chargebacks, and one-star reviews. The mechanism cannot tell the difference on its own, so the quality of the save depends on how easy you make it for the leavers to actually leave.

How do I recover failed payments without billing people who wanted to leave?

Make intent explicit and exit easy. Send a pre-expiry email before the card dies so staying is an active choice rather than a default, run smart dunning with clear update-or-cancel messaging instead of silent endless retries, and make cancelling a one-click action. When leaving is genuinely easy, a recovered payment is far more likely to be a customer who actually wanted to stay.

Is silently re-billing an expired card even legal?

Recovering payments via the card networks is standard and allowed, but the surrounding experience is under real scrutiny. The FTC negative-option and "click to cancel" rules push hard on easy cancellation and clear consent for recurring charges. If your product is easy to start and hard to stop, aggressive silent recovery is exactly the pattern regulators are targeting. Recovering accidents is fine; trapping leavers is a compliance and reputation risk.

Should I fix involuntary or voluntary churn first?

Fix involuntary churn first. It is mostly a tooling problem (smart dunning, card updater, pre-expiry outreach) that pays back within about 30 days, and that quick win buys time and budget for the slower voluntary-churn work. Just confirm the customers you recover meant to stay, or you are only deferring the churn instead of preventing it.
MA

Written by Mark Ashworth

Founder of ChurnTools. I spend my time studying how SaaS companies lose customers and building tools to help them stop. Previously worked in SaaS growth and retention across multiple B2B products. I also write about growth and answer-engine optimization (AEO) at growthpigeon.com.

Ready to run your first retention experiment?

Browse 30+ proven playbooks for reducing churn across every stage of the customer lifecycle.

Browse Experiments →