Veliro · PSP independence

Network tokens under your TRID. Same `tok_*` on every acquirer.

Veliro provisions Visa, Mastercard, and Amex network tokens under your own TRID, with PAN fallback in your Level 1 PCI vault where the networks don't support them. Stored credentials never enter a PSP vault, so switching processors becomes a connection_id change, not a card re-entry project.

Start in sandbox Contact sales →

Compliance roadmap · SOC 2 Type II · PCI DSS Level 1 · ISO 27001 · EU SCA · PSD2

0card re-entries on switch1ID across acquirerspolicyswap, no vault rebuild

Gateway tokens are locked to the PSP, not to you.

Lock-in is not a contract clause. It is an architecture choice: cards provisioned to the gateway’s merchant ID, stored in the gateway vault, and useless the day you leave.

Lock-in anatomy · gateway tokens vs network tokens

veliro · architecture

PSP lock-in happens in three moves: you store cards through the PSP’s hosted fields or vault API; the PSP provisions a gateway token locked to its merchant account; your authorization, reconciliation, and dispute data all assume that lock-in. When you renew your PSP contract or fail over from an outage, the tokens do not travel with the customer relationship you own; the PSP keeps the card.

PSP-by-PSP: where the lock-in lives.

The product names differ. The lock-in is the same: stored credentials live under the PSP’s account, not under your TRID on the card network.

How each PSP locks stored credentials
PSP	What’s locked	Bound to
Stripe	Card-on-file as pm_* under your Stripe account. Leaving means new PaymentMethods and usually a card-update campaign.	acct_* · not portable
Braintree	Vault tokens locked to your Braintree merchant ID. Network-token programs, when offered, still route through Braintree’s enrollment.	merchant_id · not portable
Adyen	Recurring contracts and storedPaymentMethodId references. Multi-PSP routing inside Adyen does not export cards when you leave.	merchantAccount · not portable
Checkout.com	Instruments locked to your entity and processing channel. Moving acquirer means new instrument IDs and full card re-entry.	entity_id · not portable
Worldpay	Tokens and recurring agreements locked to your merchant code (FIS). Exiting means card re-entry, not a credential export.	merchantCode · not portable

Lock-in shows up as card re-entry, revenue disruption, and weaker negotiating leverage.

The mechanics of a PSP-vault migration are well understood by anyone who has run one. Veliro is built so the credential layer never moves, which removes the re-entry, the recovery window, and the renewal leverage problem at the source.

re-entry
Forced card re-entry
When tokens live in the PSP’s vault, leaving means re-collecting card details: opt-in flows, card-update emails, and the drop-off that comes with them. Subscription and card-on-file books are hit hardest.
With Veliro: the credential never leaves your vault, so there is nothing to re-collect
recovery
Revenue disruption
A vault rebuild depresses authorization while BIN routing is re-tuned and card-on-file funnels recover. Cross-border segments recover slowest, and the window is rarely short.
With Veliro: provisioning happened once on the networks · no vault to rebuild
leverage
Negotiation leverage lost
When switching cost is measured in quarters of card re-entry, incumbent PSPs price to retention, not to interchange. A portable credential layer (network token or PAN fallback) changes your leverage in every contract renewal.
With Veliro: a credible exit path is the leverage

Veliro sits above PSPs, on the card networks.

Direct Visa, Mastercard, and Amex network token integration under your own TRID. PSPs become authorization routes you rotate in routing policy, not owners of the credential estate, and the tokenized networks themselves carry the approval and fraud benefits the schemes report (see why network tokens).

Neutral token layer · above PSPs

veliro · credential layer

Network tokens through Veliro lift approvals, cut fraud, and survive every card lifecycle event.

Veliro provisions cards under your own TRID on the Visa, Mastercard, and Amex networks. The approval lift, the fraud reduction, the credential continuity: those are what your traffic gets on every authorization.

2–6pp¹
Authorization uplift
Higher approval rates on eligible tokenized card-on-file and CNP traffic versus raw PAN. The gain compounds across a recurring book.
Scheme & processor benchmarks
4.6%²
Visa CNP approval lift
Global uplift in card-not-present authorization rates for tokenized credentials over non-tokenized PAN, with the gap widest in cross-border.
Visa · tokenized transactions study
up to 3pp³
Mastercard approval lift
First-attempt approvals up on network-tokenized CNP. The first retry is often the one that recovers the sale.
Mastercard · network tokenization
28–34%⁴
Lower fraud
Less fraud on tokenized online transactions than PAN-based ones. A network token is useless outside its bound merchant and channel.
Visa · token service reporting
5–8%⁵
Fewer false declines
Fewer legitimate transactions wrongly declined. Fewer abandoned good customers, every checkout, every retry.
Mastercard · pilot reporting
lifecycle⁶
Credential continuity
Tokens stay valid when the underlying card expires, is reissued, or is reported lost. Your stored credentials survive the events that normally break card-on-file.
Scheme token-service materials

These benefits travel with the credential. Veliro issues your tokens under your own TRID, holds them in your own vault, and keeps them portable across processors, so the upside lands with you on every authorization rather than inside a single PSP’s program. Tokenization reduces the systems that touch a PAN, though it does not by itself remove your PCI obligations.⁷

One `tok_*` per card. Network token where the networks support it, PAN fallback where they do not.

Veliro provisions cards under your Token Requestor ID on the Visa, Mastercard, and Amex networks: you own the credential, not the PSP. Where a BIN or issuer is not yet enabled on the network, the PAN is kept in Veliro’s Level 1 PCI vault under the same tok_* reference, never in a PSP’s vault. At authorization time you send tok_* to the acquirer your policy selects (Stripe for US CIT, Adyen for EU debit, Checkout.com for APAC, Worldpay for UK recurring, Braintree for PayPal-wallet adjacency). Veliro forwards the network token plus cryptogram, or the PAN, depending on what the network supports.

Portability here means credential ownership, not a one-time data export: whether the credential is a network token or a PAN fallback, the vault is yours, the reference is stable, and every PSP receives only what it needs to authorize.

one tok_*per card, stable across every acquirer routenetwork-tokenized where the networks allow · PAN fallback where they do not · same reference either way

Portable credential · same tok_*illustrative · sandbox

Token	Network	Route (policy)	Status
tok_01HK2L9Qm4x	visa · vts	stripe · primary	ACTIVE
tok_01HK2M8Pn2v	mc · mdes	adyen · eu_debit	ACTIVE
tok_01HK2N1Rk8w	amex · aets	braintree · us	ACTIVE
tok_01HK2P4Ts1y	visa · vts	checkout.com · apac	ACTIVE
tok_01HK2Q7Uw3z	mc · mdes	worldpay · uk_recurring	ACTIVE
tok_01HK2R3Vy5x	pan · fallback	adyen · de_no_token	ACTIVE

How merchants move processors with Veliro in the path.

Provisioning happens once on the card networks. Switching PSPs is a new POST /v1/connections plus a connection_id change in your POST /v1/forward calls, not a vault rebuild.

PSP migration · with Veliroillustrative path

week 0Sign new PSP contract · map BIN/MCC routesunchanged
week 1Stand up new PSP vault Create the connection · POST /v1/connectionsone call
week 2Card re-entry sprint Shadow traffic with the new connection_idsame token_id
week 3Customer comms Cut primary route · drain old PSPno comms
week 4Months of funnel recovery Decommission old PSPdone

forward.httpPOST /v1/forward · per request

# PSP cutover: route by picking a different connection_id
POST /v1/forward HTTP/1.1
Host: api.veliro.com
Authorization: Bearer vk_live_4kGp8x…
Idempotency-Key: auth_2024-06-18_9f2a1e

{
  "connection_id": "c0n_adyen-eu", // configured via POST /v1/connections
  "token_id": "d4e5f6a7-b8c9-0123-def0-123456789abc", // same token across PSPs
  "request": { // raw PSP payload, Veliro injects PAN + cryptogram
    "amount": 4200,
    "currency": "EUR"
  }
}

# Switching PSPs = different connection_id. Same token_id.
# Configure routes via POST /v1/connections

Gateway tokenization vs the neutral token layer on a PSP switch.

The dimensions that decide whether you stay in control of your cards. The Veliro column reflects how the platform is architected: network tokens where the networks support them, PAN fallback in Veliro’s Level 1 PCI vault where they do not.

Dimension	PSP gateway tokens	Veliro neutral token layer
Credential lock-in	Locked to PSP account · dies on exit	Your TRID · Visa, Mastercard, Amex network tokens
When the network has no token	PAN locked in PSP vault; same lock-in, no upside	PAN fallback in your Level 1 PCI vault · same tok_*
Worldpay → Checkout.com switch	New token vault · recurring agreements · card re-entry	Same tok_* · routing policy update
Customer comms	Card-update emails · opt-in flows · drop-off on every step	None on credential path
Switch calendar time	Auth recovery · vault rebuild · funnel recovery	Routing change · same tok_* · no vault rebuild
PSP in credential path	PSP sees PAN at enrollment · owns vault	Zero · PSP receives tok_* + cryptogram or PAN at authorization only

Sources & notes

Scheme and processor benchmarks for eligible tokenized CNP and card-on-file traffic. ↩
Visa, “Deep Dive into Tokenized Transactions”: global CNP authorization uplift for tokenized vs non-tokenized credentials. ↩
Mastercard network tokenization materials: approval uplift for first-attempt CNP transactions. ↩
Visa Token Service reporting and Visa Economic Empowerment Institute: reduction in fraud for tokenized vs PAN-based online transactions. ↩
Mastercard network tokenization pilot reporting: reduction in false declines. ↩
Visa, Mastercard, Adyen and PayPal token-service materials: network tokens remain valid across card expiry, reissuance, loss, and compromise where issuer lifecycle updates are supported. ↩
PCI SSC Tokenization Guidelines: tokenization reduces the systems that store or process PAN but does not automatically eliminate PCI DSS obligations. ↩

Stripe · Braintree · Adyen · Checkout.com · Worldpay. None of them in your token path.

Provision cards once on the card networks. Switch PSPs by adding a new connection and changing the connection_id on your POST /v1/forward calls. Spin up a sandbox account and stand up the credential layer against it.