Stored cards that follow you across any PSP.
Veliro is the PSP-independent vault for merchants who need to own card-on-file. Credentials provision under your TRIDToken Requestor ID: your merchant identifier on the card networks, the vault returns one stable tok_*, and the same reference routes across acquirers without re-tokenization.
Scheme-reported outcomes for tokenized credentials
- 4.6%Visa · scheme benchmark
Visa CNP approval lift
Tokenized card-not-present traffic versus non-tokenized PAN on eligible volume.
- 2–6ppScheme & processor benchmarks
Authorization uplift
Higher approval on stored, tokenized credentials across a recurring book.
- 5–8%Mastercard · pilot reporting
Fewer false declines
Fewer legitimate transactions wrongly declined on network-tokenized CNP traffic.
Scheme and processor benchmarks, not Veliro customer measurements. See sourced notes.
What you can verify before signing
- Read network tokens
Direct scheme APIs
Mutual-TLS to VTSVisa Token Service, MDESMastercard Digital Enablement Service, and AETSAmerican Express Token Service under your TRIDToken Requestor ID: your merchant identifier on the card networks
- Read migration guides
PSP migration playbooks
Per-processor cutover guides for Stripe, Adyen, Checkout.com, Braintree, Worldpay, and custom stacks
- Review PCI scope
PCI DSS vault
Tenant-isolated PAN fallback inside Veliro's Level 1 service-provider boundary
Three API calls, one stable reference.
The hero demo above shows the jobs visually. This is the integration surface your team wires: provision once, forward on every charge, subscribe to lifecycle events.
- Provision
POST /v1/tokensSecure Fields JWE in ·
tok_*out · synchronous · idempotent - Authorize
POST /v1/forwardSame
tok_*· swapconnection_id· cryptogram per charge - Lifecycle
webhook · token.updatedSigned HMAC · replayable · issuer reissue without cardholder re-entry
Pick the path that matches your evaluation.
Most vault buyers arrive with one of three questions: how to leave a PSP vault, how to lift authorization on stored cards, or how to cut over without card re-entry.
- Read PSP independence
Leave a PSP-owned vault
Gateway tokens die when the processor contract ends. Provisioning under your TRIDToken Requestor ID: your merchant identifier on the card networks keeps the stored book intact when you renegotiate or switch.
- Read network tokens
Lift authorization on stored cards
Direct VTSVisa Token Service, MDESMastercard Digital Enablement Service, and AETSAmerican Express Token Service connections with the right cryptogram on every charge.
- Plan a migration
Cut over without card re-entry
Per-PSP migration playbooks when credentials already live under your merchant identifier, not inside Stripe or Adyen.
PSP vault vs merchant-owned vault.
When you switch processors, renegotiate rates, or add a backup acquirer, the question is who owns the stored credential. That determines whether the card book survives the change.
| Dimension | PSP vault | Veliro vault |
|---|---|---|
| Credential owner | Gateway token under the processor's account namespace | Your TRID on VTSVisa Token Service, MDESMastercard Digital Enablement Service, and AETSAmerican Express Token Service |
| Switching PSPs | New vault, new token set, customer re-entry risk | Same tok_* · change connection_id only |
| Lifecycle continuity | Updates depend on one PSP program and one vault boundary | Scheme lifecycle updates · signed webhooks |
| Merchant system reference | PSP-specific token such as pm_* | One tok_* per card across acquirers |
| Operational path | Vault, routing, and custody bundled by the processor | Credential custody stays separate from authorization routing |
What is a payment token vault?
A payment token vault stores payment credentials as reusable tokens instead of raw PANs. Veliro returns one stable tok_* reference per card, provisions network tokens under your TRID where the schemes support them, and keeps PAN fallback inside a tenant-isolated Level 1 PCI vault where the networks do not.
How is Veliro different from a PSP vault?
A PSP vault issues gateway tokens that live inside that processor’s namespace. Veliro provisions credentials under your own TRID and keeps the same tok_* across acquirers, so switching PSPs is a routing change rather than a card re-entry project.
Does Veliro support network tokens and lifecycle updates?
Yes. Veliro connects directly to Visa VTS, Mastercard MDES, and American Express AETS, retrieves the right cryptogram per authorization, and absorbs scheme lifecycle updates into signed webhooks so reissues, expiries, and replacements do not break the merchant reference in your system.
How does the vault reduce PCI scope?
Veliro Secure Fields keeps PAN and CVV out of merchant application servers, which narrows the checkout path toward SAQ-A. Tokenization also reduces the number of systems that touch raw card data, while unavoidable PAN fallback remains isolated inside Veliro’s Level 1 PCI vault.
Can we migrate off Stripe, Adyen, or Worldpay without re-collecting cards?
Veliro keeps the credential layer outside the PSP, so adding or dropping Stripe, Adyen, Worldpay, Checkout.com, or another processor becomes a connection_id change on the forward path instead of a stored-card rebuild.
What payment methods does the vault cover?
Veliro is built for stored card credentials across Visa, Mastercard, and American Express. Where the schemes support network tokenization, the credential is provisioned as a network token under your TRID; where they do not, the same tok_* resolves to PAN fallback inside the vault so your application still handles one reference.
Put stored credentials in a vault you can leave with.
Start in sandbox, map a migration, or read the architecture. The outcome is the same: one merchant-owned credential layer above any PSP you choose.