Expired Card Decline Code: Why Retries Fail and the Two Fixes That Actually Work

An expired card decline means exactly what it says: the expiry date on the card you charged has passed, so the card is no longer valid. In Stripe it shows up as expired_card, and it is the most predictable failed payment in your entire business. You can see every single one of these coming months in advance, which makes it the most preventable too.

Yet it remains one of the biggest drivers of involuntary churn for subscription companies, because most founders handle it reactively or not at all. Let us fix that.

Why the retry button is dead here

Most decline codes leave room for optimism. Insufficient funds clears on payday. Do not honor clears when the bank relaxes. Expired card has no such path. The date on file is in the past, the card networks know it, and no amount of waiting changes a calendar.

This matters for how you configure your recovery flow. Every retry attempt on an expired card is a wasted attempt from your network allowance, and it delays the actions that actually work. If your dunning tool retries expired cards four times before emailing, it is burning a week on a lost cause.

Fix one: the account updater you already pay for

Here is the good news most founders never hear: when a bank issues a replacement card to your customer, the bank often reports the new details to the card networks' account updater services. Stripe plugs into these. The card on file quietly refreshes from the old expiry to the new one, the renewal charge goes through, and neither you nor your customer ever knows there was a problem.

When it works, it is magic. The failure rate on cards that get auto-updated drops to nearly zero, and it costs you nothing extra. We wrote a full breakdown of how Stripe's card updater works and what the coverage looks like if you want the details.

But the coverage is not total. Some issuing banks do not participate. Some customers do not get a replacement card because they closed the account or the bank changed products. And sometimes the update arrives after your renewal charge already failed. Depending on your customer mix, a meaningful slice of expiring cards slip through, and that slice is pure, preventable churn.

Who the updater misses

It is worth knowing exactly who falls through the cracks, because this is the population your pre-dunning emails exist for. The updater misses customers whose banks do not participate in the network programs, customers who closed the account rather than renewed it, customers whose bank swapped them to a different card product, and customers where the update simply arrived late. Add those up across a year of renewals and you are looking at a steady drip of failures that no amount of automation behind the scenes will catch.

There is also a timing hole even when the updater works. Say the card expires March 31 and the bank reports the new details on April 12. If your renewal fires April 5, it fails. The card eventually updates, but in the meantime the customer has entered your dunning flow, and how that flow behaves decides whether they stay.

Fix two: pre-dunning, the cheapest email in SaaS

Pre-dunning means contacting the customer before the failure, while their card still works. Stripe knows every card's expiry month. Your system can flag every card expiring next month and send a friendly note: heads up, your card ending in 4242 expires soon, here is a 30-second link to update it.

The economics are silly. This email prevents a problem instead of recovering from one. No failed charge, no grace period, no awkward you-owe-us message. The customer experiences it as you being on top of things, because you are. Recovery emails, even great ones, convert a fraction of failures. A pre-dunning email stops the failure from existing.

One nuance: send it from yourself, not from a billing system. A personal note gets opened and acted on. A no-reply notification gets the same treatment as every other automated email in their inbox. The medium is the difference between a card updated today and a cancellation next month.

Timing matters too. Thirty days out is the sweet spot for most businesses: close enough that the customer still remembers subscribing, far enough that they have time to find the new card when it arrives. Some founders send a second nudge at seven days if nothing has been updated. Both emails take minutes to write once and then run forever.

When the card did expire already

If you are reading this because the damage is done, the recovery email for an expired card is different from other decline codes in one important way: the customer must type new card details. There is no call your bank option. So the email should skip the diagnosis entirely and do two things: make the update link effortless, and make the ask feel small.

Something like: your card on file expired, happens to everyone, here is the link to add the new one, takes 30 seconds. No mention of failed charges, no urgency theater. The friendlier it reads, the faster it gets done. Our post on payment recovery emails that actually work has the full template structure.

A note on expired_card vs transaction not permitted

These two codes get confused because they often describe the same underlying event: a card that aged out. Some issuers report an expiring renewal as transaction not permitted instead of expired_card, especially when the replacement card has not been activated yet. If your dashboard shows a spike in either code, check the other before concluding anything. The fix is the same family either way: card updater, pre-dunning, and a painless update link.

Putting numbers to it

Cards typically run three to four years before expiry, which means around 25 to 30 percent of your cards on file age out every year, spread across every month. On 500 subscribers, that is 10 to 13 expiring cards hitting your billing every single month, forever. The account updater catches many. Pre-dunning catches most of the rest. The ones you neither update nor email about become your involuntary churn rate.

Run the math against your own MRR with the churn calculator if you want the number to sting properly. For most small SaaS companies, expired-card churn alone justifies the entire effort of setting up dunning.

A worked example makes it concrete. Say you have 500 subscribers at $30 a month, so $15,000 MRR. Around 11 of those cards expire each month. If the updater saves 7 and pre-dunning saves 3 of the remaining 4, you are left with 1 failure instead of 11. That is the difference between losing $30 a month to this code and losing $330, or about $4,000 a year, from a problem you can predict to the day.

This two-layer setup, automatic updates plus pre-dunning emails, is exactly how StayPaid handles expiring cards. The system watches expiry dates, the updater does its quiet work, and the emails that do go out read like they came from you, because you approved them before they sent. Expired cards are the most predictable revenue leak you have. They should also be the first one you plug.