Network Tokens vs PSP Tokens

PSP tokens (also called gateway tokens or vault tokens) are reference IDs that point to stored card data inside your processor's vault. Stripe's tok_xxx and pm_xxx, Braintree's vault tokens, and Adyen's storedPaymentMethodId all fall into this category.

Under the hood, the vault still stores the original PAN and expiration date. The token is just an alias. This means:

• The underlying data is still a raw PAN + expiry, subject to all the same lifecycle problems as a bare card number.
• If the physical card expires, the PSP token does not magically update itself. Without Account Updater, you will get Code 54 (Expired Card) on the next charge attempt.
• PSP tokens are processor-specific. A Stripe token cannot be used at Braintree. If you migrate processors, you need to re-collect card details or negotiate a PAN export (which is a PCI headache).
• PSP tokens provide zero interchange benefit. The card network never sees your token; it only sees the PAN your processor sends on your behalf.

Network tokens (formally EMV Payment Tokens) are generated by the card network itself. Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) issue these tokens as replacements for the PAN at the network level.

The key differences from PSP tokens:

• Lifecycle management. When the underlying card is reissued, expires, or gets a new number, the network token updates automatically. The issuer pushes the update to the token vault with no merchant action required.
• Merchant-scoped. Each network token is bound to a specific merchant. If a token is compromised, it cannot be used anywhere else. This is a material fraud reduction.
• Cryptograms. Each transaction made with a network token includes a unique cryptogram, similar to how EMV chip cards generate per-transaction authentication. This proves the token is being used by the authorized merchant.
• Interchange incentives. Visa offers approximately 0.10% reduction on eligible card-not-present transactions when network tokens are used. On volume, this is real money.

The two major networks handle token expiration dates differently, and getting this wrong causes silent failures.

Visa: Even when you have a network token, Visa requires you to submit the original PAN's expiration date in the authorization message. If you send the token's own expiry, the transaction may be declined. This trips up merchants who assume the token replaces all PAN-related fields.

Mastercard: The opposite. Mastercard requires you to submit the token's expiration date, not the underlying PAN's. Mastercard tokens expire 36 months after provisioning. Here is the catch: you must send the token's expiry even if it is in the past. Mastercard's authorization system handles expired token dates differently than expired PAN dates.

If you process both Visa and Mastercard, your integration needs to branch on the network and populate the expiry field accordingly. A single codepath for both will produce intermittent declines on one network or the other.

Network tokenization is growing fast but is far from universal.

• Visa has provisioned over 10 billion network tokens globally. Roughly 50% of Visa digital commerce transactions now use tokenization.
• Mastercard reports 30%+ of its transactions are tokenized. Both networks are targeting near-universal adoption by 2030.
• Among subscription businesses specifically, only about 45% use tokenization that covers full lifecycle management (automatic updates on card reissue). The rest rely on PSP tokens plus Account Updater, or nothing at all.

The gap between "we support tokens" and "tokens are actually flowing on every transaction" is significant. Many merchants have tokenization enabled at the gateway level but are still sending raw PANs for stored credentials because their integration was never updated.

If network tokens auto-update, why does anyone still get Code 54 (Expired Card)?

Several reasons:

• Most merchants still transact on raw PANs or PSP tokens. If you are in the ~55% of subscription businesses without lifecycle-aware tokenization, you have no automatic update mechanism.
• Non-participating issuers. Not every issuer supports network token provisioning. Smaller regional banks and credit unions may not have integrated with VTS or MDES. Transactions to these issuers fall back to PAN-based processing.
• Excluded card types. Prepaid cards, gift cards, and some government-issued cards are excluded from network tokenization programs.
• Synchronization delays. Even with network tokens, there is a propagation delay between when the issuer reissues a card and when the token vault reflects the update. If your billing cycle fires during this window, you can still get a decline.

Stripe manages network tokens transparently for merchants on supported configurations. You do not need to provision tokens yourself.

The card.networks.available field on a PaymentMethod object shows which card networks are available for that stored card. Stripe's Authorization Boost feature combines network tokens with Account Updater to increase acceptance rates by an average of 2.2%. This is not a number Stripe buries in marketing materials; it shows up in the payment_method_details.card object on successful charges.

If you want to verify that network tokens are active on your account, check whether payment_method_details.card.network_token.used returns true on a recent charge. If it returns false or the field is absent, your transactions are still running on raw PANs.

For non-Stripe processors: Adyen, Braintree, and Checkout.com all support network token provisioning, but the integration depth varies. Some require explicit opt-in per merchant account.