Network Tokenization: Why the Number a Merchant Stores Isn't Your Card Number

Network tokenization replaces a card's PAN — the Primary Account Number printed on the card — with a substitute number that only the issuer and the card network can map back to the real account. The token is what flows through authorisation, and it is what the merchant stores. The substitution is deliberately narrow in scope. A token can be restricted to a particular merchant, device or channel, so one lifted from a single context authorises nothing in another. Outside that scope it is inert: not an encrypted PAN that might be decrypted, but a reference with no intrinsic meaning. Tokenization and virtual cards are related but distinct, and marketing copy uses the terms interchangeably: - A **virtual card** is a separate card product with its own number and its own controls, issued alongside the funding account and visible to the cardholder. - A **token** is a substitute representation of an existing card, generated by the network and normally invisible to the cardholder. They stack rather than compete. Provisioning a virtual card into a mobile wallet has the network issue a device-specific token for that card, putting two layers between the merchant and the original funding account. The commercial driver is as much compliance as security. Systems that never receive a real PAN fall largely outside PCI DSS scope, which is why processors push tokenization onto merchants who would otherwise carry the audit burden of storing card data. The limitation worth keeping in view: tokenization protects the number in storage and in transit. It does nothing about a transaction fraudulently authorised in the correct context — a token used by the right merchant for the wrong amount is still a dispute. See Virtual Cards: Single-Use Numbers, Merchant Locking, and What They Don't Protect and Stripe Connect: The Payment Infrastructure That Powers Marketplace Economies.