---
title: "Network Token"
url: "https://mahouse.world/glossary/network-token"
type: "glossary term"
topic: "Payment security"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-10"
---

# Network Token

A network token is a substitute for a card number issued by the card scheme itself — Visa Token Service, Mastercard's MDES — bound to one merchant, wallet or device, so a stored credential is never the real number, is useless if stolen elsewhere, is updated automatically when the card is replaced, and is approved by issuers at higher rates. It is the technology behind Apple Pay and, since 2020, the standard for cards on file.

**Also known as:** Network tokenisation, Scheme token, Visa Token Service, Mastercard Digital Enablement Service

## Key facts

- **Used at:** wallets (every card in Apple Pay or Google Pay is a network token), card-on-file at merchants and PSPs, subscription billing, and any stored credential; the schemes have pushed adoption with pricing and mandates
- **Binding:** the schemes' tokenisation rules and the EMVCo payment-tokenisation framework; the merchant or PSP registers as a token requestor; the issuer approves the tokenisation
- **Typical benefits:** lifecycle management (a replaced card's token is updated by the scheme, no account updater needed), approval-rate uplift (issuers approve token transactions 2–4 points more often, reported by Visa and Mastercard), reduced PCI scope (the merchant never holds the number), and a domain restriction that makes a stolen token worthless elsewhere
- **Typical cost:** scheme fees per token and per transaction, partly offset by lower interchange in some regions and by the schemes' incentives; PSPs bundle it
- **Parties:** the schemes (token service providers), the token requestor (merchant, PSP, wallet), the issuer, and the cardholder, who sees the last four digits and nothing else

## How a network token works in practice

A customer saves a card at a merchant. Instead of storing the card number, the merchant's PSP, as a registered token requestor, asks the scheme to tokenise it: the scheme checks with the issuer, and returns a token — a number in the same format, bound to this merchant — with its own expiry and a cryptogram mechanism. The merchant stores the token. On each renewal it charges the token; the scheme maps it to the real card at the network and the issuer approves, seeing a token transaction it trusts. When the customer's card is replaced, the scheme updates the token's mapping and the merchant's next charge simply works. If the merchant's database is breached, the tokens are bound to that merchant's domain and cannot be used anywhere else.

The economics moved the market. Issuers approve tokens more readily because the scheme vouches for the binding; the schemes charge for the service and, in some markets, reduce interchange on token transactions; PSPs adopted it across their stored-card portfolios because the approval uplift is revenue for their merchants and a sales point for them. Wallets were the first mass use — a card provisioned to a phone is a device-bound token with a cryptogram per transaction — and card-on-file followed.

For a subscription business or a marketplace, migrating stored cards to network tokens is one of the largest single approval-rate and churn projects available; for a buyer of one, the token migration status is a line in payments diligence.

## Example

A subscription service with 2 million stored cards on PSP-proprietary tokens migrates to network tokens over four months. Results: expired-card declines fall 85% (the scheme updates tokens automatically); first-attempt approval on renewals rises 2.8 points; PCI scope shrinks because the PSP's token vault, not the merchant's, is the only place the mapping exists. Cost: €0.02 per token and €0.005 per transaction — about €70,000 a year — against €1.9m of retained renewals. When the service later switches PSPs, the network tokens travel with it under the schemes' portability rules; the proprietary tokens it had before would have required re-collecting 2 million cards.

## Common mistakes

- Storing cards as a PSP's proprietary tokens and discovering at migration that they are not portable.
- Treating a token as a card number for fraud rules; the domain binding changes the risk.
- Ignoring the cryptogram requirement on token transactions in the integration.
- Assuming tokens remove all PCI scope; the checkout that captures the card still matters.
- Buyers of a subscription business not asking what share of stored cards are network tokens.

## Related terms

- [Tokenization](https://mahouse.world/glossary/tokenization.md)
- [Digital Wallet](https://mahouse.world/glossary/digital-wallet.md)
- [Decline Recovery](https://mahouse.world/glossary/decline-recovery.md)
- [Approval Rate](https://mahouse.world/glossary/approval-rate.md)
- [Primary Account Number](https://mahouse.world/glossary/primary-account-number.md)
- [PCI DSS](https://mahouse.world/glossary/pci-dss.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov