0
Most payment teams have heard about the next layer of tokenization, but few have fully mapped it out in their own environments.
In basic tokenization, the PAN gets replaced with a token. The merchant never stores the real card number. Fraud exposure drops. The industry has largely accepted the model and moved on. But the model has been quietly evolving.
The original tokenization model solved a specific problem: stopping merchants from storing real card numbers.
A token service provider generates a token, links it to the PAN in a secure vault, and future transactions use the token instead of the actual card number.
Network token payments work on exactly that principle. The network issues a token, the merchant uses the token, and the actual card number never leaves the vault.
But the original model was designed around a single relationship - one card, one token, one vault. As digital commerce scaled, that model began to show its limits.
A token generated for Google Pay does not behave the same way as one generated for a card-on-file merchant. A subscription platform will have different lifecycle requirements than a mobile wallet. One token type, applied uniformly across all of these, creates friction that the original model was never designed to handle.
The limitations became more visible as the number of payment contexts expanded. A token that worked correctly in a mobile wallet checkout does not include the correct restrictions for a subscription payment.
A token scoped to a specific merchant cannot be reused across a platform with multiple merchant entities. As payment teams tried to apply a single-token model to an increasingly varied set of use cases, the model's gaps became harder to work around.
The industry's response has been to move from a single token type to purpose-driven token types, each scoped to the specific environment in which it operates.
The distinction between the merchant token and the device token sits at the center of that shift.
Merchant Tokens are generated and bound to a specific merchant. Unlike a network token that can theoretically be used across multiple merchants, a Merchant Token only works at the merchant for which it was created. If it gets stolen, it cannot be used elsewhere.
For card-on-file merchants and subscription platforms, this is a big security improvement. The token's usability is constrained to a single commercial relationship, which limits the damage if that token is ever compromised.
Device Tokens are bound to a specific device only. They are the core of how Apple Pay and Google Pay work.
When a cardholder adds a card to a mobile wallet, the token generated is cryptographically tied to that device. Even if the token is intercepted, whether contactlessly or through transaction data, it is useless without the device-specific keys that authorize the transaction.
It is why a mobile wallet payment carries a lower risk of fraud than a card-on-file payment - the token alone is not enough.
A Merchant Token and a Device Token have different liability profiles, lifecycle rules, and revocation requirements.
When a customer loses their phone, the device token linked to that device must be revoked - not the PAN, not every token the customer has ever generated, just the one bound to that device.
When a merchant is compromised, only the Merchant Tokens issued to that merchant are at risk. The network token and the PAN remain untouched.
Getting these boundaries wrong - treating all tokens as interchangeable - creates gaps in fraud response that only become visible during an incident. The token service provider's payments infrastructure is built to handle these distinctions, but only if the teams operating within it understand which token type they are working with and its revocation and lifecycle rules. A team that revokes the wrong token when a device is reported lost, or fails to revoke Merchant Tokens when a card-on-file merchant is compromised, is not using the Tokenization 2.0 architecture to its potential.
Token lifecycle management is where most of the operational complexity in Tokenization 2.0 lives. Provisioning a token is a one-time event. Managing it - updating it when a card is reissued, revoking it when a device is lost, and linking it correctly to the PAR so that the issuer can track the underlying card across multiple token instances - is an ongoing operational responsibility that requires the right tooling and an understanding of token-type boundaries.
The shift from a single token type to purpose-built tokens is not just a security improvement. It is a fundamental change in how the payments industry thinks about identity at the transaction level.
In the original tokenization model, a token was a substitute for a card number.
In Tokenization 2.0, a token is a statement of context - who is transacting, on which device, through which merchant, under which conditions. The token carries meaning to every transaction that the PAN never did.
Payment tokenization AI extends that logic further. If a token already encodes context - device, merchant, mandate - then an AI system operating within a payment flow can use that context to make better authorization decisions. It will also help detect anomalies more precisely and manage token lifecycle events more intelligently. The token is not just a security mechanism. It is a data structure that an AI layer can read and act on.
It is what makes Tokenization 2.0 extensible.
The same architecture that produces a device token for Apple Pay can produce an agentic payment token for an AI agent acting on a cardholder's behalf - scoped to a specific mandate, bound to a specific agent instance, and revocable without touching the underlying card.
It is exactly the direction AP2 and emerging agentic commerce protocols are pointing toward. The industry spent twenty years removing the PAN from commerce. The next phase is to make the token itself intelligent, scoped, bounded, and purpose-built for the environment in which it operates.
That infrastructure is being built now. The teams that understand the token type boundaries today will be the ones who can extend them tomorrow.
