Network Tokens: VTS vs MDES vs Your PSP Vault

Roughly half of Visa's e-commerce volume now runs on network tokens rather than card numbers, on CMSPI's April 2026 estimate, and about 35% of card transactions overall. Most engineers integrating a PSP today have never explicitly asked for one. It happened underneath them, because Checkout.com provisions tokens by default on every payment and Stripe bundles them into a product you can switch on from the Dashboard.

That is fine until something breaks. The word "token" means four different things across the stack, the last four digits your API returns may not belong to the card your customer is holding, and the credential you think you own probably cannot leave with you. This guide works from the API surfaces as they stand in September 2026, plus the EMVCo framework and the regulatory record underneath them.

What Is a Network Token vs a PSP Vault Token?

Four distinct objects get called a token, and confusing them causes most integration bugs.

A PSP vault token is a database key. It has no meaning to Visa, it is not a payment credential, and it never leaves your provider's infrastructure. A network token is a real 16-digit credential minted by the scheme under its own account range, domain-restricted to one token requestor, and useless without a matching single-use cryptogram.

EMVCo's Payment Tokenisation Specification – Technical Framework reached v2.4 on 9 July 2026, and it is the common ancestor of both Visa Token Service and Mastercard Digital Enablement Service. The schemes diverge in the details, but the shape is shared: a token requestor ID (TRID), a token account range, domain restriction controls, and a cryptogram per transaction.

How Network Token Provisioning Actually Works

The token requestor ID is the piece engineers underestimate. Visa's acceptance documentation is blunt that "Having a TRID is a prerequisite for enabling network tokenization", and Mastercard formalises an On-Behalf-Of Token Requestor model where the PSP obtains a TRID for each merchant it onboards. Two structural options, then: your PSP tokenises under its own shared TRID, or you get your own. That decides almost everything about portability later.

Provisioning also fails in enumerable ways, which is the detail vendor pages leave out. Checkout.com publishes the underlying scheme codes: MDES returns PAN_INELIGIBLE, ISSUER_DECLINED, ACCOUNT_INELIGIBLE, PAN_PROVISIONING_COUNT_EXCEEDED and REDIGITIZATION_VELOCITY_COUNT_EXCEEDED; VTS returns cardNotEligible, provisionDataExpired and staleCardMetadata.

Two of those bite a backfill job. A recent decline pauses further attempts on that PAN for 24 hours or more, so a naive retry loop burns quota and achieves nothing. The velocity counters mean a bulk re-tokenisation of an existing vault rate-limits itself. Schedule the backfill; don't loop it.

Lifecycle is push-driven, not pollable. Mastercard's MDES Customer Service API exposes suspend, resume, delete and update alongside an outbound NotifyTokenUpdated notification. You need a webhook consumer and a reconciliation job, because token state is eventually consistent by design. One asymmetry to plan around: Gr4vy's lifecycle documentation flags suspension as Visa-only, so a cross-scheme state machine with a SUSPENDED branch has a permanently empty path on Mastercard.

Network Tokens in Stripe, Adyen, Checkout.com and Braintree

Here is what each one actually returns. These are the field names from the current references, not paraphrases.

Stripe exposes the least. payment_method_details.card.network_token has exactly one documented sub-field, used, and it does not distinguish a Stripe-provisioned token from a merchant-supplied one — the description covers both, "either user provided or Stripe managed". There is no network token object on the PaymentMethod, and no PAR anywhere in the acquiring API. Stripe's public pricing puts Authorization Boost at 0.2% per successful online card transaction on custom pricing, with network tokens standalone at 12p per token provisioned, and it does not absorb scheme-side fees such as Visa's Digital Credential Updater charge.

Checkout.com exposes the most, and it is the only one of the four that will hand you the token PAN. GET /network-tokens/{id} returns network_token.number next to card.last4. That endpoint is still Beta and sits behind a vault:network-tokens scope. Note the default trap: processing.provision_network_token defaults to true on the Payments API, but network_token.provision on the Instruments API defaults to false. Same product, opposite defaults.

Adyen splits the namespaces properly, networkToken. for the token and latestCard. for the funding card, but latestCard.bin is documented as Mastercard-only. On Visa you may simply not get the real BIN back. Its most useful field is one nobody talks about: retry.attemptN.networkTokenOffered. When a token attempt fails Adyen silently retries on the PAN, and you see it as attempt1: "true" followed by attempt2: "false".

Braintree is the cautionary tale. is_network_tokenized? tells you a token exists; processed_with_network_token? tells you one was used, and the docs warn that "a token may not always be used for a transaction". Different booleans, routinely conflated in dashboards.

Device Tokens vs Card-on-File Tokens: The last4 Trap

Every provider handles wallet tokens differently from card-on-file tokens, and the naming is a genuine mess.

Braintree alone spells "last four" three ways with two different meanings. Apple Pay gives you last_4 (the DPAN) and source_card_last4 — no underscore before the 4 — for the real card. Google Pay gives you virtual_card_last_4 and source_card_last_4. Then the GraphQL API defines last4 with the polarity inverted relative to REST: for network-tokenised payments it is the source card, otherwise the virtual card. Braintree's own docs also define is_network_tokenized? as a TPAN on one page and a DPAN on another.

The practical rule: never display a last four without knowing which credential it came from. If your receipt shows the DPAN's last four and the customer is holding their plastic card, your support queue absorbs the difference. Stripe handles this reasonably, with card.last4 for the real card and wallet.dynamic_last4 for the device account number, but its card.fingerprint can be computed over the tokenised number for wallet payments — so fingerprint-based deduplication silently fails across Apple Pay and plastic for the same card.

What Is Payment Account Reference (PAR) and Does Your PSP Return It?

PAR is the scheme-assigned identifier that links every credential derived from one funding account: the plastic, the Apple Pay DPAN, the card-on-file token. It is 29 alphanumeric characters, made up of a 4-character EMVCo-assigned BIN Controller Identifier and a 25-character unique value, and it cannot initiate a transaction. Checkout.com's documentation states the useful property directly: all affiliated payment tokens and the underlying PAN carry the same PAR.

It is weaker than it looks. The US Payments Forum's December 2024 white paper documents the gaps: PAR sits in Field 56 for Visa and Mastercard but Field 112 subfield 1 for Amex; Discover does not support it in EMV tag 9F24 and offers none at all for its prepaid, debit and small business products; Visa treats merchant-supplied PAR at authorisation as optional. The paper's verdict is that "PAR has limited adoption today". It also notes PAR is generally treated as personal data, so storing it carries the GDPR obligations you would expect in the UK and EU.

Every provider spells it differently — payment_account_reference at Checkout.com, PaymentAccountReference at Adyen, paymentAccountReference at Worldpay and Braintree, paymentAccountReferenceNumber at Cybersource. Stripe does not expose it on the acquiring side at all. Build dedup around PAR where you can get it, and keep a fallback path.

Do Network Tokens Improve Authorisation Rates?

The position I will defend: the uplift is real, but every number you have read is unaudited vendor arithmetic, and you should plan as though yours lands at the bottom of the range.

Published figures sit between 2 and 11 percentage points. Visa is cited at +4.6% on card-not-present, Mastercard at +2.1%, Adyen claims an average 3% uplift from its own platform data in a 2023 press release, PayPal claims 4.8 percentage points from a window of Q4 2020 to Q3 2021, and Checkout.com's product page advertises an 11% average increase. Not one discloses a sample size, a control group, or segmentation by issuer, MCC or market.

Two structural problems with all of it. The variable that dominates is issuer participation in your target market, which you do not control: Amex's own developer network states that card-on-file tokenisation availability varies by country and excludes third-party-issued Amex cards. And the counterfactual is decaying. If half of Visa's e-commerce volume is already tokenised, the untokenised cohort increasingly self-selects for cards that could not be tokenised in the first place.

There is also a mechanical way to get zero uplift, which I have watched happen. Submit the token without a cryptogram and the issuer treats it as an ordinary card-on-file transaction. The field is easy to miss — in Adyen it is mpiData.tokenAuthenticationVerificationValue on v68 and later, mpiData.cavv before that. Cryptograms are single-use; replaying one gets you declined.

Are Network Tokens Portable Between PSPs?

Mostly no, and the documentation proves it by omission.

Look at what each provider exports when you leave. Stripe's payment data export ships an encrypted JSON file whose cards array contains a literal number field — the raw PAN. Network tokens are not mentioned on that page at all. Braintree exports a GPG-encrypted CSV containing credit_card.number, and states that Apple Pay and Google Pay tokens "are not transferrable between providers" and are excluded. Checkout.com's inbound migration guide asks for card number, expiry and the scheme transaction ID, and never says existing tokens transfer.

So the portable asset is the PAN plus the network transaction identifier, not the token. That NTI matters more than most teams realise: it preserves the CIT/MIT chain so recurring charges keep their stored-credential status after the move. Braintree exports it as credit_card.network_transaction_identifier.identifier and warns it comes back empty for brands that do not support it.

Two providers do better. Checkout.com states you can extract your network tokens and cryptograms "to use them with the acquirer and processor of your choice", via GET /network-tokens/{id} plus POST /network-tokens/{id}/cryptograms. Adyen's /forward endpoint pushes stored details, including network tokens with cryptograms, to a third-party PSP, but requires an Adyen vault token for the same card as a fallback and will not fall back automatically.

Owning your own TRID is necessary but not sufficient. A token list exported to a provider that cannot fetch cryptograms and consume lifecycle events is a list of dead credentials. The only hard deadline anywhere is regulatory: the Reserve Bank of Australia's May 2024 expectations required scheme and proprietary token portability by the end of June 2025, with migration services that "should not require gateways to retain PANs". No UK or EU regulator has matched that.

Why Network Tokens Break BIN Routing and Least-Cost Routing

This is the cost that rarely appears in the business case.

A token sits in the scheme's own account range, not the issuer's BIN. Visa assigns 9-digit token account ranges and holds processing attributes at account-range level, so any merchant-side BIN table keyed on six digits misclassifies tokens outright. Braintree's GraphQL schema says the quiet part: for a wallet or token origin the real card's BIN "may not be present", and the token's BIN "may differ from the BIN of the customer's actual card".

The consequences are on the regulatory record. The FTC's December 2022 order against Mastercard turned on exactly this: issuers let Mastercard mint the token and hold the PAN in a vault competing debit networks could not read, which made routing US e-wallet debit anywhere else impossible. The remedy forced Mastercard to supply the PAN to those networks. De-tokenisation access, not token format, determines routability.

Australia's RBA documented the co-badging version. A scheme token is scheme-specific, so tokenising only one badge on a dual-network debit card kills least-cost routing for that credential. Its expectations require tokens for both networks, a backfill path when the second fails temporarily, and lifecycle state synchronised across both. A suspended eftpos token alongside an active Visa token for the same card is a bug a regulator anticipated in writing.

If you operate where routing choice is real, model the routing loss against the auth uplift before you tokenise. They are not obviously the same size.

Do Network Tokens Replace SCA or Reduce PCI Scope in the UK and EU?

Both are routinely overclaimed, but the honest answers are narrower than a flat no.

A card-on-file network token is not an SCA substitute on its own. J.P. Morgan's developer documentation says so, and the field list makes it obvious: with 3DS you supply the ECI and the token cryptogram, because they answer different questions. The cryptogram proves the credential is genuine; the ECI carries the authentication outcome. The exception is worth knowing. EBA Q&A 2019_4827 accepts that a tokenised card solution may count as a possession element, but only under four cumulative conditions, and the load-bearing one is binding to a trusted device with SCA applied at token issuance. That describes a wallet, not a server-side token in your vault. Which transactions need a challenge is a separate, exemptions question, covered in the SCA exemptions guide.

PCI is the one where the conservative answer is also wrong. PCI SSC FAQ 1326 states that an EMVCo payment token used in accordance with the specification, held outside the token service provider's environment, "is not considered Account Data and is therefore not in scope for PCI DSS" — conditional on a dynamic cryptogram or sufficient domain controls, and on PAN recovery being infeasible. So a token store genuinely can drop out of scope.

What it does not do is take you out of scope. The out-of-scope test is conjunctive, your point of acceptance still transmits a PAN, and SAQ A validation still applies — including the e-commerce script requirements binding embedded-form merchants, which do not care which credential flows through the form. Note too that FAQ 1326 dates from May 2015 and predates PCI DSS v4. Scoping detail is in the PCI DSS 4.0 guide.

The pressure to adopt is economic rather than regulatory, and rising. Mastercard committed in June 2024 to 100% e-commerce tokenisation in Europe by 2030. Visa's Digital Commerce Security Fee changed on 1 April 2026, with US domestic card-not-present moving from 0.0075% to 0.015% and cross-border to 0.035%, its scope widened to cover account updater, token authentication verification and token lifecycle events. Analysts at CardTraq note both networks now bill digital-enablement fees on declined authorisations too.

What This Means for Payments Engineers in 2026

Concrete steps, in the order I would do them.

1. Find out what you are already doing. Log the used-a-token flag for your provider on every authorisation and chart it. On Checkout.com's Payments API you are provisioning by default; on Adyen you need a support ticket; on Stripe, check the Optimization page. 2. Separate the fields in your schema now. Token BIN, token last four, funding card BIN, funding card last four and PAR are five columns, not two. Retrofitting after a wallet launch is painful. 3. Decide the TRID question deliberately. A shared PSP TRID is faster to launch. Your own is the only version that gives you a real exit, and Mastercard's OBOTR model is how PSPs onboard merchant-specific TRIDs. 4. Build the lifecycle consumer before the volume arrives. Webhook handler plus reconciliation job, with a SUSPENDED state you accept may only fire on Visa. 5. Check the cryptogram is on the wire. Pull a tokenised authorisation from production logs and confirm the field is populated. Highest-value fifteen minutes in the project. 6. Keep the PAN-referenced escape hatch. Every documented migration path runs on card number plus network transaction identifier. Make sure you can produce both.

One last observation. I went looking for a single first-party engineering write-up from a merchant that had migrated to network tokens, with real numbers, and could not find one. Every substantive account is published by a PSP, an orchestrator or a vault vendor with something to sell. That absence should calibrate how much weight you give the uplift figures, and it is a good reason to instrument your own rollout as an A/B test rather than a migration.

If you are working through this and want to compare notes, I am Tom Wang, and I write about payments infrastructure here most days.