Network tokenization replaces the card number a merchant would store with a token issued through the card network. When a subscriber’s card expires or is replaced after a loss, the merchant can often keep charging the same saved token, because the network links it to the new card behind the scenes.
That explains a common surprise: a streaming service or ride app keeps working after a new card arrives in the post, even though nobody typed in the new number. It also explains why some merchants still lose recurring payments. Network tokens depend on issuer participation and on the merchant or its payment provider actually requesting them.
A token instead of the card number
A card number, called the primary account number or PAN, works anywhere the card is accepted. If a database of stored PANs leaks, the numbers can be tried elsewhere. EMVCo, the body that manages the EMV payment specifications, describes EMV Payment Tokenisation as removing the PAN from a transaction and replacing it with a unique alternative value.
The important property is restriction. EMVCo says a payment token is constrained in how it can be used, for example to a specific merchant, device or payment scenario. A token copied from one merchant’s records should not be usable beyond that domain.
Visa’s Network Tokenization Overview for its acceptance platform makes the same point in practical terms: a network token uses the same format as a PAN, is domain-restricted and is tied to the merchant’s token requestor ID.
Network token or gateway token?
Many merchants already store a “token” from their payment provider. That is usually a different thing.
A gateway or processor token is a reference inside one provider’s vault. The provider swaps it back to the card number when it sends the payment onward. EMVCo notes that other forms of tokenization happen at different points, for example between merchant and acquirer.
A network token travels further. According to EMVCo, it is used from the point of purchase through the acquirer and across the payment network to the issuer for authorization. Visa’s overview says that, unlike standard tokens converted back to the PAN during authorization, network tokens remove the PAN from the payment flow.
The two can sit together. Mastercard’s gateway documentation describes a setup where the merchant keeps using its gateway token while the gateway requests a network token in the background and uses it when one is available.
Why the saved card survives a reissue
The behavior in the headline comes from lifecycle management. The Visa Token Service fact sheet says tokenization lets financial institutions automatically update expired or compromised credentials, without the customer making manual updates, when a Visa card is lost, stolen or expired.
Mastercard’s gateway guide states it from the merchant’s side: if the issuer updates the card, for example because it expired or was lost or stolen, the network token requires no update. The stored card number behind the gateway token is flagged as invalid instead, so a payment that falls back to the old number is rejected.
Take a monthly subscription. The customer saved a card in January and the merchant’s provider requested a network token. In June the bank replaces the card after a fraud alert. With a working token, the July charge goes out on the same token and the network maps it to the new card. Without one, the merchant holds a dead card number and has to ask the customer for new details.
A cryptogram on each payment
A network token is not sent alone. Visa’s acceptance overview says each network token is paired with a dynamic cryptogram, and Visa’s guide to tokenized transactions says tokens provide a unique cryptogram for every transaction. In Mastercard’s gateway fields, the merchant submits the cryptogram together with the token and its own expiry date.
The cryptogram gives the issuer evidence that the payment came from the party allowed to use the token. A copied token without a valid cryptogram is worth much less to an attacker than a copied card number.
What network tokens do not do
They do not cover every card. Mastercard’s gateway guide says tokenization of stored card numbers is subject to issuer participation and to enabled card account ranges.
They do not remove card-data responsibilities on their own. Visa’s acceptance overview lists reduced PCI scope when a merchant stores tokens instead of raw card data, but the merchant’s assessment still depends on how card data reaches its systems. Our explainer on PCI SAQ types covers that checkout question.
They do not replace authentication. A token-based payment can still need cardholder authentication where rules require it, which is a separate step covered in our 3D Secure explainer. And they do not change what a payment costs; for published processor pricing, see the payment fee calculator.
Network rules also vary by market. For example, Mastercard’s gateway guide notes that US merchants on that gateway cannot process Visa Token Service tokens for debit or prepaid transactions routed to domestic debit networks, which ties into how US debit card routing works.
What a merchant can check
Ask the payment provider whether it requests network tokens for stored cards, for which card networks, and whether existing saved cards are tokenized as well as new ones. Check what happens when no token is available: the provider may fall back to the stored card number. Then compare recurring-payment declines for tokenized and non-tokenized cards in your own data rather than relying on a vendor’s average.
