connection type stripe
Veliro + Stripe
Forward Veliro network tokens and cryptograms to Stripe without storing cards in Stripe’s vault. Same tok_* when you add or leave Stripe.
Stripe is a common first acquirer for product-led merchants, and a common source of credential lock-in. Stripe-issued payment method IDs (pm_*) live inside Stripe’s namespace. They work beautifully on Stripe rails, but they do not travel when you negotiate a backup processor or migrate to Adyen for European coverage.
Veliro provisions network tokens under your TRID (or holds PAN in tenant-isolated vault fallback) and returns a processor-neutral tok_*. You register Stripe once as a connection with type stripe and your secret key, then authorize with POST /v1/forward. Stripe receives the token surrogate, cryptogram, and ECI your issuer expects, without re-tokenizing into pm_*.
Teams already on Stripe often run a parallel path: new checkouts provision tok_* via Veliro Secure Fields while legacy pm_* references age out. PSP cutover becomes swapping connection_id on forward calls, not a card-on-file rebuild. Stripe-specific Radar and Billing features still work on the authorization you forward; Veliro does not replace Stripe’s risk or subscription SKUs, it decouples custody from routing.
Sandbox uses the same forward contract with test keys. Validate cryptogram freshness on each charge before blaming Stripe decline codes; many “card declined” tickets are stale TAVV/UCAF payloads, not Stripe configuration.
Setup
Create a Stripe connection
POST /v1/connections with type stripe and your sk_test_* or sk_live_* secret. Veliro stores credentials encrypted per tenant. Name the connection for the market or entity it represents.
Provision tok_* at checkout
Capture with Secure Fields, then POST /v1/tokens. Persist the returned tok_* on your customer record, not pm_* from a parallel Stripe Elements flow if portability is the goal.
Forward authorizations
POST /v1/forward with token_id, connection_id, amount, and currency. Fetch a fresh cryptogram immediately before forward for network-token charges.
Forward & portability notes
- Stripe Connect platforms should map each sub-merchant to its own Veliro merchant_id and TRID; connection credentials may be per connected account.
- When leaving Stripe, disable the connection, not delete tokens. tok_* remains valid on the next acquirer.
- See Connections API docs for error shapes when Stripe returns card errors through the forward proxy.