Four routes into one credential layer.
Read the credential model, plan a migration off PSP-vault tokens, wire agent-scoped tokens for delegated checkout, or integrate from a clean repo. Each path lands on the same outcome: cards provisioned under your TRIDToken Requestor ID: your merchant identifier on the card networks and a single tok_* your application keeps at authorization time.
Pick the route that matches your starting point.
If you need the credential model first, start with Token portability. If you have a stored-card book locked in a PSP vault, read PSP independence. If you are issuing credentials to shopping agents, read Agentic commerce. If you are integrating from a clean repo, start with How it works.
TRID ownership and portable tok_*
Three token shapes (gateway, scheme, Veliro tok_*) and what they mean for cross-PSP use, lifecycle updates, and a stable reference in your database.
Switch PSPs without re-collecting cards
Network tokens under your merchant identifier, with PAN fallback in your Level 1 PCI vault where the networks do not tokenize yet. Changing Stripe → Adyen or adding Worldpay is a connection_id update, not a card-on-file rebuild.
Agent-scoped credentials, in development
We are extending the Veliro token layer so a credential can be delegated to an AI agent under your own TRID, owned by you rather than the agent platform. Register interest for early access.
Provision your first network token
Secure Fields at the edge, vault custody, direct MDESMastercard Digital Enablement Service / VTSVisa Token Service / AETSAmerican Express Token Service provisioning, and signed lifecycle webhooks on the way out. Same REST contract from sandbox to production; no separate integration surface between environments.
Spin up a sandbox key from any starting point.
First credential on the wire in under ten minutes. If you are planning a PSP switch, we can map the migration without asking a single customer to re-add a card.