Up to 40% of Your SaaS Churn Is a Failed Card, Not a Cancellation: The Customer.io Dunning Flow Most Teams Never Build

Somewhere inside the card networks, a quiet repair job runs every day. When a customer's card is reissued—new number, new expiry date, same underlying account—Visa's Account Updater and Mastercard's Automatic Billing Updater can push those new details to the businesses billing that card, before the old one fails. The customer does nothing. They may never know their subscription was a week from lapsing. Industry estimates collected by ChurnWard put the reduction in hard declines from these services at 30 to 50%, and ChurnWard cites Gravy Solutions' finding that more than 70% of stored cards now get updated this way.

That self-healing is the part most retention teams forget. A failed charge isn't always a lost customer, and often it isn't even a problem yet. The networks, and your billing provider's own retries, will fix a good share of failures on their own if you give them a few days. Fire off a panicked "your payment failed" email the moment a charge bounces and you've interrupted a recovery that was already underway... and possibly reminded a content customer that they have a subscription they could cancel.

This post is the build: how to wire your billing provider into Customer.io and run a dunning flow that works with the retry window instead of against it. You'll get the events to ingest, the timing that respects silent retries, the channel escalation, and the suppression that stops you dunning a customer who already paid. Plus the one number to report at the end of it. Dunning, if the word is new to you, is the industry's term for chasing a failed payment—the sequence of retries and messages that tries to recover a charge that didn't land.

The churn you're not counting

A large share of the customers you lose each month never decided to leave. Their card expired, their bank declined a cross-border charge, or they hit their limit the day you billed them. Sources put involuntary churn—churn caused by failed payments rather than a cancellation—at 20 to 40% of all churn. Dodo Payments cites that range, and ProfitWell's analysis of 17,234 subscription companies, summarised by ChurnWard, lands in the same place.

It hides because your dashboards don't separate it. A cancellation and a failed card both show up as a churned subscription, so the failed card gets filed under "churn" and written off as a cost of doing business. It isn't. Around a quarter of lapsed subscriptions are payment failures, a figure Stripe has put forward and Slicker reports. The customer wanted to stay. The payment just didn't arrive.

Involuntary churn is the mirror image of the voluntary kind you manage through a subscription centre that turns the unsubscribe into a conversation. One is a choice you can sometimes talk someone out of. The other is a logistics failure you can quietly fix. If you've already built the retention side—the win-back campaigns and at-risk segments in our complete retention playbook for SaaS churn—this is the half that has nothing to do with whether people like your product.

Why your billing provider's emails aren't enough

Stripe, Chargebee, Recurly and the rest all send failed-payment emails out of the box. They're better than nothing and worse than what you can build. The defaults come from your biller's domain, not yours. They're generic, awkward to brand, and they live outside the system where you already manage timing, segmentation and channels.

You already hold the customer in Customer.io with their plan, their usage, their lifecycle stage. The biller's email knows none of that, can't escalate to SMS, and can't coordinate with the rest of the customer's experience. A failed-payment email is also a transactional message, and transactional messages get opened far more reliably than marketing ones. That attention is wasted on a plain-text Stripe default. The same logic that turns receipts into a revenue engine with Customer.io applies here: you own a moment the customer is paying attention to, so use it properly.

The build in Customer.io

Three pieces make up the flow: getting billing events in, timing the sends around the retry window, and suppressing on recovery. Here's each one.

Ingest the billing events

Start by getting your billing events into Customer.io. There are two ways to do it, and the right one depends on whether you can put a small relay in front.

The no-code path uses Customer.io's webhook trigger. Create a webhook-triggered campaign and Customer.io generates a unique URL; point your Stripe webhook at it for events like invoice.payment_failed, invoice.payment_succeeded and customer.subscription.deleted. A webhook-triggered campaign can't send a message on its own, because the incoming webhook is the subject, not a person. So you use the Send Event action to turn the payload into an event attached to the customer, matched on an identifier like their email or your own user ID. That event then triggers the campaign that actually sends the emails. Customer.io's webhook campaign documentation walks through the Send Event step.

The cleaner production setup puts a small endpoint of your own between Stripe and Customer.io. Your server receives the Stripe webhook, verifies the Stripe-Signature header so you know the request is genuine, then posts a track event to Customer.io's Pipelines API. Customer.io recommends the Pipelines API over the older Track API for new integrations. The relay costs you a few lines of code and buys you signature verification, your own retry handling, and the freedom to reshape Stripe's payload before it lands.

Which to pick? The direct webhook path ships faster and is fine for a first version. It just can't verify that a request genuinely came from Stripe, so anyone who learns the URL could post to it. For a flow that touches billing, verify the signature before you trust the event in production. Either way, the wider patterns—webhook ingestion, the Track and Pipelines APIs, reverse ETL—are covered in our guide to integrating data sources with Customer.io.

Respect the silent-retry window before you email

Don't email on the first failure. The single most important decision in dunning is to retry before you contact anyone.

Churn Buster, which has run dunning since 2013, reports that 21% of failed payments recover through silent retries before the first email is ever sent, and that roughly half of all recovery comes from retries alone, as ChurnWard summarises. Stripe's own Smart Retries handle much of this for you; ChurnWard puts them at recovering around 57% of failed payments before you've written a single email. Add the account-updater self-healing from the top of this post and a real slice of your "failed" payments were never going to need an email at all.

There's a hard reason not to hammer the card yourself, too. ChurnWard's rundown of the card-network rules notes that Visa allows 15 retry attempts in 30 days and zero retries on hard-decline codes like an expired or invalid card. Mastercard caps retries and charges fees past its limits, and issues "Do Not Try Again" advice codes you're required to honour. Let your biller's retry logic respect those rules. Your job in Customer.io starts after the silent retries have had their go, usually a day or two in, not at minute zero.

The sequence: timing, copy and channel

Once you're emailing, send three to five messages over about 28 to 30 days, and don't stop early. ChurnWard, summarising Baremetrics' analysis of more than a million dunning emails, found the day-of-failure email is the strongest single touch at a 13.25% recovery rate. But the long tail matters: the day-30 email still recovers 4.2%, and up to 42% of all recovery happens after day 14. Teams that close their dunning window at day 7 or 14 leave close to half the recoverable revenue behind.

A cadence that works: a first email once the initial retry has failed, often the same day, then follow-ups around day 3, day 7, day 14 and day 28. Each one earns its place. The marginal email at day 28 recovers less than the first, but it still recovers.

Tone does real work here. Write to a customer who wants to stay, not to a debtor. "We couldn't process your payment" beats "your payment is overdue." Reference the plan they're on and the feature they'd lose. Personalised dunning messages are far likelier to get a response—Slicker puts it at 62% more likely than a generic one. And keep the action to a single click: a tokenised link straight to a pre-filled card-update page, no login required. Every extra step in that update flow sheds customers who meant to pay.

The hard stop: suppress on recovery

The fastest way to annoy a paying customer is to keep dunning them after their payment has gone through. Build the stop before you build the sends.

You're already ingesting invoice.payment_succeeded and customer.subscription.deleted. Turn each into an event—say payment_recovered and subscription_cancelled—and set them as exit conditions on the dunning campaign. The moment a recovery event lands, the customer drops out of the sequence and the remaining emails never send. This is exactly where the account updater bites: a card silently refreshed by Visa or Mastercard recovers the payment, Stripe fires the success webhook, and your suppression logic pulls the person out before email two. Without that wiring, you email someone whose payment already cleared and manufacture a complaint out of a non-event.

This is suppression doing its job, the same discipline covered in our guide to frequency management and the art of not sending. Dunning is one of the few flows where a missed suppression doesn't just waste a send. It damages a relationship with someone who just paid you.

Channel escalation: email, then SMS or WhatsApp

Email carries the first few touches. For the ones that don't land, SMS and WhatsApp reach customers that email can't. SMS open rates sit near 98% against 20 to 40% for email, per figures ChurnWard collects, and most people read a text within minutes. That makes SMS a strong escalation channel for the later, more urgent stages. Introduce it after the second or third email, not as a final resort.

For audiences outside the US, WhatsApp often beats SMS outright. Customer.io ships native WhatsApp and LINE now, which changes the maths for any brand whose customers don't live in the US—the case we made in why native WhatsApp and LINE change the omnichannel maths. A dunning flow that's email-only is quietly missing the channel a large part of your base actually reads.

One caution: consent still applies. A failed payment doesn't grant you SMS or WhatsApp permission you didn't already have. Keep billing-related messaging inside the consent you've collected and the rules of each channel.

The one number to report: net involuntary churn recovered

Report recovered revenue, not opens. The metric that matters is net involuntary churn recovered—the MRR you would have lost to failed payments and got back.

Open and click rates on dunning emails tell a finance team almost nothing. What they want is the recovered amount, and ideally proof that your flow caused it rather than the silent retries that would have fired anyway. A holdout gives you that proof. Hold back a small, random slice of failed payments from your Customer.io flow, let them receive only the biller's defaults, and compare recovery rates. The gap is your flow's real contribution.

Customer.io made holdouts a checkbox inside the A/B test flow, which is the cleanest way to measure this, covered in why every lifecycle campaign should have a holdout. And recovered subscribers are worth more than the single payment: Stripe's data, echoed by Slicker and ChurnWard, shows a recovered subscription continues for an average of seven more months. One save is several months of MRR, not one.

A 30-minute first version

You don't need the full architecture to start. Here's a version you can ship this afternoon.

Create a webhook-triggered campaign in Customer.io and copy its URL. In Stripe, add a webhook endpoint pointing at it for invoice.payment_failed and invoice.payment_succeeded. In the campaign, use Send Event to convert a failed-payment webhook into a payment_failed event on the customer, matched by email. Build a second, event-triggered campaign off payment_failed with two emails—one a couple of days in, one a week later—each carrying a one-click update link. Add an exit condition on a payment_recovered event so anyone who pays drops straight out.

That's a working dunning flow. It won't have SMS, holdouts or signature verification yet, but it will start recovering revenue that's currently walking out the door... and you can layer the rest on once you've watched the first saves land.

Frequently asked questions

What is involuntary churn, and how big is it?

Involuntary churn is churn caused by a failed payment rather than a customer choosing to cancel. An expired card, a declined cross-border charge, or insufficient funds on billing day all count. Sources put it at 20 to 40% of all churn for subscription businesses, with Dodo Payments and ProfitWell both landing in that range. The customer usually still wants the product, which is what makes it recoverable.

What is dunning?

Dunning is the process of chasing a failed payment to recover it. It combines two things: automated retries of the charge itself, and a sequence of messages asking the customer to update their card if the retries don't work. A good dunning flow does the retries first and only emails once they've failed.

How do I send dunning emails from Customer.io instead of Stripe?

Get Stripe's billing events into Customer.io, then trigger your own campaign off them. The no-code route is a webhook-triggered campaign: Customer.io gives you a URL, you point a Stripe webhook at it, and you use the Send Event action to convert the failed-payment payload into an event on the customer. That event triggers an ordinary event-triggered campaign that sends branded emails. Customer.io's webhook campaign docs cover the setup.

Should I email on the first failed payment?

No. Let the silent retries run first. Churn Buster reports that 21% of failed payments recover through retries before any email is sent, and ChurnWard puts Stripe's Smart Retries at around 57% recovered before a single message goes out. Emailing at minute zero interrupts a recovery that was already happening and risks reminding a happy customer they have a subscription to cancel. Start your sequence a day or two in, once the first retry has failed.

How many dunning emails should I send, and over what period?

Three to five emails over roughly 28 to 30 days for monthly subscriptions. ChurnWard's data shows up to 42% of recovery happens after day 14, so cutting the window short at day 7 forfeits a large share of it. A workable cadence is a first email once the initial retry fails, then follow-ups around day 3, 7, 14 and 28. Annual subscribers justify a longer window.

How do I stop dunning someone whose payment already went through?

Ingest the recovery events—invoice.payment_succeeded and customer.subscription.deleted—turn them into events in Customer.io, and set them as exit conditions on the dunning campaign. When a recovery event arrives, the customer drops out and the remaining emails don't send. This matters most with card-network account updaters, which can recover a payment silently; without the suppression, you'd email someone whose card already cleared.

Should dunning use SMS or WhatsApp as well as email?

Email handles the early touches; SMS and WhatsApp are for escalation. SMS open rates sit near 98% versus 20 to 40% for email, per figures ChurnWard collects, so they reach customers email misses. Introduce them after the second or third email rather than as a last resort. For audiences outside the US, WhatsApp often outperforms SMS. Consent still applies—a failed payment doesn't grant messaging permission you didn't already have.

What's a good payment-recovery rate?

The median sits around 50% of failed payments recovered, according to ChurnWard. A well-configured flow with smart retries and a solid email sequence reaches 60 to 70%, and the best ML-driven systems push into the 70 to 85% range. If you're recovering well under half, the retries or the email sequence need work. Break the number down by recovery method to see which part is earning its keep.

Do I need a backend relay, or can Stripe webhook straight into Customer.io?

Both work. Pointing Stripe's webhook directly at a Customer.io webhook-triggered campaign is faster to ship and fine for a first version. The trade-off is that Customer.io's inbound URL can't verify Stripe's signature, so anyone who learns the URL could post to it. For production, put a small relay in front that checks the Stripe-Signature header and forwards a clean event to Customer.io's Pipelines API.

Does the card-network account updater make dunning unnecessary?

No, but it does a meaningful chunk of the work. Visa's Account Updater and Mastercard's Automatic Billing Updater refresh reissued cards automatically, cutting hard declines by an estimated 30 to 50% per figures ChurnWard cites from Stripe and Cybersource. That recovers some failures with no email at all, which is exactly why you wait for the retry window before emailing. It doesn't help with insufficient funds or cards the updater can't refresh, so you still need the flow.

What metric should I report for a dunning flow?

Net involuntary churn recovered: the MRR you would have lost to failed payments and got back. Opens and clicks don't translate to anything finance cares about. To prove your flow caused the recovery rather than the retries that would have fired anyway, run a holdout—keep a small random slice of failed payments out of the flow and compare recovery rates.

How long do recovered subscribers stay?

On average, about seven more months. Stripe's data, reported by both Slicker and ChurnWard, shows subscriptions recovered through dunning continue for an average of seven additional months. So a single save isn't one payment recovered—it's several months of MRR, which is what makes the flow's return compound.

Sources

• Involuntary Churn: How Failed Payments Silently Kill SaaS Revenue. Dodo Payments, 26 March 2026.
• Dunning Emails vs. Intelligent Retry Logic: 2025 Data on Subscription Revenue Recovery. Slicker, 7 September 2025.
• Dunning Best Practices: 7 SaaS Strategies. ChurnWard, 2025.
• Webhook campaigns. Customer.io Docs.
• Differences between the Pipelines and Track APIs. Customer.io Docs.