connection type worldpay
Veliro + Worldpay
Enterprise acquirer routing with Veliro tok_*. Register Worldpay merchant codes as connections and forward without re-enrolling cards.
Worldpay (FIS) serves large merchants and regulated verticals with direct acquirer relationships. Enterprise contracts often span years, exactly when PSP lock-in hurts most if your entire credential file lives in Worldpay’s token vault.
Veliro registers Worldpay with connection type worldpay and merchant code credentials, then forwards authorizations with network tokens and cryptograms Worldpay’s ISO interfaces expect. Your TRID stays on the scheme enrollment; Worldpay is the route, not the custodian.
Enterprises frequently keep Worldpay for specific MCCs or geographies while using Adyen or Stripe elsewhere. Veliro makes that a routing table on connection_id rather than multiple incompatible token namespaces in your database.
Worldpay integrations historically required heavy ISO and file-based reconciliation; Veliro’s REST forward layer abstracts that for application teams while leaving settlement reporting on the acquirer relationship you already operate.
Setup
Obtain merchant code
Work with your Worldpay relationship manager for the merchant code used in authorization messages. Register via POST /v1/connections with type worldpay.
Validate BIN coverage
Some Worldpay routes accept network tokens only on eligible BIN ranges; PAN fallback under the same tok_* covers gaps until scheme tokenization lands.
Coordinate cutover windows
Enterprise migrations use weighted forward traffic between old and new connection_id values, tok_* stays constant across the window.
Forward & portability notes
- Worldpay maintenance windows may affect forward latency; implement retries with fresh cryptograms, not stale payloads.
- Keep acquirer reconciliation files separate from Veliro token lifecycle logs: different teams, different SLAs.
- Custom ISO fields may be required for certain verticals; use connection metadata fields documented in the Connections API.