Back to blog
Tutorials

Stripe Automatic Card Updater and Failed Payments: What It Actually Catches

How Stripe's Card Account Updater works, what it catches and what it misses, and when you still need a dunning tool to recover failed payments.

Rekko Team
April 8, 2026
6 min read
stripecard updaterfailed paymentsdunning

Stripe's Automatic Card Updater is one of those features that sounds like it solves your whole failed-payments problem. It promises to refresh expired and replaced cards automatically, before they ever fail a charge. If that worked for every customer, you wouldn't need a dunning tool.

It doesn't work for every customer. It works for a meaningful slice, and the rest still need the usual recovery playbook.

This guide covers what Stripe's card updater actually catches, where the gaps are, how to turn it on properly, and what to layer on top so you're not watching recoverable MRR walk out the door.

What Stripe's Automatic Card Updater is

Stripe's Card Account Updater (sometimes called Network Updater or Automatic Card Updates) plugs into the Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) networks. When a card is reissued, lost, stolen, or its expiration date changes, issuers can push the new card details to merchants participating in those networks.

Stripe handles the integration. When you enable it, Stripe periodically queries VAU and ABU for the cards on file in your account. If an issuer responds with updated details, Stripe silently swaps the card on the customer object. Your next charge goes through as if nothing happened.

No email, no friction, no recovery sequence. That's the best case.

What it actually catches

Realistic expectations matter here. Across Stripe accounts we've seen, the updater refreshes somewhere in the range of 20 to 40% of cards that would otherwise go stale. That's not a guarantee, it's a ballpark. The variance comes down to:

  • Which issuer the card belongs to
  • Whether that issuer participates in VAU or ABU
  • Whether the card brand is supported (Visa and Mastercard are, Amex and Discover mostly are not)
  • Whether the cardholder opted out of network updates at the bank level
  • Whether the card is personal vs commercial (commercial cards have lower participation)

Expired cards drive roughly 40% of involuntary failed payments. If Stripe's updater catches even half of those, you've quietly avoided a chunk of dunning work. If it catches none because your customer base skews toward smaller regional banks or Amex, you're in the same spot you were before.

What it misses

The updater is a silent background service. It doesn't catch:

  • Amex cards (Amex runs its own enhancer service that Stripe supports separately, but coverage is thinner)
  • Cards from issuers outside VAU and ABU, including many non-US banks
  • Customers whose bank opted them out of network updates
  • Soft declines unrelated to card validity (insufficient funds, fraud holds, issuer timeouts)
  • Cards that were updated between VAU sync windows (sync is not real-time)
  • International cards in markets where network updater coverage is weak

That last point matters for European SaaS especially. VAU and ABU coverage is strongest in the US. In the EU and UK, a material share of cards won't get refreshed, and SCA rules add another layer of complexity on top.

How to turn it on

For most Stripe accounts the updater is on by default, but you should verify it. Here's the checklist:

Step Where
1. Confirm card updater is enabled Dashboard, Settings, Payment methods, Card updates
2. Enable Network-level updates for Visa Same page, toggle per brand
3. Enable for Mastercard Same page
4. Enable Amex Account Updater if applicable Separate toggle, requires Amex merchant
5. Check "Automatic card updates" in customer events Dashboard, Events log
6. Set up webhook for payment_method.updated Developers, Webhooks

The webhook is the one most teams skip and then regret. If you listen for payment_method.updated with a network_reason of automatic_update, you can log exactly which cards Stripe refreshed. That gives you a clear picture of coverage in your specific customer base, which is the only number that matters.

Where the updater stops and dunning starts

Think of the updater as a pre-filter. It removes the easy wins before they ever hit your dunning queue. What reaches your dunning sequence is:

  • Cards the updater couldn't refresh (wrong issuer, opted out, Amex)
  • Soft declines (insufficient funds, temporary holds)
  • Hard declines (fraud, closed account)
  • Customers whose banks rejected the updated card (rare but real)

In practice, even with the updater fully enabled, you'll still see failed payments on roughly 60 to 80% of the volume you'd see without it. For a SaaS doing $100K MRR with average involuntary churn of 9%, that's still $5K to $7K per month flowing into recovery sequences.

The layered recovery stack that actually works

Here's the stack we recommend for Stripe-first SaaS:

Layer What it does Coverage
Stripe Card Updater Silently refreshes reissued cards 20 to 40% of expiring cards
Stripe Smart Retries Re-attempts failed charges on optimal schedule ~30% of failures
Dunning sequences (email + SMS) Asks the customer to update their card 60 to 80% of what's left
Customer support followup Handles the edge cases 5 to 10% of remaining

Stacked together, you can reasonably expect 75 to 85% total recovery of involuntary failures. Remove the dunning layer and you're probably sitting at 40 to 50%.

What a good dunning layer looks like

The dunning layer has to do the thing the updater can't, which is talk to the customer. A working sequence has three properties:

  1. Multi-channel. Email-only recovery tops out around 50 to 60%. Adding SMS moves the ceiling to 65 to 80%. That's the single largest lever.
  2. Pre-authenticated update links. If your customer has to log in, remember their password, and navigate to billing, you've lost half of them. One-click hosted update pages close the gap.
  3. Tied to Stripe events in real time. Polling is too slow. You want the first email out within minutes of the failure, while the customer is still in their inbox.

Where Rekko fits

Rekko is built for exactly this layer. It connects to Stripe via OAuth, listens for invoice.payment_failed in real time, and runs pre-built email plus SMS sequences against whatever the card updater couldn't save. Pre-authenticated payment update links come out of the box, setup takes around 5 minutes, and SMS is included at every tier.

If you've already turned on Stripe's card updater and smart retries and you're still watching MRR leak, Rekko is the part of the stack you're missing.

Start your 14-day free trial, no credit card required. Or compare it to Stripe Billing's built-in dunning if you want the side-by-side first.

Stop losing revenue

Ready to recover your failed payments automatically?

Join hundreds of SaaS companies using Rekko to recover 10-20x their investment. Set up in 5 minutes, see ROI in 24 hours.

No credit card required. 14-day free trial.

Related Articles