Network Token Lifecycle Management: How Card Updates Happen Without Merchant Intervention

A stored card credential has a lifespan. Cards expire. Cards are reissued after fraud. Banks merge and migrate accounts. Cardholders report cards lost or stolen. Every one of these events generates a new PAN, a different 16-digit number, that invalidates the credential stored in the merchant's vault.

Without intervention, the next charge attempt against that credential fails. In a subscription business, that failure initiates a dunning sequence. Some customers re-enter their details. Some do not. The ones who do not become involuntary churn: customers who intended to stay but left because a payment system failed them.

Network token lifecycle management eliminates most of this category of failure. The mechanism is automatic and operates without the merchant or cardholder taking any action.

To learn more about how network tokens work end to end, see our guide to network tokenization.

How does lifecycle management work?

When a network token is provisioned, the card network creates a binding between the DPAN (the device-specific token) and the underlying card account. The card network monitors that account for changes: expiry date updates, card reissuance (new PAN), account closure, suspension, or restoration. When any of these events occurs, the card network pushes the update to the token layer, and the token's record is refreshed to reflect it.

A vault or token service provider typically exposes this in two ways:

1. On-demand status checks. The merchant, or the merchant's payment infrastructure, can query a token status endpoint at any time to retrieve the current state of a stored credential: the token's expiry date, its status, and the last four digits of the underlying PAN. If the underlying card number has changed, this check surfaces the update without the merchant needing to store or see the raw PAN.

This response also typically includes a payment account reference (PAR), a unique identifier issued directly by the card networks that stays constant across a given cardholder-merchant relationship even as the underlying token or PAN changes. This lets a merchant recognize "this is still the same card account" across channels and over time, independent of which specific token or card number is currently active.

2. Push notifications (webhooks). Rather than polling, a merchant can configure a webhook endpoint to be notified automatically whenever something changes on the token or its underlying PAN, changes to the masked card number, expiry date, or status arrive as an HTTP call to that endpoint as soon as the card network processes them. To confirm a notification hasn't been tampered with in transit, these webhooks are typically signed, with the receiving system verifying the signature using a shared key before trusting the payload. Delivery is usually retried automatically (with exponential backoff) until it succeeds.

Either way, the mechanism is the same at its core: the DPAN itself generally remains valid and stable, the network updates the metadata behind it, and the merchant's internal reference to that credential never changes. The next charge submits successfully against the refreshed credential.

The cardholder never needs to re-enter their payment details. The merchant never needs to run a manual account updater job.

Token status states

A network token typically carries one of several defined states, which is what a status check or webhook notification reports back:

This gives merchants a clear, structured signal to act on, rather than an opaque decline code. A SUSPENDED token, for instance, can be surfaced differently in a dunning flow than a DELETED one, since the latter means the credential needs to be replaced entirely rather than simply retried later.

The main lifecycle event types

Card expiry

The most common lifecycle event. Cards carry a two-to-three-year expiry date. When a card approaches expiry, the issuer typically reissues it with a new expiry date (and sometimes a new PAN). The card network pushes an update to all associated network tokens. The token's expiry metadata is updated. No charge fails because of an expired credential.

Card reissuance after fraud

When a card is compromised — the PAN is exposed in a data breach or used fraudulently — the issuer reissues a new card with a new PAN. The network token for that cardholder-merchant pair is updated to reflect the new underlying PAN. The DPAN itself may or may not change; in most implementations the DPAN remains stable and its mapping to the new PAN is updated internally. The merchant's stored credential continues to work.

Account suspension and restoration

If a card account is suspended — due to non-payment, fraud investigation, or account hold — the associated network token status updates to SUSPENDED. Charge attempts against a suspended token return the appropriate decline code without the merchant needing to know the specific reason. When the account is restored, the token status returns to ACTIVE. The merchant can retry without any re-provisioning.

Account closure

When a card account is permanently closed, the network token status updates to DELETED. The merchant's system can detect this status and take the appropriate action, removing the card from saved payment methods, triggering a card update request to the cardholder, without waiting for a hard decline.

Network tokens versus Account Updater

Account Updater services (Visa Account Updater, Mastercard Automatic Billing Updater) are the predecessor technology for keeping stored credentials current. They work by submitting batches of stored PANs to the card network on a regular schedule, typically monthly, and receiving back any updates: new PANs, new expiry dates, account closures.

Account Updater is reactive and batch-based. Updates arrive days or weeks after the card change occurs. In the gap between a card reissuance and the next Account Updater batch, charge attempts against the stale PAN fail.

Network token lifecycle management is real-time and push-based. Updates arrive at the token service provider as soon as the card network processes the change, typically within hours of the issuer updating the account. There is no batch cycle. There is no gap.

Account Updater also requires the merchant to store or transmit raw PANs for the batch submission, which creates PCI scope implications. Network token lifecycle management operates entirely on the token layer; no raw PANs are involved at any point.

For merchants currently using Account Updater, network tokenization does not replace it immediately: issuer participation in token lifecycle management varies, and Account Updater provides broader coverage in markets where token lifecycle is not yet fully supported. The practical approach is to run both in parallel: use network token lifecycle management as the primary mechanism and Account Updater as a fallback for cards where token lifecycle events are not available.

To learn about the additional benefits of network tokenization, have a loot at

Issuer participation coverage

Token lifecycle management depends on issuer participation. The issuer must be connected to the card network's token service, Visa Token Service (VTS) or Mastercard Digital Enablement Service (MDES), and must push lifecycle events through that service.

Coverage is strong in the US, Europe, and major Asia-Pacific markets where tokenization adoption is high. It is growing in MENA and Latin America, where adoption has accelerated significantly in 2024–2025. In markets with lower issuer participation, lifecycle events may not be available for all cards, and the Account Updater fallback becomes more important.

A vault provider that maintains integrations with both VTS and MDES can handle this issuer coverage complexity transparently, processing events for cards where lifecycle management is available and surfacing Account Updater as the fallback path where it isn't.

The business case for token lifecycle management is direct: every failed payment caused by a stale credential is preventable. For a subscription business with $1 million in monthly recurring revenue and a 2% failed renewal rate, that is $20,000 per month in at-risk revenue, $240,000 per year, before accounting for the downstream churn those failures drive. Network token lifecycle management eliminates the structural cause of the failure, not just the symptom.

For more on how network tokens improve approval rates beyond lifecycle management, see How Network Tokenization Helps Improve Payment Authorization Rates.