Stored cards become network tokens under your TRIDToken Requestor ID: your merchant identifier on the card networks.
Veliro provisions credentials directly with Visa, Mastercard, and Amex, returns a single stable tok_* your application keeps, and absorbs scheme lifecycle events into signed webhooks. Adding, dropping, or rotating PSPs is a routing change in your policy.
MDESMastercard Digital Enablement Service · VTSVisa Token Service · AETSAmerican Express Token Service · tenant-isolated vault · built to PCI DSS Level 1
- Your reference
- One
tok_*per card, stable in your database - Network enrollment
- Credentials under your TRIDToken Requestor ID: your merchant identifier on the card networks on MDESMastercard Digital Enablement Service, VTSVisa Token Service, and AETSAmerican Express Token Service
- PSP routing
- Swap
connection_idwithout re-keying or cardholder re-entry
Gateway tokens, network tokens, and Veliro's tok_* are three different things in one card-on-file conversation.
Each type lives somewhere different, is bound to a different identifier, and behaves differently when you change PSP. Portability starts when your application holds a reference the PSP did not mint.
| Dimension | PSP gateway token | Network token | Veliro tok_* |
|---|---|---|---|
| Issued by | PSP vault (pm_*, storedPaymentMethodId, etc.) | VTSVisa Token Service, MDESMastercard Digital Enablement Service, or AETSAmerican Express Token Service | Veliro maps to a network token or PANPrimary Account Number: the raw card number fallback under the same reference |
| Bound to | acct_* · merchantAccount · entity_id | Merchant TRIDToken Requestor ID: your merchant identifier on the card networks on the scheme | Your TRID · your tenant vault |
| Portable across PSPs | No · dies when you leave the PSP account | Yes, when you control enrollment and routing (not via PSP program alone) | Yes · same reference on every acquirer route |
| Lifecycle updates | Manual card-update flows · PSP-dependent account updater | Scheme-driven reissue, expiry, and replacement where issuer supports it | Scheme updates + signed webhooks to your systems |
| At authorization | Gateway token scoped to one PSP integration | Token + per-transaction cryptogram (TAVVToken Authentication Verification Value (Visa cryptogram) / UCAFUniversal Cardholder Authentication Field (Mastercard cryptogram) / AEVVAmerican Express Verification Value) | tok_* + cryptogram or PAN via POST /v1/forward |
Veliro's tok_* is the stable handle your application stores. Under the hood it may resolve to a Visa, Mastercard, or Amex network token, or to a PANPrimary Account Number: the raw card numberin Veliro's Level 1 PCI vault when the issuer is not yet network-token-enabled. Either way the reference in your database does not change when you add Adyen, drop Stripe, or renegotiate Worldpay.
The Token Requestor ID belongs to you, not your PSP.
Network tokens are enrolled under a Token Requestor ID on VTSVisa Token Service, MDESMastercard Digital Enablement Service, and AETSAmerican Express Token Service. When that ID is yours, the credential estate is contractually and architecturally separate from any acquirer relationship.
Veliro provisions and lifecycle-manages credentials under your TRIDToken Requestor ID: your merchant identifier on the card networks. PSPs receive only what they need to authorize: tok_* plus cryptogram, or PAN where the network has no token yet. They never own the stored-card book.
Cross-PSP routing keeps the same tok_*; only the connection_id changes.
Your application keeps the same token_id through every cutover, backup acquirer, or geographic split. Veliro forwards the credential shape each PSP needs at authorization time, and routing decisions stay where they belong: in your policy.
At authorization time you call POST /v1/forward with a connection_id for Stripe, Adyen, Checkout.com, Braintree, or Worldpay. The tok_* in the request body does not change when you cut over traffic or add a backup acquirer.
PSP independence covers lock-in mechanics, migration timelines, and the full processor comparison. This page stays on the credential model; the switch playbook lives there.
Read PSP independence
Gateway lock-in, neutral token layer, and what a Worldpay → Checkout.com cutover looks like with Veliro in the path.
Lifecycle events update the network token under a stable tok_*.
Issuer reissue, expiry, and replacement propagate into the token record at the scheme. Veliro surfaces each as a signed webhook so your billing stack updates without asking the cardholder to re-enter a PAN.
What your systems receive when the issuer moves.
Veliro signs lifecycle payloads with HMAC-SHA256. Deliveries are replayable per event, and subscriptions can filter by type or use a wildcard. Your subscription billing service updates the credential metadata it already holds for tok_*; it does not issue card-update emails because the PAN path never broke.
How PSP-vault storage compares to a merchant-owned credential layer.
The four dimensions that decide whether your credentials outlive any single acquirer contract: who is the token requestor, what travels across PSPs, what handles lifecycle events, and what stays stable in your database.
| Dimension | PSP gateway vault | Veliro portable layer |
|---|---|---|
| TRID ownership | PSP is token requestor · merchant ID is the PSP's | Your TRID on VTSVisa Token Service, MDESMastercard Digital Enablement Service, AETSAmerican Express Token Service |
| Cross-PSP use | New vault per PSP · new gateway token per account | Same tok_* · connection_id swap only |
| Lifecycle continuity | Card-update campaigns · manual re-entry on failure | Scheme-driven updates · signed webhooks |
| Reference stability | pm_* changes when you switch PSP | One tok_* per card · network or PAN fallback |
Provision your credentials once on the card networks, route them anywhere, keep the same tok_*.
Stand up a sandbox key and provision your first credential in under ten minutes. If you are planning a PSP switch, we can map portability without a single cardholder re-entry.