What Is Pre-Dunning? The 3-Stage Timeline for Stopping Involuntary Churn Before It Starts

Pre-dunning is the set of proactive payment-method interventions that fire before a subscription charge, so the payment never fails in the first place. The three tactics are an expiring-card email cadence, an in-app update nudge, and account-updater enrollment.

Most writing about dunning treats it as a billing problem. From building one myself, it's a customer-communication problem with billing as a side effect. The cheapest version of that communication happens before any charge fails.

Get this layer right and you cut the involuntary churn that shows up in Stripe or Recurly, with no extra work for your billing team.

Key takeaways

• Run three proactive steps before a charge to prevent the failure.
• Send an expiring-card email 30 days before expiry, another at 7 days.
• Treat pre-dunning and dunning as one playbook, prevention then recovery.
• Check account-updater enrollment first to skip auto-refreshed cards.
• Replace the email with in-app push for mobile-app subscribers.

What is pre-dunning?

Pre-dunning prevents a payment failure before the charge runs, while dunning recovers revenue after a charge has already failed. Pre-dunning reaches the customer while their card still works.

Dunning is the sequence you run once a charge bounces.

The difference is timing. A pre-dunning message reaches the customer while they still have time to act, before anything breaks. A calm "update your card" prompt earns a better response than an alert that something already failed.

Pre-dunning only touches involuntary churn, the customer loss caused by failed payments rather than a decision to leave. It does nothing for the customer who chooses to cancel.

That kind of voluntary churn is a job for the cancel flow. If someone has already decided to go, pre-dunning is irrelevant.

Why payment failures happen before pre-dunning can help

Pre-dunning can prevent only two of the three causes of involuntary churn, card expiry and card reissuance, while soft declines fall through to dunning. The three split by how much warning you get, which decides whether you can prevent the failure or only recover from it.

A 2023 PYMNTS survey found that failed payments cause half of all subscription churn. Pre-dunning won't stop every one of those failures, but the cheapest ones to stop are the two it reaches before the charge.

Each cause maps to its own recovery tool, and the involuntary churn rate guide covers that mapping. The narrower question for pre-dunning is which of these you can see coming early enough to prevent.

Card expiry (the most preventable cause)

Card expiry is the one failure you can predict, because the expiry month is stored on the card token long before the card stops working. Your payment processor holds the old details, and the next charge after the expiry date fails unless someone updates the card.

That stored date is what sets this case apart. You know the exact month a card will stop working, so you can reach the customer while the current card still goes through. It's the best moment to act, and it's why Stage 1 of the timeline comes first.

Card reissuance (handled by account updater, not email)

When a bank reissues a card after loss, theft, or fraud, account updater refreshes the stored credentials automatically, so no email is needed. Card replacement breaks a huge number of recurring charges, and most of it resolves without the customer ever knowing.

Account updater (CAU) refreshes a customer's stored card when the network has new credentials. Because it runs silently, reissuance is a hygiene task rather than a communication one.

The work here is confirming enrollment, not writing a message, which is why it sits at Stage 3 as a hygiene check.

Soft declines (no pre-dunning remedy, dunning handles these)

A soft decline is a temporary failure the network lets you retry, like insufficient funds or a network timeout, and nothing proactive can prevent it. You can't see a customer's bank balance the day before billing, so there's no prompt to send and no card to fix in advance.

Soft declines fall straight through to dunning, where the remedy is a retry sequence after the charge fails. Knowing which failures belong to pre-dunning and which belong to dunning keeps you from trying to prevent the unpreventable.

The breakdown of soft declines versus hard declines shows which codes the network lets you retry.

The pre-dunning timeline

A complete pre-dunning playbook runs in three stages before the billing date. Run them in this order:

1. Expiring-card email cadence: the most effective send, and the one you control directly.
2. In-app payment-method update nudge: catches active users who missed the email.
3. Account-updater enrollment confirmation: the hygiene check that stops you over-messaging.

The order follows how much control you have. You own the email outright, so it goes first. The in-app nudge backs up the email for people who open the product but ignore their inbox.

The account-updater check comes last because its job is to suppress the other two for customers whose cards the network will refresh on its own.

Stage 1: expiring-card email cadence

Send the first expiring-card email 30 days before the card's expiry month and a second at 7 days, and Stripe automates the 30-day reminder for you. You set it up once under Stripe's billing settings, and the trigger handles the rest.

The two sends cover two different misses. The 30-day email gives the customer enough runway to update the card before the next cycle. The 7-day email catches anyone who skimmed past the first one, and it's the last prompt before the charge runs.

Say your subscriber's Visa expires at the end of October and you bill on the 15th. The first email fires October 1st and the second fires October 24th. Both land before the November 15th charge, so the card gets updated, the charge clears, and no dunning sequence ever starts.

The cadence works only when the expiry date is visible in your payment token, which Stripe stores natively.

Some older card-vaulting setups keep the token without the expiry metadata. For those, account updater is your only pre-dunning layer for an expiry event.

Stage 2: in-app payment-method update nudge

An in-app banner shown to subscribers with a card expiring within 30 days catches the active users who open your product but skip email. It links straight to the payment-settings page, so updating the card takes under a minute.

People act on a prompt that appears where they already are. The nudge fires on session start for any subscriber whose stored expiry date is inside the 30-day window. So it only shows when the customer is already paying attention.

Picture a subscriber who logs in on October 5th with a card expiring October 31st. A banner appears at the top of the dashboard with an "update card" link. Once they update, the banner clears and you can suppress the Stage 1 email for them.

For products with low email open rates, like consumer subscriptions and B2C apps, the in-app nudge does more work than the email. Lead with this layer when you know your audience lives in the product and ignores their inbox.

Stage 3: account-updater enrollment confirmation

Confirm account updater is enabled as your first move, because a card it auto-refreshes should never trigger an expiry email. This is a prerequisite you check once up front, then a per-send suppression check is what runs last, after Stages 1 and 2 are built.

Account updater and the expiry email both fire on card-expiry events, which is exactly where they collide. If the network refreshes a card before your email sends, the email is still accurate but pointless, and the customer clicks through only to find their card already works.

Check the update log before each email trigger fires, and skip any subscriber whose card was already refreshed.

There's a limit worth knowing. Prepaid cards, some debit cards, and cards from banks outside the Visa or Mastercard network don't refresh on their own. For those, the email cadence is your only tool, so keep it running even when account updater is on.

If you'd rather not build and run this sequence by hand, Churn.io handles the automation.

How pre-dunning interacts with dunning

Pre-dunning and dunning are two halves of one playbook, where pre-dunning fires before the charge to prevent failures and dunning fires after one to recover revenue. Pre-dunning can't reach every failure mode, so dunning catches the rest.

Card expiry and reissuance are addressable before the charge. Soft declines from insufficient funds or network timeouts only show up when the charge runs, and so do hard declines from closed or fraud-flagged accounts.

Those failures need the post-failure dunning playbook to recover.

So the two sequences run on different failures without overlapping. When a card is expired, pre-dunning resolves it before the charge. When the charge fails anyway on an insufficient-funds decline, your dunning sequence takes over and works the timed retries and emails.

Pre-dunning still leaves a real share of failed charges for dunning to handle, mostly soft declines, and retrying a hard decline too aggressively can even escalate into chargebacks.

Prevention lowers the total volume of failures that recovery has to clean up. It does not replace recovery.

Use the churn rate calculator to size the revenue at risk before you decide which pre-dunning stage to build first.

Mobile-app pre-dunning: what changes when you do not control the card expiry

On Google Play and the App Store, you can't see a card's expiry date, so the in-app push is your only pre-dunning move. The email cadence drops out entirely.

Apple and Google run the billing here, and they hand you a "billing issue" event after a renewal fails, with no card-level data beforehand.

Because the platform controls billing, only Stage 2 is left. You can't send a custom expiring-card email with an update link, so the nudge has to use the platform's own billing-issue prompt instead. The card data that Stages 1 and 3 need isn't yours to read.

Hybrid businesses can split the difference.

Run the full three-stage timeline for web subscribers, where you control the card data, and the platform-restricted Stage 2 for mobile subscribers. Segment by acquisition channel first, then deploy the version each segment can actually support.

FAQ

How does dunning reduce involuntary churn?

Dunning recovers revenue after a payment fails. It retries the charge on a schedule and emails the customer to update their card, working on the failures pre-dunning can't prevent.

Can I get sued for emailing subscribers about their expiring card?

A transactional notice about a card on an active subscription is generally low-risk under CAN-SPAM and ROSCA, because it concerns a service they already pay for. Keep the email purely about the account, and handle consent for EU subscribers under GDPR.

What is the difference between pre-dunning and account updater?

Account updater is one tactic inside pre-dunning rather than a separate program. Pre-dunning covers all three proactive stages before a charge, and account updater is the stage that refreshes card credentials silently with no customer message.

Does pre-dunning work for B2B SaaS with annual billing?

Yes, and the expiring-card email matters more on annual plans, because there's only one charge a year and a single failure costs twelve months of revenue. The same 30-day and 7-day cadence applies, timed to the annual renewal date.