0
This blog is about the next layer of tokenization, one that most payment teams have heard about but few have fully mapped 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 this 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.
It works. But it 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 doesn't 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 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.
Coming to these two types of tokens.
Merchant Tokens are generated and are 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 is stolen or leaked, 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.
Device Tokens are bound to a specific device rather than a specific merchant.
They are the foundation 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 contactless 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, as 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 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 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 PAN never did.
It is what makes Tokenization 2.0 extensible.
The same architecture that produces a device token for Apple Pay can produce an agent 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.
