Network tokens and card account updaters: what they fix and what they don't

A subscription is a promise to charge the same card for months or years. Cards do not last that long. They expire, get replaced after a fraud alert, get reissued when a bank changes its card program, or are closed. Each of those events can turn a healthy customer into a failed renewal.

Card networks have two mechanisms to soften this: card account updaters and network tokens. Stripe uses both for you, mostly without any setup. They are worth understanding, because they explain why some cards keep working after they “should” have failed, and why others still fail no matter what. This guide covers both, based on Stripe’s and the networks’ own documentation (accessed November 2026).

The problem they solve

When you save a card for a subscription, Stripe stores the card number (the PAN) and expiry date, securely, on your behalf. If the customer’s bank issues a new card with a new number or a new expiry date, the stored details go stale. The next charge fails, typically with expired_card or another decline. See Stripe decline codes explained.

Both mechanisms aim to get the new details to you before that happens.

Card account updaters

How they work

A card account updater is a service run by a card network. Issuers that participate report changes to their cards (new number, new expiry date, closed account), and merchants or their payment providers can receive those changes for cards they keep on file.

The main ones:

• Visa Account Updater (VAU). Visa’s developer documentation describes it as a way for issuers, acquirers and qualified merchants to exchange updated account information for recurring and card-on-file payments, covering card numbers, expiry dates, closed accounts and “contact cardholder” advices.
• Mastercard Automatic Billing Updater (ABU). Mastercard’s developer documentation describes a repository of account lifecycle events: issuers tell ABU when an account is created, updated or closed. For a closed account, Mastercard’s guidance is that the merchant should use another payment method for future transactions.

What Stripe does

You do not integrate with these services yourself. Stripe’s cards overview explains that Stripe automatically attempts to update saved card details when a customer receives a new card, using the networks’ updater programs. Key points from Stripe’s docs:

• Coverage depends on the issuer and varies by country; it is strongest in the US.
• You cannot know in advance which cards will be updated.
• You can see updates as they happen. Stripe sends the payment_method.automatically_updated webhook with the new expiry date and last four digits. If the number changed, the card’s fingerprint changes too.

Stripe has also announced expanded network token and card account updater coverage, including real-time updates in some cases. Check the announcement for the current scope in your markets.

Network tokens

How they work

A network token is a substitute for the card number, issued by the card network (for example through the Visa Token Service), and tied to a specific merchant or payment provider. Instead of charging the raw card number, the payment provider charges the token.

The useful property for subscriptions: the token is linked to the cardholder’s account at the network, not to one physical card. When the issuer replaces the card, the network can update what sits behind the token. Visa’s token service documentation describes how issuers manage a token’s lifecycle (activate, suspend, resume, delete), and how Visa can pull updated card data from VAU to keep tokens current when the underlying card number or expiry date changes.

What Stripe does

Stripe’s guide to network tokens explains that Stripe tokenizes saved cards with the major networks where available, and decides for each payment whether to use the network token or the card number. If a payment on the network token fails, Stripe can retry it with the card number. Stripe’s guide also notes two trade-offs: using a network token often requires fetching a one-time cryptogram from the network, which can add latency, and some networks charge fees related to token use.

For most subscription businesses, none of this requires code. It is part of how Stripe processes saved cards.

Updaters vs tokens

	Card account updater	Network token
What it is	A feed of card changes from issuers	A substitute card number issued by the network
How the new details arrive	Stripe receives the update and changes the saved card	The network updates what the token points to
Visible to you	Yes, payment_method.automatically_updated webhook	Mostly not; the card keeps working
Depends on	Issuer participation, country	Network and issuer support
Covers expired and replaced cards	Yes, where the issuer reports them	Yes, where supported
Covers closed accounts	Can report the closure, so you know to ask for a new card	The token stops working

In practice they overlap, and Stripe combines them. You do not choose between them.

What they do not fix

This is the important part. Updaters and tokens solve one problem, stale card details, and only where issuers participate. They do nothing for the rest:

Failure	Fixed by updaters or tokens?	What does fix it
Card expired, issuer sent the new expiry	Yes	Nothing else needed
Card replaced, issuer sent the new number	Yes	Nothing else needed
Card expired, issuer does not participate	No	Pre-expiry email, card update page
Account closed	No (at best, you learn about it)	Ask for a new payment method
insufficient_funds	No	Retry at a better time; email
Generic decline, bank block	No	Retry; email; customer calls the bank
authentication_required	No	Customer confirms the payment
Customer switched banks entirely	No	Ask for a new card
Customer removed the card on purpose	No	Talk to the customer

That last row deserves attention. When a customer removes their saved card before a renewal, it is often a sign they intend to leave or dispute the next charge. It is a churn signal, not a payment problem, and it should be handled as one.

What to do on your side

Even with good coverage, you need a process for the cards that are not updated. The full approach is in expiring cards; in short:

1. Listen to the updates

Subscribe to payment_method.automatically_updated. Log each update (old expiry, new expiry, whether the number changed). It tells you how much of your base the networks are covering, and it lets you cancel any “your card is expiring” email you were about to send.

2. Find cards that will not be updated in time

Before each renewal, check whether the card on file expires before the renewal date. If it does, and no update has arrived by a week or two before the renewal, email the customer.

3. Watch for closures and removals

A closure report or a removed card means the next charge will fail. Ask for a new payment method right away, instead of waiting for the renewal to fail.

4. Keep dunning for the rest

Most failed payments are not about stale card details. Retries and clear dunning emails still do most of the recovery work. See how to recover failed payments on Stripe.

5. Prefer payment methods that last

Some payment methods are better suited to recurring billing than others. Prepaid and virtual cards, for example, carry their own renewal risks, which updaters and tokens do not address. See prepaid and virtual cards.

Measuring coverage

Track these monthly:

• Automatic updates received: count of payment_method.automatically_updated events, split by “expiry only” and “new number”.
• Expiring cards not updated: cards with an expiry before their next renewal and no update by a set date.
• expired_card failures: how many renewals still fail with an expired card. If this is high, your pre-expiry emails need work.
• Share by card country and brand: coverage varies, so a high failure rate in one country may point to issuer participation rather than your process.

Checklist

• payment_method.automatically_updated is logged.
• Pre-expiry emails are skipped for cards that were already updated.
• Cards expiring before the next renewal are flagged.
• Removed cards and closed accounts trigger an immediate request for a new payment method.
• Failures are reported by decline code, so you can see what updaters do not cover.
• Dunning handles everything else.

How NoChurn helps

NoChurn works alongside Stripe’s updaters and tokens and covers what they leave. It flags customers who remove their card before renewal, raising their churn score so you can reach them before the payment fails. When a renewal fails, it reads the decline code, retries soft declines at better times, and sends AI-written recovery emails, reviewed before sending, with a hosted card update page. Card data stays with Stripe; NoChurn only sees details like brand, last four digits, expiry and funding type.

It connects to Stripe in one click, and pricing depends only on MRR. See failed payments, the churn score and pricing.