Card Update Campaign Planner: The Expiry Wave
Cards do not expire randomly. They expire in waves — the month printed on the plastic, batched by when thousands of your subscribers first signed up or last replaced a card — and every expiry date is sitting in your billing system months in advance. A card update campaign turns that calendar into renewals saved before they ever fail: pull the expiry report, segment it, send three touches in the right order, and measure the updated rate by segment. This planner runs the whole wave, start to finish, with no guessed yields — your own first wave sets your baseline.
Run this alongside your network card updater, not instead of it. Updaters silently refresh many cards, but they miss plenty, and they never tell the subscriber anything changed. Our explainer on card updater services covers what they do and do not catch; the campaign below covers the rest — the subscribers whose new card only they can provide. The destination for every touch is a hosted update page built to the standard in our card update page guide: mobile-first, no login wall if you can avoid it, and a confirmation the moment the new card saves.
Step 1: Pull the expiry report (day −45)
Forty-five days before the wave month, export every active subscription whose card expires in that month. You need five fields per row: subscriber, plan and plan value, expiry month, email deliverability status, and whether a network updater is enrolled for that card. Most billing platforms — including Stripe, Recharge, Seal Subscriptions, Skio, Loop Subscriptions, Chargebee, Recurly, Braintree, and Paddle — expose card expiry in their subscription or payment-method exports; if yours buries it, ask support for the report rather than guessing. Clean the list before anything sends: remove cancelled accounts, remove accounts already in an active dunning sequence (they get the recovery flow, not this one), and remove anyone whose card has already updated since the export.
Step 2: Segment the wave
| Segment | Definition | Why it gets its own handling |
|---|---|---|
| A — High value | Top plans / annual plans in the wave | A failure here costs the most; these get all three touches plus a support flag |
| B — Standard | Everyone else on recurring plans | The bulk of the wave; the standard 3-touch sequence |
| C — Updater enrolled | Cards covered by a network updater | Send Touch 1 later — give the updater the first chance to fix it silently, then campaign whoever remains |
| D — At risk | Prior failed payment in the last 6 months, any reason | These subscribers have already shown payment fragility; earlier first touch, plainer copy |
Segment by expiry month first, then by value inside the month. The output of this step is a dated send list, not a vague audience: every row knows its segment, its three send dates, and the exact link it will receive.
Step 3: The 3-touch send order
| Touch | Timing | Channel | Copy points — include all of these |
|---|---|---|---|
| 1 — The heads-up | 30 days before expiry | Subject names the month ("Your card ending [last4] expires in [month]"); body states the consequence plainly — the renewal on [date] will fail on an expired card; one button to the update page; reassurance that updating changes nothing else about price, plan, or billing date | |
| 2 — The nudge | 10 days before expiry | Email, plus SMS for opted-in Segment A and D | Shorter than Touch 1; leads with the renewal date, not the expiry date; repeats the single link; adds one line on what happens if they do nothing — a failed payment, then the standard recovery sequence |
| 3 — The last call | 3 days after expiry, before the renewal attempt where your billing date allows | Email + SMS where opted in | States the card has now expired; the renewal on [date] needs a new card before it runs; same link; no false urgency — if the renewal already failed, this touch is replaced by your dunning sequence, not sent alongside it |
Copy discipline across all three touches: the sender name is your product, the link domain matches the sender domain, and the page the link opens shows the subscriber's name, plan, and the card's last four digits being replaced. Every mismatch between email and page costs updates — subscribers are right to be suspicious of card-update emails, and your job is to remove every reason for suspicion except the healthy one that makes them check the domain.
Step 4: Landing-page requirements (non-negotiable)
- Works logged out, via the signed link, on a phone, in under a minute.
- Shows what is being replaced: "Card ending 4242, expiring [month]" — never a blank form with no context.
- Confirms instantly on save, on screen and by email, naming the next billing date the new card protects.
- Handles the already-fixed case: if the card was updated since the send, say so warmly instead of demanding another.
- No offers, no upsells, no survey. This page has one job. Every extra element is paid for in abandoned updates.
Step 5: Measure the wave — and prove it worked
| Metric | How to compute it | What it tells you |
|---|---|---|
| Updated rate by segment | Cards updated before renewal ÷ cards in segment at export | Whether segmentation and touches are earning their complexity |
| Silent updater rate | Segment C cards refreshed with no campaign click | What the updater alone would have saved — your campaign's true baseline |
| Expiry-failure rate | Renewals in the wave that failed on expired-card declines ÷ wave renewals | The headline result: compare against your last un-campaigned wave |
| Touch attribution | Updates within 48 hours of each touch ÷ segment size | Which touch does the work; if Touch 3 dominates, your early copy is too soft |
| Cost per prevented failure | Campaign time + send costs ÷ failures prevented vs baseline | The number that justifies running every wave, every month |
Judge the campaign on prevented failures, not clicks. Then feed the prevented-failure count into our recovery calculator to put a revenue figure next to it, and compare your expiry-failure rate with the broader picture in our failed payment recovery benchmarks. Context worth remembering while you plan: across 5.4M failed payments analysed by Churnkey from Stripe data, insufficient funds is the largest decline family at 40.6% — expiry is not the biggest failure family, but it is the most preventable one, because you can see it coming a month out. That is the entire case for the campaign.
Running it as a rhythm, not a project
Put the wave on a monthly calendar: export on the first week, Touch 1 mid-month for next month's expiries, measurement two weeks after the wave's renewals run. Assign one owner. Keep a one-page wave log — segment sizes, send dates, updated rates, expiry-failure rate — so wave three can be compared with wave one and the planner improves instead of just repeating. The teams that lose renewals to expired cards are rarely missing technology; they are missing the recurring hour.
The bottom line
An expiry wave is a list of future failures with dates on them — the only churn you are warned about in writing, a month ahead. Pull the report, segment by value and fragility, send three honest touches to one clean update page, and measure prevented failures against your last un-campaigned wave. Do that monthly and expired cards stop being a churn line and become a routine. If you would rather the update pages, touches, and the recovery sequence behind them ran as one system, the next step is our pricing page — flat pricing and a 14-day trial.
Frequently asked questions
How far ahead should a card update campaign start?
Pull the expiry list about 45 days before the expiry month and send the first touch about 30 days before the card expires. That gives subscribers time to act on a calm heads-up rather than a deadline, and leaves room for the second and third touches before the renewal is at risk.
Does a network card updater make this campaign unnecessary?
No. Updaters refresh many cards silently, but coverage is partial — some issuers and card types do not participate, and some updates never arrive. The campaign catches the remainder. Segment updater-enrolled cards separately so you can see exactly what the updater handled and what your touches had to earn.
What if a subscriber updates their card but the campaign keeps emailing them?
That is a data-refresh failure, and it erodes trust fast. Re-check the list before every touch, suppress anyone whose card has updated since the export, and make the landing page recognise an already-updated card and say so, instead of asking for another one.
Should the campaign include a discount or incentive?
Almost never. Updating a card costs the subscriber a minute, not money, and attaching an offer teaches them to wait for one. Spend the effort on clarity — the right date, the right consequence, a page that works on their phone — and reserve offers for subscribers who are actually deciding whether to stay.
How do I prove the campaign worked?
Compare the wave's expiry-failure rate — renewals that failed on expired-card declines, divided by all renewals in the wave — against a previous wave you did not campaign. Report the updated rate by segment alongside it, so you can see whether the result came from the updater, the touches, or a particular segment's behaviour.
Stop losing subscribers
who never meant to leave.
Every billing cycle without recovery is revenue you earned and never collected. Connect in 2 minutes — see your first wins inside the trial.
Start trialFree 14-day trial · No code · Cancel anytime