Tokenization
Last updated:August 03, 2026
Tokenization exists to finish a purchase you have not started yet. A shopper's card is only present at the moment they type it in. Every purchase after that has to be initiated from something the card was replaced with. That something is a token.
This guide focuses on card data, since that is most of what merchants tokenize. The same idea reaches further than a card. A PayPal billing agreement, a SEPA direct debit mandate, or a wallet issued DPAN from Google Pay or Apple Pay can all sit behind a token instead of the raw data itself, and the registration tokens section below shows how.
Consider a returning shopper, call her Anna, who saves her card once with a multi category retailer. Her next purchase and her monthly subscription renewal both need to reinitiate a payment using whatever sits behind that saved card, without her typing it in again, and without the merchant ever holding the real number.
Why tokenize
Tokenization solves two problems at once. Most merchants notice one before the other.
The first is exposure. A primary account number sitting in a merchant's own systems is a liability even when nothing goes wrong with it: every system that touches it, every backup that stores it, sits inside PCI DSS scope. The second is harder to see. A returning shopper or a recurring subscription needs a way to reinitiate a payment later, without the card being present and without asking the shopper to type it in again. Tokenization does both jobs in one move: replace the sensitive data with a token, then use that token to protect the original value and to trigger future charges against it.
Every token type in this guide is doing one of these two jobs, or both. The rest of this guide is about which token does which job, and who ends up managing the complexity behind it.
Card on file: what it enables, and what it requires
The card Anna saved is not charged again by magic. Every renewal after the first purchase is a card on file transaction, and it only clears if it is flagged correctly.
The moment a merchant stores any token to charge it again later, every one of those future charges is a card on file transaction. The card networks require it to be identified correctly. A charge the shopper is actively present for and approves in the moment is cardholder initiated (CIT), the original purchase where the card was saved, or a one-click repeat purchase. A charge the merchant sends on its own, based on an earlier agreement and without the shopper present, is merchant initiated (MIT), a scheduled subscription renewal or an installment. Networks also distinguish the first use of a stored card from every use after it.
On this platform, that distinction is carried in the standingInstruction parameters attached to a
payment request. standingInstruction.source identifies CIT or MIT. standingInstruction.mode
identifies whether this is the initial use or a repeated one. standingInstruction.type identifies
whether the agreement is unscheduled, recurring, or an installment plan. A repeated charge also carries an
initialTransactionId, linking it back to the original CIT that created the stored credential.
Getting this right is not paperwork. An issuer that sees a correctly flagged card on file transaction can
trust it as authorized. An unflagged or mislabeled one looks like a merchant charging a card without the
cardholder present, exactly the pattern issuers are trained to decline or flag as fraud.
The complete set of standingInstruction use cases, initial and subsequent, one time and recurring, live and worked through end to end in the Card on File guide. This section covers why it matters for tokenization specifically, not the full parameter reference.
The Token Vault
Every merchant token on this platform, Registration or Omni, is issued by the same place: the Token Vault. The Vault is not just storage. It is also the door to the card networks. When network tokenization is enabled, the Vault is what requests a network token from Visa, Mastercard, or another scheme, on behalf of whichever merchant token a shopper's card already has. A merchant never has to manage that scheme relationship directly. The Vault does, and the merchant keeps referencing the same Registration or Omni token it always has.
That last step is optional, and it sits behind the merchant token, not beside it. A merchant does not choose "a network token" the way it chooses between Registration and Omni. It chooses a merchant token first, based on where it needs that token to work, then decides whether to let the Vault request a network token behind it. The next section walks through that decision in order.
Choosing your path
Most merchants answer three questions, in this order, to land on the right combination.
The first question decides which merchant token to request from the Vault. Registration fits an ecommerce only business. Omni fits a business that sells across ecommerce and in-store and wants one customer, not two, on both sides. The second question is whether to let the Vault manage the scheme relationship for you, by enabling network tokens behind that same merchant token. The third only applies if a merchant already has its own acquirer relationship it wants to use directly, or already runs its own Token Service Provider integration with the networks. External tokens and a bring your own network token both let that merchant trade the Vault's convenience for direct control of one specific relationship.
Registration tokens
Anna's saved card at checkout is a UUID, not her real card number. That is what lets her skip re-entering it every time she buys online.
Registration tokens are the Vault's answer for an ecommerce only business. They let a shopper check out again without typing their card back in, with the least setup on the merchant's side. Choose a registration token when your business sells only through ecommerce and speed of setup matters more than a unified in-store identity.
A registration token is a UUID, for example 123e4567-e89b-12d3-a456-426614174000, a universally
unique identifier in a random alphanumeric format unrelated to the shape of the original card number. That
format needs no separate vault onboarding. A card is registered once, and the token is ready to use
immediately. Removing the card number from the merchant's own environment is what simplifies PCI compliance
for a small online boutique that never has to store a card of its own. It also protects a subscription
streaming service: a stolen registration token is useless anywhere else, unlike a real card number.
Registration tokens are not limited to a card's PAN either. The same UUID mechanism can stand behind a wallet issued DPAN, the device account number Google Pay or Apple Pay hands the merchant instead of a real card number, or behind non-card payment data entirely: a PayPal billing agreement, or a SEPA IBAN based direct debit mandate. Whatever sits behind it, the same registration token is what the merchant references going forward. If a shopper asks to remove a saved payment method, that registration token is deregistered outright and stops working the moment that happens. A registration token can also carry a network token behind it, the same way an omni token can. See Network tokens for how that layer works.
Benefits
Anna adds her card once, on her first purchase, and it becomes a UUID stored on the merchant's side. Every purchase after that is one tap, sent as a cardholder initiated card on file transaction. If she later asks to remove the card from her account, that registration token is deregistered and stops working immediately.
Integration guide: COPYandPAY · Server-to-server
Network tokens
Anna's card was reissued last spring. The network token behind her registration token updated automatically, so her subscription renewal never missed a beat.
A network token is not a third merchant token sitting next to Registration and Omni. It is what the Token Vault can request from the card network, Visa, Mastercard, or another scheme, behind whichever merchant token a shopper's card already has. Enable it when you want fewer failed renewals and higher approval rates without changing your integration. The merchant keeps referencing its own Registration or Omni token exactly as before. Network tokenization happens behind that reference, not instead of it.
A lost, stolen, or expired card would normally make a stored credential unusable. That is exactly the moment a subscription is most likely to lapse. Because the issuing bank updates the token proactively, a merchant token with a network token behind it keeps working through a card refresh, reissue, or replacement, with no customer contact required. Network tokenization also brings the issuer into the approval process, which tends to reduce false declines caused by stale card data. A network token carries a dynamic cryptogram rather than a static number, so a captured token is worth far less to a fraudster than a stolen card number. Network tokens can also stand in for the PAN during 3D Secure, letting an issuer authenticate a returning shopper silently and skip a step up challenge, which matters most in markets where Strong Customer Authentication would otherwise add friction to every charge.
Not every acquirer supports network tokens today. Confirm with your acquirer or your Customer Success Manager before enabling this layer for a given payment method or region.
Benefits
When Anna's card was reissued after her bank flagged suspicious activity elsewhere, the merchant never saw an interruption. The network token behind her registration token updated in the background, and her next renewal, sent as a merchant initiated card on file transaction, went through on the new card details without her doing anything.
Integration guide: COPYandPAY · Server-to-server
Bring your own control
The Token Vault trades some control for convenience: one merchant token, managed relationships behind it, less for the merchant to run. Some merchants want the opposite trade. They already have a specific processing relationship and just want to use it directly, without the Vault sitting in between.
Your own Token Service Provider
If the merchant already runs its own network token relationship, Anna's card never needs a Vault provisioning step at all, it arrives already tokenized.
Some merchants already have their own Token Service Provider (TSP) relationship directly with the card networks: their own enrollment with Visa Token Service or Mastercard's equivalent. Choose this path when that relationship already exists and you want to submit payments using network token authorization data you already hold, rather than have the Token Vault provision it again.
That is fully supported. The merchant sends the network token and its dynamic cryptographic data using the
tokenAccount.* request parameters, for both
the cardholder initiated payment that establishes the card on file relationship and every merchant initiated
charge after it. The platform processes what is handed over. No provisioning step runs on this side, and the
acquirer authorizes with the network token if it supports one.
Benefits
A merchant with its own TSP integration sends Anna's network token and cryptogram directly on her first purchase, then reuses that same network token, flagged as a merchant initiated transaction, for her monthly renewal, with no token ever provisioned on the platform side.
Integration guide: Server-to-server
Apple Pay tokens
Anna checks out with Face ID on her phone. The MPAN behind that tap is controlled by Apple and the issuer, not by the Token Vault.
Apple Pay tokens, merchant primary account numbers or MPANs, are a third kind of "outside the Vault" path, alongside external tokens and a merchant's own TSP. The wallet and the issuer control the token's lifecycle. The platform receives and stores what the wallet provides, in the same encrypted JSON format Apple Pay always returns. An MPAN links a shopper's card to their Apple Wallet rather than to one physical device, which is what lets the same token keep working across a device upgrade or a lost phone.
An MPAN is device independent and built for continuity. It supports recurring and subscription charges without being tied to whichever iPhone or Watch the shopper happens to be using, and if the device is lost or replaced the underlying payment relationship survives, because the token belongs to the wallet, not the hardware. Each transaction carries a one time dynamic security code, so a captured token cannot be reused outside its original context.
Every request for a fresh MPAN falls into one of three types: automatic reload for topping up a stored balance, recurring payment for a subscription such as a monthly streaming service, or deferred payment for something booked now and charged later, such as a hotel room. If the card issuer does not yet support MPAN generation, Apple Pay falls back to issuing a device payment account number instead, tied to that one device rather than the wallet.
Benefits
Anna checks out with Face ID on her iPhone, and the merchant receives an MPAN, never her actual card number. If she later switches to a new phone, the same Apple Pay relationship carries over without her re-adding the card.
Integration guide: Integration guide
Tokenization value map
However a merchant gets there, Vault issued, network token enriched, externally issued, brought in through its own TSP, or handed over by a wallet, tokenization is always resolving the same problem: complete the purchase, or the recurring charge, without moving the real card number, flagged correctly as card on file so the issuer trusts it. The difference between the paths is who manages the complexity behind that result: the Token Vault for Registration, Omni, and the network tokens layered behind them, or the merchant and its own acquirer, TSP, or wallet relationship for everything in Bring your own control.
Tokenization is not the destination. It is what makes the next purchase possible without asking the shopper to start over.
Anna never sees a token or a standingInstruction parameter. She sees a checkout that remembers her card, works the same way in the app and in store, and keeps working after her card is reissued. That experience is what the right tokenization choice, and correctly flagged card on file transactions behind it, buys the merchant.