Network Tokenization Explained: Network Tokens vs Vault Tokens

A saved card in a payment integration usually sits behind two different tokens. One is the vault token your payment provider gives you, a reference that only works inside that provider’s account. The other is a network token, issued through the card network to stand in for the card number itself as the payment travels to the issuer. They solve different problems, and confusing them leads to wrong assumptions about portability, declines and what your own database holds.

Two tokens, two scopes

A vault token is created by the processor. Stripe describes its own tokens as a nonsensitive string that can be used only by the business that collected the card. Adyen’s tokenization works the same way from the developer’s side: Adyen swaps the card details in your request for a token, sends it to you in a webhook, and you use it in later recurring requests for that shopper. The card number still sits in the provider’s vault, and the provider still sends that card number to the network when it authorizes a charge.

A network token replaces the card number further down the chain. EMVCo, which publishes the standard, describes an EMV Payment Token as a unique alternative value for the primary account number (PAN) that is constrained in how it can be used, for example to a specific merchant, device or payment scenario. It is used from the point of purchase through the acquirer and across the card network to the issuer for authorization.

The table summarizes the linked EMVCo, Stripe and Adyen documentation. It is not a contract for every product either provider sells.

What a network token changes in practice

The most visible effect is on stored cards. Adyen’s documentation says card networks maintain network tokens so they remain valid when the card details change: if a shopper receives a new card because the old one expired or was lost, the network token remains the same. Stripe’s guide makes the same point and links it to fewer declines for outdated credentials, particularly for subscriptions and other frequently used cards.

The second effect is security. Adyen says each network token transaction is protected with a single-use cryptogram. Stripe notes the cost of that design: the cryptogram often has to be fetched from the network, which can add latency compared with sending a card number.

The third effect concerns reporting. Because a merchant may hold tokens rather than card numbers, EMVCo’s framework defines a Payment Account Reference (PAR) that links transactions made with tokens to the PAN they were issued for. EMVCo lists fraud screening, some PAN-based loyalty systems and transit among the uses. Visa’s token service page describes a PAR inquiry service for the same purpose. If your analytics group customers by card fingerprint, check what your provider returns for tokenized payments before assuming the old grouping still works.

Let the provider manage tokens, or hold them yourself

Most integrations never touch a network token directly. Stripe says it has built integrations with Visa, Mastercard and American Express and requests network tokens on the business’s behalf, then decides per transaction whether to use the token or the underlying card number. Adyen offers the same managed option with no extra integration: when a request carries a storedPaymentMethodId, Adyen swaps it for a network token before authorization.

Adyen also documents a self-managed route for merchants that already obtain network tokens from the card networks. The request changes shape:

• paymentMethod.type is set to networkToken, and paymentMethod.number carries the token, with the token’s own expiry month and year.
• mpiData.tokenAuthenticationVerificationValue carries the token cryptogram (TAVV); Adyen notes that Checkout API v67 and earlier use mpiData.cavv instead.
• The response returns a networkTxReference, which you save and send with subsequent payments on the same token.

Adyen states two limits worth reading before choosing this route. The self-managed option cannot be combined with Adyen’s own tokenization feature, and network tokenization applies only to payments Adyen acquires, not to external acquirer connections.

Failure handling and fallback

A network token attempt can fail where the card number would succeed. Stripe says it keeps the PAN available to retry failed network token transactions. Adyen documents the same behavior: if the first attempt with a network token is refused, it retries without one. With the optional “retry attempts” data enabled, the /payments response and the AUTHORISATION webhook show each attempt, including retry.attempt1.networkTokenOffered.

That detail matters for support and reconciliation. An approved payment can carry a refused first attempt in its additional data. Treat those fields as diagnostics, not as a second payment, and keep decline-code handling based on the final result.

For merchants who manage tokens themselves, Adyen says including the underlying PAN in the request, which requires full PCI compliance, lets Adyen recover refused payments with a PAN fallback. Holding card numbers to enable that fallback brings them back into your environment, which undoes much of the scope reduction described in our guide to PCI DSS scope and tokenization.

Portability is not automatic

Network tokens are often described as portable, but the documentation is narrower. EMVCo says a token can be restricted to one merchant, device or scenario. Adyen describes a network token as unique per combination of shopper and merchant, offers token sharing between a company’s own merchant accounts on request, and documents forwarding network tokens to a PCI-compliant third party such as another payment service provider.

Before a processor migration, ask which token requestor the tokens were provisioned under, whether the old provider will forward them, and what the new provider needs to keep using them. Version differences matter too: field names such as mpiData.cavv changed between API versions, which is the kind of change our payment API changelog tracker follows.