Payment Token Lifecycle

What Is the Payment Token Lifecycle?

The payment token lifecycle is the sequence of states a tokenized payment credential passes through from the moment it is created until it is permanently deleted. Every token that replaces a primary account number (PAN) in a digital wallet, merchant vault, or card-on-file system follows this lifecycle. The stages determine when a token can authorize transactions, when it must be blocked, and when it should be removed entirely.

Understanding these stages matters because tokens are not static identifiers. They are dynamic credentials whose validity depends on issuer policies, cardholder actions, and fraud signals. A lost phone, a reissued card, or a suspicious transaction can change a token's state in seconds. The lifecycle framework ensures that every participant in the payment network responds consistently to these events.

The EMVCo Payment Tokenisation Technical Framework standardizes the roles and responsibilities of entities involved in lifecycle management, including token service providers (TSPs), token requestors (merchants or wallets), and issuers. Visa's Token Service (VTS) and Mastercard's Digital Enablement Service (MDES) are the primary TSPs for their respective networks.

How It Works

The lifecycle begins when a cardholder enrolls a card in a digital wallet or a merchant stores it for future use. From that point, the token passes through a defined set of states.

Stage 1: Token Request and Creation

A token requestor (such as Apple Pay, Google Pay, or a merchant checkout system) sends a provisioning request to the TSP. The request includes the PAN, expiration date, and context about the intended use: device payment, e-commerce, or card-on-file storage.

The TSP forwards the request to the card issuer for approval. The issuer evaluates risk signals: is the cardholder authenticated? Does the device match known patterns? Is the card in good standing? Based on this assessment, the issuer approves, declines, or requires additional verification such as a one-time passcode.

Stage 2: Provisioning

Once approved, the TSP generates a unique token value mapped to the underlying PAN in a secure token vault. The token is assigned a domain restriction (limiting it to a specific device, merchant, or channel) and a token assurance level indicating how strongly the cardholder's identity was verified during enrollment.

During provisioning, the token exists in a pending or inactive state. It cannot yet authorize transactions. Visa uses the status code "P" (pending) for this phase; Mastercard's MDES treats the token as not yet active until the issuer confirms final activation.

Stage 3: Active Use

After provisioning completes, the token moves to an active state (Visa status code "A"). It can now authorize payments within its assigned domain. When a transaction occurs, the token is sent to the network, which de-tokenizes it back to the real PAN before forwarding to the issuer for authorization.

During active use, the TSP handles ongoing lifecycle events transparently. If the underlying card is reissued with a new expiration date or replacement PAN, the TSP updates the token-to-PAN mapping in its vault. The token value itself does not change, so merchants and wallets continue processing without interruption.

Stage 4: Suspension

A token can be suspended by the issuer, the cardholder, or the TSP. Common triggers include:

• The cardholder reports a device lost or stolen through their banking app
• The issuer detects suspicious activity on the underlying card
• The cardholder removes the card from a digital wallet temporarily
• The issuer places the card account on hold for compliance reasons

Suspended tokens (Visa status code "S") cannot authorize transactions, but they remain in the token vault. The suspension is reversible: the entity that initiated the suspension can restore the token to active status without creating a new one. A key rule is that only the same authority that suspended the token can resume it.

Stage 5: Resumption

If the trigger is resolved (the device is found, the fraud alert is cleared, the account hold is lifted), the suspending authority can reactivate the token. This returns it to active status with the same token value and domain restrictions. No re-provisioning or cardholder re-enrollment is needed.

Stage 6: Deletion

Deletion permanently deactivates a token (Visa status code "D"). Unlike suspension, deletion is irreversible. Deleted tokens cannot be reactivated or used for any future transactions. Triggers include:

• The cardholder permanently removes a card from a wallet
• The card account is closed by the issuer
• The merchant deletes the stored credential from their system
• The token is replaced by a new one during re-digitization

Once deleted, the TSP removes the token-to-PAN mapping, and any subsequent transaction attempts using that token value are declined.

Token Status Codes

Visa defines five standard status codes that map to these lifecycle stages:

Network Tokens vs. Gateway Tokens

A critical distinction in lifecycle management is between network tokens and gateway tokens. They handle card updates very differently.

Network tokens are issued by the card networks themselves (Visa, Mastercard) and stored in their token vaults. When a card is reissued, the network pushes an update to the token mapping in real time. The merchant never needs to collect new card details. This push-based lifecycle management is one of the primary advantages network tokens have over older approaches.

Gateway tokens are issued by a specific payment gateway or processor. They are tied to that provider and not portable across gateways. When a card is reissued, gateway tokens rely on the account updater service to refresh credentials. Account updater operates in monthly batches, meaning there can be a gap of days or weeks between a card reissue and the token update. Transactions during that gap may be declined.

For businesses that use recurring billing or subscription models, this distinction directly affects revenue. Network tokens reduce involuntary churn caused by expired or reissued cards, while gateway tokens require supplementary account updater services to achieve a similar (though less timely) result. For a deeper comparison, see the research article on payment network tokenization.

How Automatic Updates Work

When a card issuer replaces a cardholder's PAN (due to expiration, fraud, or a product upgrade), the issuer notifies the TSP. The TSP updates its vault to map the existing token to the new PAN. This process is transparent to the token requestor:

// Simplified lifecycle event flow
Token: 4000-0012-3456-7890
  ↓
Original PAN: 4111-XXXX-XXXX-1234 (expires 03/26)
  ↓ Card reissued
New PAN: 4111-XXXX-XXXX-5678 (expires 03/29)
  ↓
TSP vault updated: token now maps to new PAN
  ↓
Merchant charges same token → authorized against new PAN

The merchant sees no change. The token value, the token expiry, and the merchant's integration remain identical. Only the TSP's internal mapping changes.

The Role of Token Service Providers

Token service providers are the entities responsible for generating, storing, and managing tokens throughout their lifecycle. The two largest TSPs are the card networks themselves:

• Visa Token Service (VTS): manages tokens for Visa cards, handles provisioning approvals, de-tokenization during authorization, and lifecycle events like suspension and card updates
• Mastercard Digital Enablement Service (MDES): the equivalent for Mastercard, providing token generation, lifecycle management, and integration with digital wallets and merchants

Third-party TSPs also exist. Companies can become certified TSPs through EMVCo's registration program, allowing them to issue and manage tokens on behalf of the networks. These third-party TSPs must meet strict security and operational requirements, including PCI DSS compliance and network-specific certification.

The TSP acts as the central authority for lifecycle decisions. When a cardholder removes a card from Apple Pay, the wallet sends a de-provisioning request to the TSP, which deletes the token. When an issuer suspends an account, the TSP suspends all associated tokens across every wallet and merchant where they are stored.

Use Cases

Digital Wallet Enrollment

When a cardholder adds a card to Apple Pay, Google Pay, or Samsung Pay, the wallet triggers the full provisioning flow. The TSP creates a device-specific token bound to that phone's secure element. If the phone is lost, the cardholder suspends the token through their bank without affecting the physical card or tokens on other devices.

Recurring and Subscription Payments

Merchants storing credentials on file for subscriptions benefit from network token lifecycle management. When a card expires, the token automatically maps to the replacement card. Subscription charges continue without the cardholder needing to update their payment method. This reduces involuntary churn significantly.

E-Commerce Checkout

Online merchants use scheme tokenization to store tokens instead of raw PANs. The lifecycle ensures these tokens are deactivated if the underlying card is reported compromised, reducing the merchant's exposure to fraud without requiring them to monitor card status changes directly.

Multi-Device Management

A single card may have tokens provisioned across multiple devices and merchants. Lifecycle management ensures each token can be controlled independently. Suspending a token on a lost tablet does not affect the token on the cardholder's phone or their stored credentials at an online retailer.

Risks and Considerations

Fragmented Token State

A single card can generate dozens of tokens across wallets, merchants, and payment apps. If the issuer suspends the card, all associated tokens should be suspended. In practice, propagation delays between the issuer and various TSPs can create windows where some tokens are still active while others are suspended.

Irrecoverable Deletion

Token deletion is permanent. If a token is deleted by mistake (for example, a cardholder accidentally removes a card from a wallet), the cardholder must re-enroll and go through the full provisioning process again. For card-not-present merchants, this means the customer must re-enter their card details.

Issuer Dependency

The issuer controls token approval during provisioning. Some issuers have restrictive policies or slow approval flows, which can cause friction during enrollment. If the issuer's systems are down, new tokens cannot be provisioned, and lifecycle events (suspension, resumption) may be delayed.

Gateway Token Limitations

Merchants using gateway tokens instead of network tokens face portability issues. Gateway tokens cannot be migrated to a new processor, meaning a processor switch requires re-collecting card details from all stored customers. Network tokens, managed by the card networks, are portable across processors by design.

Blockchain and Stablecoin Comparison

In contrast to card-based tokenization, blockchain-based payment systems like stablecoin rails do not require a centralized TSP to manage credential lifecycles. The payer controls their own keys and can authorize transactions directly. Platforms like Spark enable self-custodial payments where the user manages their own credentials without relying on issuer approval or network-mediated lifecycle events.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.