Payment Credential Vault Architecture: Topology, Control, and Migration

Most credential architecture questions get answered with a token comparison — network tokens versus PSP tokens, which one wins on authorisation rate, which one survives a card reissue. That comparison is already well covered in network tokens vs PSP tokens, and this article does not repeat it.

The question underneath it gets asked far less often, and matters more once you need an answer: where do these credentials physically sit, who controls the relationship that makes them work, and what happens to that relationship when you leave a PSP. Token format is a technical detail; vault topology and control are the operational reality that decides whether a PSP migration is a configuration change or a six-month re-authentication campaign.

Five credential types, not two

Most conversations about stored payment credentials collapse into "PSP token vs network token." That framing skips three other things a stored credential can actually be, each with its own owner and its own migration behaviour.

The distinction that gets lost when this is flattened to two categories: a vault token and a PSP token look almost identical in application code — both are opaque reference strings — but they behave completely differently in a migration, because one is issued by an entity the merchant contracts with directly, and the other is issued by whichever processor happens to be running the checkout that week. PCI DSS scope, detokenisation rights, and migration mechanics all trace back to this ownership distinction, not to whether the value on the wire looks like a card number.

Device tokens are not network tokens

Device tokens and network tokens get treated as the same thing constantly, because both are scheme-issued and both replace the PAN with a domain-restricted surrogate. They are provisioned by different parties, for different purposes, and they behave differently when a merchant changes PSPs — differences that matter for support triage and for migration planning, not just terminology.

A merchant card-on-file network token is provisioned when a customer saves a card at checkout, and the Token Requestor is typically the PSP or gateway acting on the merchant's behalf — EMVCo's own use-case guide describes this as the "Third Party Service Provider" pattern, where the merchant is the Token User and the PSP holds the actual Token Requestor relationship. A device token is provisioned when a customer adds a card to a mobile wallet — the Token Requestor there is the wallet provider itself, entirely outside the merchant's and the PSP's control. EMVCo's guide states this directly for proximity payments: the consumer device "is provisioned with a Payment Token... by the mobile payment application provider (Token Requestor)."

Three consequences follow. Provisioning trigger: a merchant CoF token needs a transaction or an explicit "save this card" action; a device token needs nothing from the merchant at all — a customer can add a card to Apple Pay or Google Pay months before ever transacting with you, invisibly. Migration behaviour: merchant CoF network tokens are tied to the merchant ID your PSP operates on your behalf, so switching PSPs generally means re-provisioning (mechanics covered in the card credential lifecycle guide); device tokens are untouched by a PSP migration, because that relationship sits between the wallet and the scheme, not between merchant and PSP. Support triage: a merchant CoF token issue is fixable through the PSP's re-tokenisation flow; a device token issue — card removed from the wallet, phone replaced — is entirely outside merchant or PSP control, with nothing on your side to re-tokenise.

This isn't a niche distinction: India's RBI tokenisation mandate is the clearest live example of an operator having to build support scripts that separate the two explicitly, because its no-PAN-storage rule makes this boundary operationally unavoidable rather than a background detail.

Three vault topologies, and the control you're trading away

Wherever a stored credential lives — raw or tokenised — it lives inside one of three topologies, and the choice is a control-versus-effort trade, not a security-versus-convenience one.

PSP vault. The processor holds the credential (as a raw PAN internally, or as a PSP-proprietary token) and issues the merchant an opaque reference. This is the default for almost every merchant — it's what you get by simply calling Stripe's or Adyen's tokenisation API. Lowest integration effort, lowest operational burden, and the least control: the merchant has no independent relationship with the underlying credential at all.

Merchant-hosted (self-hosted) vault. The merchant runs its own card data environment and holds the PAN directly. PCI SSC calls this the "on-premise" model: the merchant "maintains control over all components of the tokenization system" and is "fully responsible for complying with all applicable PCI DSS requirements." Maximum control, maximum PCI DSS burden, and the highest breach liability of the three — few merchants choose it deliberately outside large, security-mature organisations with a specific reason to hold the data themselves.

Third-party independent vault. A dedicated vault provider — VGS, Basis Theory, and Skyflow are the recognised category examples — holds the credential and issues the merchant a vault token the merchant controls independently of any single PSP. This is PCI SSC's "outsourced" model: the vault provider "assumes responsibility for the components it manages," formalised in an agreement between merchant and provider. Basis Theory states the trade-off from the vendor side plainly: in a PSP-hosted vault, "the token delivered to a vendor by one PSP cannot be used to securely process a transaction through an alternative PSP," whereas in the independent-vault model the merchant "retains token ownership" and can route the same underlying credential to whichever PSP it chooses.

The topology decision is a decision about who holds the relationship you'll need at the moment you want to leave a PSP. A PSP vault gives you nothing to hold onto. A merchant-hosted vault gives you everything, at a PCI DSS cost most merchants don't want to carry. A third-party vault is the middle position: no direct PCI burden, but a credential relationship that survives any single PSP's departure.

Token Requestor ownership: the fact that actually decides portability

Of everything covered here, this is the detail most likely to be wrong in a merchant's own mental model, and the one worth confirming directly rather than assuming.

EMVCo's Payment Tokenisation framework separates the Token Requestor — the entity that registers with a network and requests tokens — from the Token User, the entity that actually presents the token in a transaction. These are not automatically the same party. In the "Third Party Service Provider" use case, the merchant is the Token User, and the PSP or gateway is the Token Requestor, managing the interface to the network's Token Service Provider on the merchant's behalf. EMVCo is explicit that this arrangement lets a single Third Party Service Provider hold the Token Requestor relationship for many merchants at once, and that a single token can be shared across multiple Token Users under one Token Requestor.

That structural fact is the actual answer to "will my network tokens move with me to a new PSP." If your PSP is the Token Requestor of record, the registration, the scheme relationship, and the provisioning history all belong to the PSP — not to you, and none of it transfers when your account ends. If you hold your own Token Requestor ID, that relationship is yours to carry, at least in principle — though it still typically requires re-provisioning against the new PSP's merchant ID, as multi-entity MID architecture covers: network tokens are bound to whichever MID a PSP operates for you, so a new PSP means a new MID regardless of who requested the token.

How to find out what you have today. Ask your PSP account manager directly: are we registered as the Token Requestor for our network tokens, or are you? If it's the PSP, ask what happens to that registration and to already-provisioned tokens on termination. Most merchants have never asked, because the tokens work identically either way — until the day they need to migrate.

Detokenisation: who can, and the boundary that makes a token useless elsewhere

A token is only as useful as its ability to be reversed back to a PAN by someone authorised to do it — and that authority is deliberately narrow, in every topology. For network tokens, EMVCo's framework places de-tokenisation at the card issuer's own Token Service Provider systems, performed at the moment an authorisation, refund, or chargeback request is routed — the issuer's TSP "performs De-Tokenisation and applies the Token Domain Restriction Controls" before the PAN authorisation proceeds. No PSP, gateway, or merchant holds that capability for a network token at any other point in its life. This is also what makes a token domain-restricted rather than universally portable: Token Domain Restriction Controls bind a token to its intended context — device-specific, merchant-specific, or single-use guest checkout — so a token copied outside its own domain has no value, because the issuer's TSP simply won't complete de-tokenisation for a context it wasn't issued for.

Vault tokens and PSP tokens work differently, because the vault provider or PSP holds the underlying PAN directly rather than relying on a scheme-level mapping. A PSP operating its own vault can generally detokenise internally for support, refund-to-a-different-instrument requests, or a migration export — the capability Stripe's and Adyen's own PAN-export processes rely on. That flexibility is also why a PSP-hosted vault carries more direct PCI DSS exposure: holding detokenisation capability means holding the PAN, in scope, indefinitely.

India's RBI tokenisation mandate takes the network-token model to its logical extreme, worth naming as the boundary case: no intermediary downstream of the network — aggregator, gateway, or merchant — is permitted to hold detokenisation capability or PAN data after authorisation. That's stricter than the typical PSP-vault model this article otherwise describes, and it's concrete: no support-side manual charge from a looked-up card number, no self-service refund-to-a-different-card, no PAN file to bootstrap a migration from.

PCI DSS scope: what each topology actually removes

PCI SSC's own tokenization guidance is more conservative than most vendor marketing about what tokenisation removes from scope — a gap worth knowing before relying on either. The Council's scoping principles are specific: a system that stores, processes, or transmits only tokens can be considered out of scope, but only if PAN recovery is not computationally feasible from the token alone, and the system is fully segmented from anything that can submit a de-tokenisation request or reach the vault or its cryptographic keys. The tokenization system itself — including de-tokenisation and any PAN storage — is always in scope as part of the cardholder data environment, regardless of deployment model. The point of capture and any de-tokenisation point stay the merchant's responsibility even in an outsourced deployment; PCI SSC's guidance is explicit that the split of responsibility has to be documented in a formal agreement, not assumed from a product description.

Mapped onto the three topologies: a PSP vault carries the CDE burden itself, and the merchant's own systems can often qualify for a lighter SAQ category (commonly SAQ A) if card data never touches merchant infrastructure — though PCI DSS v4.0's updated SAQ A rules tightened this for merchants using embedded iframe payment fields, one of the year-one findings operators keep getting wrong. A merchant-hosted vault carries full PCI DSS responsibility for every component, with no scope reduction at all — PCI SSC's "on-premise" model, and the most expensive to assess. A third-party independent vault shifts responsibility for the outsourced components to the provider by agreement, and the merchant's own scope reduction depends on how tightly its systems are segmented from the vault and any de-tokenisation point; vendor-marketed figures like "up to 90% scope reduction" (VGS, Skyflow) are the vendor's own architecture claim, not an independently audited number, and don't substitute for confirming your own segmentation meets PCI SSC's criteria.

None of the three eliminates PCI DSS obligations outright — they redistribute where the remaining obligations sit, which is a meaningfully different claim than "tokenisation gets us out of PCI scope."

PSP migration mechanics: what actually happens when you move

This is the moment vault topology stops being an architecture diagram and becomes an operational project — far more procedural, and far slower, than most merchants expect going in.

Raw PAN export, PCI-gated. Stripe's own data-migration documentation states plainly that it will only transfer card data to another PCI DSS Level 1-compliant processor, which must provide either a current PCI Attestation of Compliance or a listing on Visa's Global Registry of Service Providers, plus a PGP public key of at least 4096 bits, hosted over HTTPS on one of the receiving processor's own registered domains. This isn't a formality — a merchant that hasn't already selected and contracted with a compliant receiving processor cannot begin the export. Stripe also excludes credentials saved via Link from any export outright, regardless of the receiving processor's compliance status.

PSP-to-PSP vault migration. Adyen's documented import process coordinates an internal shopper reference with the losing provider before any file moves, because Adyen tokenizes recurring-payment data against that reference rather than the raw payment details themselves. On export, Adyen requires a Data Processing or Data Transfer Agreement, the receiving processor's compliance attestation and a publicly listed PGP key, and runs a limited sample export first — around 1,000 shopper references — so the receiving vault can confirm it can decrypt and ingest the file before the full export proceeds. The result is a fixed-format CSV; Adyen states directly that "customisation of this format is currently not possible." None of this is negotiable per-merchant — it's baked into the standard migration process on both sides.

What's lost. PSP-proprietary tokens simply don't transfer — meaningless to the receiving PSP by definition, which is why raw PAN export exists as a separate, heavier process. Network tokens are bound to the losing PSP's merchant ID, so even where the scheme-side token-to-PAN relationship persists, the tokens generally need re-provisioning against the new PSP's MID rather than transferring automatically — the same MID binding described above. Fraud-model calibration and dispute history don't travel either, a cost covered in full further below.

Realistic timeline. Adyen states its own migrations "typically" take 10 days or more for technical and compliance reasons — and that figure covers only the data-transfer mechanics once both processors and the agreement are already in place, not the vendor selection and contracting that precede it or the cutover and decline-monitoring window that follow it. Budget the full migration as a multi-week project at minimum, not a weekend cutover.

Multi-PSP routing against one credential store

Running more than one PSP for routing, redundancy, or negotiating leverage creates a specific credential problem: if each PSP tokenises independently, the same card ends up with a different, non-interchangeable token at every PSP in the stack, and no single place knows they're the same card.

A third-party independent vault addresses this by design: the merchant stores the credential once, in a vault it controls, and requests tokenisation against whichever PSP a given transaction needs — Basis Theory names this as the core reason merchants who "wish to... use multiple PSPs simultaneously" adopt a third-party vault rather than any single PSP's proprietary token. The vault becomes the canonical store; each PSP-specific token is a derivative of it, not a replacement for it. The alternative — a PSP vault as the canonical store, with a second PSP bolted on for routing — inherits the same single-PSP lock-in already described, just spread across two relationships instead of one. The token-orchestration layer (Primer, Spreedly) some merchants add on top of multiple PSPs needs exactly this kind of vault underneath it to actually work, not as a separate fix for the same problem.

Identifier mapping: one card, several IDs, one ledger

A single physical card can legitimately carry several identifiers at once inside a merchant's stack — a vault token from an independent vault provider, one PSP token per PSP it's routed through, a network token per merchant ID it's tokenised against, and potentially a device token in a customer's wallet the merchant never provisioned. None of these look alike, and without a deliberate mapping strategy, nothing in the ledger knows they're the same credential.

EMVCo's framework has a built-in answer for the network-token slice of this: Payment Account Reference (PAR). PAR data is the same value for a PAN and every network token affiliated with it, specifically so a merchant can link transactions across a mix of PAN-based and token-based payments without needing the PAN itself — made available in the PAR field at the conclusion of token processing, or via a separate enquiry. It's a mechanism built exactly for the "is this the same card, even though the token looks completely different" reconciliation problem.

PAR's coverage has a real limit: it links a PAN to its affiliated network tokens only. It does not tie a PSP-proprietary token or an independent-vault token into that chain — those live entirely outside the EMVCo framework, in the PSP's or vault provider's own identifier space. Building a complete cross-domain map — vault token, PSP token(s), network token(s), and PAR where available, all resolving to one internal customer-credential ID — is integration work the merchant has to do deliberately. Skip it, and the same customer's card gets treated as several unrelated instruments in fraud scoring, duplicate-payment-method detection, and reconciliation, because nothing forced the identifier spaces to converge.

Incident containment: what a vault compromise means, and what you can revoke

Topology determines blast radius, and what "contain the incident" actually means when something goes wrong.

A PSP vault compromise is the PSP's incident to run; the merchant has no independent lever to revoke or rotate credentials faster than the PSP acts, because it never held the underlying relationship. A merchant-hosted vault compromise is entirely the merchant's own incident — full PAN exposure risk and full breach-notification obligations, but also, the flip side of the control this topology offers, every lever to revoke, rotate, or re-key immediately.

A third-party independent vault compromise sits in between, and its containment story is the more interesting one: because the vault is the canonical store and PSP-facing tokens are derivatives of it, revoking the underlying vault credential can, depending on the provider's design, invalidate every downstream token in one action — a single point of revocation across every PSP in a multi-PSP setup, rather than a separate response per relationship. That same centralisation is what makes multi-PSP routing viable in the first place; it also makes the vault the single highest-value target in the whole stack, so its own PCI DSS Level 1 status and security posture matter more than any individual PSP's.

What's revocable also differs by credential type, independent of topology: a network token can be suspended at the scheme level without affecting the underlying PAN or the physical card elsewhere — Token Domain Restriction Controls exist precisely to make a token's blast radius smaller than the PAN's. A raw PAN has no equivalent partial-revocation option; a raw-PAN compromise means the underlying card, full stop.

Regional constraints: India's mandate as the live example

Vault topology choices aren't purely a merchant decision everywhere. India is the clearest current example of a regulator collapsing the topology choice to one option by law: no payment aggregator, gateway, or merchant may store raw PANs after a transaction completes, ruling out the merchant-hosted vault and any topology that relies on a merchant- or PSP-side PAN lookup — the strictest version of the detokenisation boundary described above, applied as a blanket requirement rather than a choice a merchant made voluntarily.

The operational effect for a multinational operator is asymmetric risk: a vault topology and migration plan that works cleanly almost everywhere can hit a wall specifically in India, where a PSP migration cannot bootstrap from an exported PAN file, because no PAN file exists anywhere in the aggregator's stack to export. Treat India as a distinct case in your migration runbook, not an edge case of your default topology — the default topology described elsewhere in this article simply isn't legally available there.

Vendor lock-in and data-ownership contract terms

Every topology creates a different lock-in shape. PSP vendor lock-in covers the negotiation playbook — network token portability clauses, data export rights, rolling reserve timing — and applies most directly to a PSP vault, the topology with the least built-in exit leverage. For a third-party independent vault, that same lock-in risk shifts to the vault relationship itself: a vault contract worth signing specifies data export rights and format in the same explicit terms, plus how token-to-PSP mappings and PAR export alongside the raw credential data — the vault only delivers on its portability promise if the contract guarantees everything comes back out, not just the card data.

Common failure modes

Assuming a PSP token and a vault token are equally portable. They look identical in application code and behave completely differently the moment a PSP relationship ends.

Never confirming who holds the Token Requestor relationship. Most merchants find out their PSP was the Token Requestor of record — not them — only at migration time, too late to have negotiated otherwise.

Treating "we use tokenisation" as "we have reduced PCI scope." PCI SSC keeps the point of capture and every de-tokenisation point in scope regardless of deployment model; a vendor's marketed scope-reduction percentage doesn't substitute for verifying your own segmentation.

Planning a PSP migration around the checkout and forgetting the credential base. The checkout can go live in weeks; the stored-credential transfer is a separate, PCI-gated process with its own prerequisites and multi-week timeline.

Building multi-PSP routing on a PSP vault instead of a shared credential store, and assuming India's strict no-PAN-storage model generalises (or that other markets' looser assumptions apply there) — both break in the direction you got them wrong.

What to read next

• Network tokens vs PSP tokens — the auth-rate and lifecycle comparison this article deliberately skips, including the multi-PSP portability problem and orchestration layers.
• Card credential lifecycle and Account Updater operations — what keeps a vaulted credential working over time.
• PSP vendor lock-in — the contract-negotiation playbook for the exit this article's migration section describes.
• PCI DSS 4.0, year one — where SAQ eligibility assumptions are breaking in practice.
• India's RBI tokenisation mandate — the regulatory case where topology choice is removed entirely.