About 30% of failed subscription payments are caused by a single thing: the card on file changed. It expired, got replaced after a breach, or the customer lost it and got reissued. Without a card updater, you find out the hard way when the charge fails, the customer ignores your email, and the subscription churns.
Stripe Account Updater solves this automatically for most cards. It is one of the highest-ROI features any SaaS can enable - often recovering 5-10% of otherwise lost revenue with zero ongoing work. But it has real limits, and many teams enable it without understanding what it does not cover.
This guide covers exactly how Account Updater works in 2026, which cards are covered, what it misses, how much it costs, and how to combine it with proper dunning to get the full recovery benefit.
What Stripe Account Updater Actually Does
Stripe Account Updater is a background service that checks your saved cards against the Visa, Mastercard, American Express, and Discover card-updating networks. When those networks report that a card number or expiration date has changed, Stripe automatically updates the saved payment method in your account.
The customer does nothing. You do nothing. The card details refresh silently in the background, and the next subscription charge succeeds against the new card.
Under the hood, it uses three underlying networks run by the card schemes themselves:
- Visa Account Updater (VAU) - Visa's card update network
- Mastercard Automatic Billing Updater (ABU) - Mastercard's equivalent
- American Express Account Updater - Amex's equivalent (smaller coverage)
- Discover Account Updater - Discover's equivalent (US only)
The card networks receive card-change events directly from issuing banks when a card is reissued, replaced, or has its expiration date updated. Stripe queries these networks on your behalf and applies any updates to your stored payment methods.
How to Enable It
In most Stripe accounts, Account Updater is enabled by default as of 2024. To verify:
- Go to Stripe Dashboard → Settings → Payments → Card updates
- Confirm that "Automatic card updates" is toggled on
- Review which card networks are enabled (Visa, Mastercard, Amex, Discover)
If you are on Stripe Billing, there is nothing else to configure - the updated card is automatically used for the next invoice charge. If you are managing subscriptions outside Stripe Billing (custom charge logic), make sure your code reads the latest payment method from the customer object rather than caching the PM ID.
What It Covers
Account Updater handles four specific card change events:
| Event | What Happens | Coverage |
|---|---|---|
| Card expired and reissued | New expiration date (possibly new last 4) | High - 70-80% of expirations |
| Card replaced after breach | New card number, same account | High - most major issuers participate |
| Card replaced by customer | New card number (lost/stolen) | High - same channel as breach replacement |
| Account upgrade (e.g., basic to rewards) | New card number, same customer | Medium - depends on issuer |
Realistically, if you have 1,000 active subscriptions and 30% of cards change each year, Account Updater will silently save 200-250 of those automatically. That is significant revenue preserved with zero intervention.
What It Does NOT Cover
This is where most teams get tripped up. Account Updater is not a substitute for dunning or a failed payment recovery tool. It only solves one specific problem: outdated card details.
It does nothing for:
- Insufficient funds. The card details are correct. The customer just does not have the money today.
- Fraud flags and
do_not_honordeclines. The bank is blocking the charge for reasons unrelated to the card data. - Customer-initiated cancellations or card cancellations. If the customer cancels their card without a replacement, there is nothing to update.
- Non-participating issuers. Smaller banks and prepaid/debit card issuers often do not participate in the card update networks. For those, expired cards stay expired until the customer acts.
- International coverage gaps. Coverage is strong in the US and Canada, good in Western Europe, and patchy elsewhere. Cards from some regions simply do not participate.
- Customers who switched banks entirely. A new card at a new bank is not an "update" - it is a new payment method. The customer must add it themselves.
- Expired cards where the customer does not have a new one. If the card expired and the customer never got a replacement, no update exists to pull.
In practical terms: Account Updater handles about 30-40% of the failed-payment problem. The remaining 60-70% still needs proper dunning with retries and customer outreach.
Cost
Stripe Account Updater is included free in most Stripe plans as of 2026. There is no per-update or per-card fee - it is part of the standard Stripe Billing offering.
If you are on a custom or enterprise contract from before the 2024 changes, check with your Stripe rep - older contracts sometimes had a per-update fee, usually in the $0.25 range. Almost always worth paying given the revenue saved, but worth knowing.
Paddle's Equivalent: Paddle Retain
Paddle does not have a standalone "Account Updater" - it is bundled into Paddle Retain, their dunning product. Paddle Retain includes:
- Automatic card updater (same networks as Stripe)
- Retry logic (up to 7 attempts over 30 days)
- Dunning email sequences
- Basic recovery analytics
It is enabled by default on Paddle subscriptions. You do not turn it on - you just use it. Paddle Retain's recovery rates are broadly comparable to Stripe Smart Retries - good for a baseline, not enough for optimized recovery.
Account Updater + Dunning: The Combined Strategy
Account Updater handles the passive 30%. Dunning handles the active 70%. Running both is how you actually recover 80%+ of failed payments.
The right mental model: Account Updater is a silent background feature that works for you. Dunning is the active layer that works on everything Account Updater misses. Running them together is how you get recovery rates above 70%.
A realistic breakdown of a $10k/month failed-payment problem:
| Recovery Layer | Typical Recovery % | Recovered (of $10k) |
|---|---|---|
| Stripe Account Updater (silent) | 15-20% | $1,500 - $2,000 |
| + Stripe Smart Retries only | +15-20% | $3,000 - $4,000 total |
| + Email dunning sequence | +15-20% | $4,500 - $6,000 total |
| + Multi-channel (SMS/WhatsApp) | +15-25% | $6,000 - $8,000 total |
| + Smart retry timing by decline code | +5-10% | $7,000 - $8,500 total |
The jump from Account Updater alone (15-20% recovery) to a full stack (70-85% recovery) is 3-4x. That is the difference between accepting involuntary churn and actually fighting it.
Common Mistakes
Mistake 1: Assuming Account Updater Handles Everything
The most common mistake. Teams enable Account Updater, see some recovery in their dashboard, and conclude they have "handled" failed payments. They still have 60-70% of recoverable revenue leaking out the door. Account Updater is a layer, not a solution.
Mistake 2: Caching the Payment Method ID
Some custom Stripe integrations cache the pm_xxx payment method ID on their own database. When Account Updater refreshes the underlying card, the PM ID stays the same, but if your code is charging based on a cached card fingerprint or last-4, it may skip or mis-route. Always read payment method details fresh from Stripe at charge time.
Mistake 3: Not Handling the payment_method.updated Webhook
Stripe fires a payment_method.updated event when Account Updater refreshes a card. Most teams ignore it. If you display card details in your customer portal ("Card ending in 4242, expires 12/25"), you need to re-fetch and re-render on this webhook - otherwise the customer sees stale info and calls support.
Mistake 4: Forgetting About Non-Card Payment Methods
Account Updater only works on cards. If your customers pay with ACH, SEPA, BACS, iDEAL, or other bank-based methods, none of them have an equivalent updater. Those require a different recovery approach (usually a direct customer email when the mandate fails).
Mistake 5: Assuming International Coverage Is Uniform
Account Updater works great for US, Canadian, UK, and major EU cards. Coverage drops off sharply for Latin America, Southeast Asia, Africa, and the Middle East. If 30%+ of your customers are in those regions, budget for a higher baseline failed-payment rate even with Account Updater enabled - and invest more in active dunning.
How to Measure Whether It Is Working
In Stripe Dashboard:
- Go to Payments → Failed payments
- Filter by date range (last 30 days)
- Look for the "Automatically recovered" column or card update indicator
If you are on Stripe Billing, the Retention Report shows recovered revenue broken out by source. Account Updater recoveries show as "auto" in most reports.
A healthy number for a SaaS with Account Updater enabled and standard Stripe Smart Retries is 30-40% overall recovery. If your number is below 20%, something is wrong - usually either Account Updater is disabled, Smart Retries are off, or you have a high concentration of customers with non-participating issuers.
When You Need More Than Account Updater
Account Updater plus Stripe Smart Retries gets you to a recovery ceiling of about 35-40%. You hit diminishing returns fast beyond that unless you add:
- Customer-facing dunning emails timed to decline reason (the templates in our dunning email template guide)
- Multi-channel outreach for high-value customers (SMS, WhatsApp)
- Smart retry timing that adjusts based on decline code and customer behavior
- In-app banners for active users - they already have an account open, show them the failure
A dedicated recovery tool like Rebounce layers all of this on top of Stripe. Account Updater keeps doing what it does silently, and the dunning layer catches everything Account Updater misses. Combined, recovery rates typically land in the 70-80% range - which is the difference between "involuntary churn is a frustration" and "involuntary churn is mostly solved".
See exactly what Account Updater is recovering and what it is missing in your Stripe account. Free audit, no signup, 30 seconds.
Run free recovery audit →