How to Set Up Pre-Dunning: Card Expiry Emails That Stop Failed Payments (2026 Guide)

Pre-dunning means emailing a customer about a card that is about to stop working before the charge fails. To set it up, find the subscriptions whose default card expires this month or next, send each customer a link to update it, and stop as soon as they do. Three routes get you there — Stripe's own toggle, a script of your own, or a tool — and this guide walks through all three, step by step.

An expiring card is the most predictable cause of a failed payment there is. The expiry date is printed on the card and stored on the payment method, so unlike an insufficient_funds decline you can see this one coming weeks ahead. That is why the prevention half of recovery is the cheapest half: one email can save an invoice that would otherwise need a retry schedule and a four-email sequence. If the card has already failed, jump to our failed-payment recovery guide; if you want the concept first, read what dunning is.

Step 1: Decide how far ahead to email

Email about 30 days before the end of the expiry month, with a short reminder about a week before it for anyone who has not updated. A card works through the last day of the month printed on it, so a customer whose card says 11/26 is fine for a 30 November charge and declined on 1 December. Working back from the end of the month, not the start, is the most common thing people get wrong.

Why two touches rather than one? The first email catches the customer who reads it. The second catches the one who read it, meant to do it and forgot. Stripe documents the single one-month email; the second touch is our recommendation from how dunning sequences work, not a Stripe feature. Silent network refreshes can also update some cards before you email anyone — see Account Updater explained — which is why the later touch is the one that matters most.

Step 2: Pick how you will run it

There are three realistic routes, and the right one depends on how much control and maintenance you want. Start with the table, then read the route you are leaning towards.

Route A: Stripe's built-in expiring-card email

In the Stripe Dashboard, open the email notification settings and turn on Send emails about expiring cards. Stripe emails the customer one month before the card on file expires — their default payment method or default source — with a link to update it, which can be the Stripe-hosted Customer Portal or your own page. It uses your branding settings. It is the right first move for almost everyone: it costs nothing and takes a minute. Its limits are that the timing is fixed and there is one email, not two. For where it sits among Stripe's other recovery features, see Stripe built-in recovery versus a dedicated tool.

Route B: Your own script

If you want the second reminder or your own copy, a small job that runs daily is enough. List active and trialing subscriptions, expand the default payment method, and compare the card's expiry month and year with today. A minimal version looks like this:

import Stripe from 'stripe'

// Use a restricted, read-only key on the server — never in the browser.
const stripe = new Stripe(process.env.STRIPE_RESTRICTED_KEY!)

const now = new Date()
const index = (month: number, year: number) => year * 12 + (month - 1)
const thisMonth = index(now.getMonth() + 1, now.getFullYear())

for (const status of ['active', 'trialing'] as const) {
  for await (const sub of stripe.subscriptions.list({
    status,
    limit: 100,
    expand: ['data.default_payment_method', 'data.customer'],
  })) {
    const card = (sub.default_payment_method as Stripe.PaymentMethod | null)?.card
    if (!card) continue // card saved only on the customer: look there next

    const monthsLeft = index(card.exp_month, card.exp_year) - thisMonth
    if (monthsLeft > 1) continue // 0 = expires this month, 1 = next month

    // queue one email per customer per month, then stop once the card changes
  }
}

Three details trip people up. First, the default payment method can live on the subscription or on the customer, and Stripe resolves them in a defined order, so read both. Second, trialing subscriptions with a card on file are worth including, because the first real charge arrives later. Third, run it on a restricted, read-only key on your server; a secret key in client code is a security incident waiting to happen.

Route C: A tool

Revova's pre-dunning is a switch under Settings. Once on, on Stripe, a daily job looks at your active subscriptions, finds the ones whose default card expires this month or next, and sends an AI-written email with a secure link to update the card. It sends at most one pre-dunning email per customer per month, skips customers with no email address or on your blocklist, and lists the cards it found in a Customers In Danger panel on the dashboard so you can see the exposure.

Step 3: Write an email that gets the card updated

The best pre-dunning email is short, names the card, and has one button. It should say which card (last four digits and expiry), what happens if nothing changes, and give a link that opens the update page directly — no login maze. The difference is easy to see side by side.

More copy to borrow, including the later steps once a charge has actually failed, is in our dunning email templates.

Step 4: Add the guardrails

Pre-dunning only helps if it is polite and stops when it should. Put these in before you turn it on.

1. De-duplicate. One email per customer per touch. Log what you sent and check the log before sending.
2. Stop when the card changes. Re-check the payment method right before the second touch; if it no longer expires soon, skip it.
3. Respect opt-outs. A blocklist or unsubscribe path is both courteous and a deliverability signal; see our deliverability guide for SPF, DKIM and DMARC.
4. Skip customers with no email address. Nothing to send, and nothing to error on.
5. Keep dunning ready. Some customers will not update. The normal retry and email sequence still has to catch them when the charge fails.

Step 5: Measure whether it worked

Track two simple numbers: how many customers you emailed about an expiring card, and how many of those updated before expiry. Divide the second by the first and you have an update rate for your own audience — we do not quote a benchmark for it because your mix of customers, plans and countries decides it. For the outcome, watch the first-attempt failure rate in Stripe's recovery analytics; Stripe itself suggests proactive reminders when that rate is high.

Annual plans deserve a special look: a card has a full year to expire before it is tested once, so the update rate there decides whether a whole renewal survives. We cover that case in how to reduce annual plan renewal failures. And once prevention is running, the failures that already happened are the next pot of money — the free Lost Revenue scan shows how large that backlog is.

Pre-dunning setup checklist

• Stripe's Send emails about expiring cards toggle is on (or you have your own job replacing it).
• You know whether your customers' cards live on the subscription, the customer, or both.
• The email names the card, the date and one button; it has been sent to yourself as a test.
• A second touch exists, and it skips customers who already updated.
• De-duplication, an opt-out path and a log are in place.
• You record emailed versus updated each month.

Frequently asked questions