Migrate off Worldpay

Leave Worldpay enterprise contracts without re-enrolling cards

Enterprise Worldpay token vaults tie credentials to multi-year deals. Veliro tok_* under your TRID let you add Stripe or Adyen, or exit Worldpay, without a card-on-file migration program.

Worldpay (FIS) underpins large merchants with direct acquirer relationships and ISO-heavy integrations. Token vaults in those contracts are optimized for retention: leaving at renewal historically meant re-collecting cards or paying migration services.

Veliro inverts the model: scheme tokens live under your TRID; Worldpay is connection type worldpay with merchant code credentials on POST /v1/forward. Adding Checkout.com for a pilot market or shifting US volume to Stripe is a routing table change, not a vault export.

Enterprise cutovers run over quarters with weighted traffic. Finance and ops need approval-rate parity reports by cohort; Veliro’s stable tok_* makes before/after comparisons meaningful because the credential, not the customer, stays constant.

ISO reconciliation and settlement files stay on the acquirer relationship you operate. Veliro does not replace Worldpay reporting; it removes Worldpay as the only place your card file can live.

Migration phases

  1. Align stakeholders on custody vs routing

    Procurement, finance, and engineering agree: TRID-owned tokens are the target state; Worldpay is a route until contract strategy says otherwise.

  2. Register Worldpay and successor connections

    Mirror existing merchant codes as Veliro connections. Add successor PSP connections in parallel, sandbox first.

  3. Shadow forward sample traffic

    Forward a percentage of charges to the new connection_id while production default remains Worldpay. Compare approval and interchange categories.

  4. Contract-window cutover

    Time full default routing shift to renewal leverage or outage remediation plans. tok_* avoids emergency re-collection if Worldpay has an incident.

  5. Retain Worldpay only where economics win

    Some MCCs or geographies may stay on Worldpay intentionally; multiple connection_id values on one tok_* estate is normal.

Common pitfalls

  • Underestimating ISO field differences between Worldpay and a modern REST PSP adapter.
  • Big-bang cutover before two billing cycles of shadow metrics.
  • Letting custom ISO passthrough requirements block cryptogram forwarding; document fields in connection metadata.

Plan your Worldpay cutover.

Same tok_* on the next acquirer, no card re-collection campaign. Talk to us about cohort sizing and sandbox forward tests.