Scheme Tokenization

What Is Scheme Tokenization?

Scheme tokenization is the process by which a card network (also called a card scheme) replaces a cardholder's PAN with a surrogate value called a network token. The token looks like a card number, passes format checks, and flows through the payment system in place of the real PAN. But it can only be used by the specific merchant or application that requested it, within a defined domain such as e-commerce or in-app payments.

Each major card network operates its own Token Service Provider (TSP). Visa runs the Visa Token Service (VTS), Mastercard runs the Mastercard Digital Enablement Service (MDES), and American Express runs its own American Express Token Service (AETS). These TSPs follow the EMVCo Payment Tokenization Specification, which standardizes how tokens are issued, restricted to domains, and used in transactions.

The term "scheme tokenization" distinguishes this network-level approach from other forms of payment tokenization where a gateway or acquirer generates and manages the token. Scheme tokens carry the authority and trust of the card network itself, which is what enables their portability and the automatic lifecycle management that other token types lack.

How It Works

The EMVCo specification defines four core stages in the scheme token lifecycle: issuance, provisioning, presentment, and processing. Each stage involves coordination between the merchant (or their payment service provider), the card network's TSP, and the issuing bank.

Token Provisioning

Before a merchant can request tokens, they register with each card network and receive a Token Requestor ID (TRID): a unique identifier that ties all token requests back to that specific merchant. A merchant working with Visa, Mastercard, and American Express needs three separate TRIDs. Payment service providers can also register as "On-Behalf-Of Token Requestors" (OBOTR), letting them manage tokens for multiple merchants.

When a cardholder saves their card for a card-on-file transaction, the merchant's system sends the PAN to the network TSP. The TSP checks with the issuing bank to verify the card is eligible, then generates a token and returns it along with a token reference. The merchant stores the token instead of the PAN.

Domain Restriction

A defining feature of scheme tokens is Token Domain Restriction Controls (TDRC). Unlike a PAN, which works everywhere, a scheme token is locked to a specific domain: a particular merchant, a particular channel (e-commerce vs. in-store), a particular device, or a combination. If a token provisioned for one merchant's e-commerce checkout is presented at a different merchant or through a different channel, the TSP will reject it.

This domain binding is what makes scheme tokens fundamentally more secure than PANs. A data breach at one merchant exposes tokens that are useless anywhere else. The token cannot be replayed at other merchants, used in different channels, or sold on dark markets for general fraud.

Cryptogram Generation

For each transaction, the TSP generates a unique, single-use cryptogram. This cryptogram combines the token, transaction-specific data (amount, currency, terminal context), and cryptographic keys shared between the TSP and issuer. Common cryptogram types include Visa's Token Authentication Verification Value (TAVV) and Mastercard's Digital Secure Remote Payment (DSRP) cryptogram.

The cryptogram serves as proof that the token is being used in a legitimate, authorized transaction. Even if an attacker intercepts the token and cryptogram from a network trace, the cryptogram is bound to that specific transaction and cannot be reused. This per-transaction binding provides a layer of dynamic security that static card data like the CVV cannot match.

Transaction Processing

When the merchant submits a tokenized payment, the transaction flows through the standard payment rails. At the network level, the TSP detokenizes the token back to the original PAN before forwarding the authorization request to the issuer. The issuer sees the real PAN, evaluates the authorization, and responds. The merchant never handles or sees the actual PAN during this process.

Token Lifecycle Flow:

Cardholder saves card
  → Merchant sends PAN to TSP (via TRID)
  → TSP validates with issuer
  → TSP returns network token + token reference
  → Merchant stores token (not PAN)

Transaction time:
  → Merchant submits token + cryptogram
  → TSP validates domain + cryptogram
  → TSP detokenizes to PAN
  → Issuer authorizes against real PAN
  → Response flows back through network

Automatic Card Updates

One of the most commercially valuable features of scheme tokenization is automatic lifecycle management. When a cardholder's card is reissued (due to expiration, loss, or bank migration), the network TSP automatically updates the token mapping. The merchant's stored token now points to the new card number without any action from the merchant or cardholder.

This contrasts sharply with traditional card-on-file storage, where card reissuance breaks stored credentials and requires the cardholder to manually re-enter their new card details. Services like Visa's Account Updater partially address this for PANs, but scheme tokens handle it natively as part of the token lifecycle.

Scheme Tokens vs. Other Token Types

Payment tokenization exists at multiple layers, and the differences matter for security, portability, and PCI DSS compliance scope.

The portability difference is commercially significant. A merchant using gateway tokens that wants to switch payment processors may lose access to all stored card credentials, effectively locking them to that gateway. Scheme tokens travel with the merchant because the card network, not the gateway, manages the token mapping.

Use Cases

Card-on-File E-Commerce

The primary use case for scheme tokenization is securing card-not-present transactions where merchants store card credentials for repeat purchases, subscriptions, or one-click checkout. The token replaces the PAN in the merchant's database, reducing PCI DSS scope while maintaining the ability to charge the card for future transactions.

Mobile Wallets and Digital Payments

Apple Pay, Google Pay, and Samsung Pay all use scheme tokenization under the hood. When a cardholder adds their card to a mobile wallet, the wallet provider requests a device-specific token from the network TSP. This token is stored in the device's secure element and generates a unique cryptogram for each contactless payment or in-app purchase.

Recurring Billing and Subscriptions

Subscription businesses benefit significantly from scheme tokenization's auto-update capability. When a subscriber's card is reissued, the token automatically maps to the new card, preventing failed renewals and involuntary churn. This alone can recover meaningful revenue that would otherwise be lost to expired card credentials.

Secure Remote Commerce

Visa's Secure Remote Commerce (SRC) and Mastercard's Click to Pay both rely on scheme tokenization to enable streamlined online checkout without exposing PANs to merchants. The checkout experience combines tokenization with 3D Secure authentication for both security and liability shift.

Industry Mandates and Adoption

Card networks are actively pushing the industry toward universal scheme tokenization through mandates, incentives, and fee structures.

Mastercard has committed to tokenizing 100% of e-commerce transactions by 2030. Its European roadmap includes phased milestones: credential-on-file transactions must be tokenized by October 2026, with further requirements in April 2028 and full coverage by April 2030. In Europe, Mastercard has also signaled scheme fee surcharges for stored-card payments that are not network-tokenized.

Visa has taken an incentive-driven approach rather than hard mandates. It offers reduced interchange fees for tokenized transactions in several markets and has introduced a "behavioral fee" in Europe for merchants not using network tokens. As of recent Visa data, approximately 30% of transactions processed over VisaNet are tokenized, with the network targeting 70% toward the end of the decade.

For a deeper look at network economics, see the research article on card network economics and the comparison of network tokenization approaches.

Authorization Rate and Fraud Impact

Scheme tokenization measurably improves two metrics that directly affect merchant revenue: authorization rates and fraud rates.

Visa reports a 4.7 percentage point improvement in authorization rates for tokenized card-not-present transactions compared to PAN-based transactions, based on VisaNet data. Mastercard reports a 3 to 6 percentage point improvement for first-attempt CNP authorizations. Some processors report even higher gains, with one 2025 study showing a 10.3 percentage point uplift.

On fraud reduction, Visa data shows up to a 28% decrease in fraud on tokenized CNP transactions. Mastercard cites a 50% reduction compared to traditional card transactions. These improvements come from three reinforcing mechanisms: domain restriction prevents token misuse, per-transaction cryptograms prevent replay attacks, and issuers treat tokenized transactions as lower risk because of these security properties.

Why It Matters for Digital Payments

Scheme tokenization represents a structural shift in how card payments work. For merchants, the practical benefits are higher approval rates, lower fraud losses, reduced PCI compliance scope, and fewer failed recurring payments. For cardholders, it means their card details are less exposed and their stored credentials survive card reissuance seamlessly.

As payments continue evolving beyond traditional card rails, the principles behind scheme tokenization (replacing sensitive credentials with domain-restricted, cryptographically secured surrogates) apply broadly. Blockchain-based payment systems like the payment token networks built on protocols such as Spark take a fundamentally different approach: instead of retrofitting security onto legacy card numbers, they use cryptographic keys and on-chain settlement that are secure by design. Understanding scheme tokenization helps clarify what traditional payment infrastructure is evolving toward and where native digital payment rails already start from a stronger security baseline.

Risks and Considerations

Implementation Complexity

Adopting scheme tokenization requires integration with each card network's TSP separately. A merchant supporting Visa and Mastercard needs separate TRIDs, separate onboarding processes, and separate API integrations. Many merchants delegate this to their payment gateway or processor, but this reintroduces some of the portability concerns that scheme tokens are meant to solve.

TSP as a Central Point of Trust

The card network's TSP becomes a critical dependency. All token provisioning, cryptogram validation, and detokenization flows through this centralized service. An outage at the TSP would prevent tokenized transactions from processing. This centralization is a tradeoff: scheme tokens gain their security and lifecycle features precisely because a trusted party manages the mapping.

Transition Period Friction

During the migration from PAN-based to token-based processing, merchants may run both systems in parallel. Edge cases arise when a cardholder's token is provisioned at one merchant but the same card is still stored as a raw PAN at another. Issuers must handle both tokenized and non-tokenized authorization requests, and card scheme mandates create compliance pressure with different timelines across regions.

Cost Considerations

Networks may charge fees for token provisioning, lifecycle management, and cryptogram generation. While these costs are often offset by improved authorization rates and reduced fraud losses, smaller merchants should evaluate the net economics carefully, especially before mandates make tokenization non-optional.

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.