Integrations

Authorize with any PSP.Keep every card when you switch.

Configure a route once, forward at authorization with the same tok_*, and change processor by swapping a connection_id. Where a network can't yet tokenize a card, the PAN sits in your own vault under that same reference, so portability holds on every acquirer either way.

Start in sandboxSee a PSP cutover

Forward path: any PSP via POST /v1/forward to a stable tok_* reference. Backing: MDES, VTS, AETS, or PAN vault under the same reference.

ForwardAny PSP you configurePOST /v1/forward
  • Stripe
  • Adyen
  • Checkout.com
  • Braintree
  • Worldpay
  • Custom
Your credentialtok_*

Stable on every acquirer. Swap processor by changing connection_id only.

Backed for you

MDESMastercard Digital Enablement Service, VTSVisa Token Service, and AETSAmerican Express Token Service on one API surface, with PANPrimary Account Number: the raw card number fallback in Veliro's vault when a scheme cannot tokenize a card yet.

  • VTS
  • MDES
  • AETS
  • PAN vault
Any acquirer · one connection_idPAN fallback in your vaultSame tok_* across PSPsBuilt to PCI DSS Level 1

Authorize with the processor you already use, and the next one too.

Connection types map to the acquirers merchants run today. Veliro forwards the authorization request and keeps cards out of PSP vaults. Your credential reference lives on Veliro. Gateway tokens scoped to acct_* stay with the processor you route through, and you can add or swap that route without touching the card file.

At a glance: forward with POST /v1/forward to Stripe, Adyen, Checkout.com, Braintree, Worldpay, or a custom HTTPS endpoint. Register each route once with POST /v1/connections and its credentials.

Define a route: POST /v1/connections registers a PSP with its credentials. Route a charge: POST /v1/forward sends the token and, where one exists, the cryptogram to that connection. The token_id in the body does not change when the route does.

PSP and acquirer connection types supported via POST /v1/connections and POST /v1/forward
IntegrationInterfaceCredentialsDocs
Stripeconnection type stripe · forward at authorizationPOST /v1/forwardStripe secret keyConnections API (opens in new tab)
Adyenconnection type adyen · entity-scoped routesPOST /v1/forwardAPI key + entity IDConnections API (opens in new tab)
Checkout.comconnection type checkoutPOST /v1/forwardSecret keyConnections API (opens in new tab)
Braintreeconnection type braintreePOST /v1/forwardMerchant ID + keysConnections API (opens in new tab)
Worldpayconnection type worldpayPOST /v1/forwardMerchant codeConnections API (opens in new tab)
Custom acquirerconnection type custom · your HTTP endpointPOST /v1/forwardYour HTTPS endpointConnections API (opens in new tab)

Network token where the scheme has one. PAN where it doesn't.

Portability can't depend on every BIN being tokenizable. Veliro provisions a network token under your TRIDToken Requestor ID: your merchant identifier on the card networkswhere the scheme supports the card, and holds the PAN in its own Level 1 PCI vault where it can't, under one stable reference. Any PSP authorizes against it.

Network token

scheme supports the BIN

Scheme-issued token under your TRID plus a per-transaction cryptogram, with the authorization uplift the networks publish.

PAN fallback

BIN not yet tokenizable

PAN held in Veliro's own Level 1 PCI vault under the same reference, outside any processor vault. Upgrades to a network token automatically when coverage lands.

Either waytok_* stays stable · any PSP authorizes

Own the token and its PAN fallback in Veliro. A PSP switch is a new connection_id on the same tok_* reference, not a vault migration.

Edge capture and lifecycle delivery.

Card data enters as JWEJSON Web Encryption: encrypted JSON envelope from Secure Fields, keeping your application SAQ-APCI SAQ-A: card data never touches merchant servers eligible. State changes exit as HMACHash-based Message Authentication Code: signed integrity proof-signed webhook deliveries with per-event replay. Both surfaces share the sandbox contract.

Secure Fields SDK platforms and lifecycle webhook integration
IntegrationInterfaceStatusDocs
Secure Fields · WebHosted fields · JWEJSON Web Encryption: encrypted JSON envelope to api.veliro.com · SAQ-APCI SAQ-A: card data never touches merchant servers eligiblepk_* publishable keyAvailable in sandboxSDK reference (opens in new tab)
Secure Fields · iOSNative capture · same contract as webpk_* publishable keyNative SDK · in buildSDK reference (opens in new tab)
Secure Fields · AndroidNative capture · same contract as webpk_* publishable keyNative SDK · in buildSDK reference (opens in new tab)
Lifecycle webhooks12 event types + wildcard · HMACHash-based Message Authentication Code: signed integrity proof-SHA256 signedVeliro-Signature headerAvailable in sandboxWebhooks API (opens in new tab)

Secure Fields · Web

Detail
Hosted fields · JWEJSON Web Encryption: encrypted JSON envelope to api.veliro.com · SAQ-APCI SAQ-A: card data never touches merchant servers eligible
Interface
pk_* publishable key
Status
Available in sandbox
Docs
SDK reference (opens in new tab)

Secure Fields · Android

Detail
Native capture · same contract as web
Interface
pk_* publishable key
Status
Native SDK · in build
Docs
SDK reference (opens in new tab)

Lifecycle webhooks

Detail
12 event types + wildcard · HMACHash-based Message Authentication Code: signed integrity proof-SHA256 signed
Interface
Veliro-Signature header
Status
Available in sandbox
Docs
Webhooks API (opens in new tab)

The scheme programs behind it, managed for you.

Veliro holds the direct, mutual-TLS connections to each network token service and carries the certification and compliance standing. Sandbox exercises network-token simulation today; production scheme certification is in progress per program below. Your integration work stops at Veliro's API.

Scheme program reference (MDES, VTS, AETS)

Sandbox network-token simulation is live for all three programs today. Production scheme certification is in progress on the same timeline for each; your integration stops at Veliro's API either way.

Card network token services Veliro integrates with directly: Visa VTS, Mastercard MDES, and American Express AETS
IntegrationInterfaceStatusDocs
Visa Token ServiceVTSVisa Token Service · TAVVToken Authentication Verification Value (Visa cryptogram) cryptograms · ECIElectronic Commerce Indicator on authorizationMutual TLS · directProd cert in progressToken API (opens in new tab)
Mastercard Digital Enablement ServiceMDESMastercard Digital Enablement Service · UCAFUniversal Cardholder Authentication Field (Mastercard cryptogram) cryptogramsMutual TLS · directProd cert in progressCryptogram API (opens in new tab)
American Express Token ServiceAETSAmerican Express Token Service · AEVVAmerican Express Verification Value cryptogramsMutual TLS · directProd cert in progressCryptogram API (opens in new tab)

One REST contract from sandbox to production.

OpenAPI-specified JSON over HTTPS. Idempotency on every mutation. The same endpoints, error shapes, and rate-limit headers in both environments; only the key prefix and network backing change at go-live.

Publishable keys (pk_test_* / pk_live_*) stay in the browser for Secure Fields. Merchant keys (vk_test_* / vk_live_*) sign server-side calls for tokens, connections, forwarding, and webhooks.

Card payloads are JWE-encrypted to the public key from /.well-known/jwks.json. Scheme is derived from BIN at provision time. Responses carry X-Request-Id for support correlation.

Open the API reference → (opens in new tab)

Route your first PSP in sandbox.

First credential on the wire in under ten minutes. Follow the Secure Fields quickstart (opens in new tab), configure a connection, forward a charge, and watch the same tok_* authorize against simulated networks and PAN fallback alike.

Start in sandboxContact sales