Use a computer

For full performance and fluidity, please open Pay Engineers on a desktop or laptop. On mobile, the experience is limited — especially authenticated sections and advanced tools after login.

Pay Engineers Pay Engineers
Anmelden
Sprache
Startseite
Individueller Prozessor Maßgeschneiderte Zahlungsinfrastruktur Konfigurator Prozessor-Setup gestalten Stripe-Arbeitsbereich Verbundene Stripe-Operationen Compliance Zulassungen & Lizenzen
Alle Leistungen Engineering- & Beratungsangebote Prozessor beauftragen Individuelles Projekt starten Beschwerde einreichen Beschwerde- & Claims-Service
Prozessor-Leitfäden Architektur & Best Practices API-Dokumentation (opens in a new tab) Entwicklerdokumentation Blog Product & engineering notes
Über uns Who we are Kontakt Talk to our team
Create an account

Advisory & Delivery

Acquirer / PSP Migration

Switch rails without downtime

Presentation

Overview

Migrating between acquirers or payment service providers is one of the highest-risk operations a payments business can undertake, precisely because it touches live revenue: every transaction, every stored card token and every merchant relationship depends on the migration going smoothly, with no acceptable margin for extended downtime or lost recurring billing capability.

Pay Engineers plans and executes these migrations using dual-running architecture as the default approach: both the old and new acquiring relationships operate in parallel for a defined period, with traffic shifted gradually and reversibly, rather than a single high-risk cutover event with no safe path back if something goes wrong.

We treat the migration of stored payment tokens as a first-class workstream in its own right, since losing the ability to charge stored cards is one of the most damaging and hardest-to-reverse mistakes a migration can make, directly threatening recurring revenue.

Who This Is For

  • Businesses switching acquirers or PSPs due to pricing, service quality or capability limitations with their current partner
  • Companies consolidating multiple acquiring relationships into fewer, better-negotiated partnerships
  • Platforms whose current acquirer cannot support new markets, currencies or payment methods they need
  • Any business for whom transaction downtime during a switch would be commercially unacceptable

What You Get

  • A dual-run strategy allowing both acquiring relationships to operate simultaneously during a controlled transition window
  • A token portability plan ensuring stored card credentials remain usable for recurring billing after the switch
  • A cutover runbook detailing every step, responsible party and rollback trigger for the migration day itself
  • Post-go-live hypercare support to catch and resolve any issues quickly in the days immediately following cutover

Technical Approach

Smart routing infrastructure is put in place to direct traffic between the old and new acquiring connections according to configurable rules, allowing you to shift volume gradually, by merchant segment, transaction type or percentage, rather than an irreversible all-or-nothing switch. This same routing layer provides the rollback mechanism if unexpected issues appear during migration.

Token migration is handled through the appropriate network token or account updater mechanisms available from your schemes and acquirers, since directly transferring raw card data between acquirers is rarely permitted or advisable. Where full token portability is not available, we design a re-tokenisation strategy that minimises customer disruption during the next natural payment attempt. Feature flags control which merchants or transaction flows are routed through the new acquirer at any given time, giving granular control over the pace of migration.

Delivery Process

  • Discovery of your current and target acquiring relationships, contractual constraints and technical differences between them
  • Dual-run architecture and token migration strategy design, reviewed against your specific token volumes and recurring billing patterns
  • Build and testing of routing infrastructure and token migration mechanisms in a staging environment
  • Cutover runbook rehearsal, including simulated rollback scenarios, before the live migration window
  • Phased live migration with hypercare support and close monitoring of authorisation rates throughout

Outcomes and Benefits

  • A migration completed with no meaningful transaction downtime and no lost recurring billing capability
  • A reversible, staged transition that removes the all-or-nothing risk of a single cutover event
  • Merchants and customers who experience the migration as a non-event rather than a disruption
  • A documented playbook your team can reuse for future acquirer or PSP changes

Technologies

Smart routing Token migration Feature flags

FAQ

Yes, zero-downtime migration is the standard approach we design for, typically using a parallel-run strategy where the new acquirer connection is built and tested alongside your existing one, with traffic shifted gradually rather than through a single cutover event. This lets you validate authorisation rates, settlement behaviour and reporting accuracy on the new acquirer with a small percentage of real traffic before committing fully. We plan explicit rollback procedures at every stage, so if an issue is discovered during the gradual shift, traffic can be routed back to the original acquirer without customer impact. This phased approach is significantly safer than a hard cutover, even though it takes somewhat longer.
We assess your current integration points, such as checkout SDKs, server-side API calls, webhook consumers and reconciliation processes, and build an abstraction or routing layer where one does not already exist, so switching or adding acquirers becomes a configuration change rather than requiring every downstream system to be individually reworked. Where your systems are tightly coupled to acquirer-specific API responses or identifiers, we handle the translation so your application logic does not need to change. This investment in an abstraction layer pays off beyond the immediate migration, since it makes any future acquirer changes considerably faster. We scope the level of abstraction to your realistic future needs rather than over-engineering for hypothetical scenarios.
We map transaction identifiers, statuses and historical data between the old and new acquirer's data models before migration begins, ensuring your reporting, reconciliation and customer support tools continue to function correctly for transactions that occurred before, during and after the cutover. Historical transaction data from the outgoing acquirer is preserved and remains queryable, since disputes, refunds and chargebacks on old transactions can arise well after the migration completes. We run reconciliation checks specifically comparing pre- and post-migration data continuity as a formal verification step before declaring the migration complete. This attention to historical continuity is often overlooked in acquirer migrations and is a common source of post-migration support issues when it is not handled properly.
We work through the new acquirer's required integration testing and certification process, which typically covers authorisation flows, 3-D Secure handling, refunds, and settlement file validation, and we build a dedicated test plan covering your specific transaction types and edge cases rather than relying solely on the acquirer's generic test suite. Certification timelines vary by acquirer and are factored into the overall migration schedule from the outset. We also validate settlement and reconciliation file formats against your existing finance processes before go-live, since a functionally correct integration that produces unreconcilable settlement data is still a significant operational problem. This thorough testing phase is what makes the subsequent live migration low-risk.
A typical migration takes 3 to 5 months from kickoff to full cutover, covering integration build, certification testing, a gradual traffic shift period, and a stabilisation window before decommissioning the old connection entirely. Timeline depends on the complexity of your existing integrations, the number of payment methods and currencies involved, and the new acquirer's own certification process speed. We recommend not decommissioning the old acquirer relationship until the new one has processed a full billing and settlement cycle successfully, to ensure no timing-related issues surface only at month-end. This conservative approach to decommissioning has repeatedly prevented issues that would otherwise only appear during the first full reconciliation cycle.

Similar services

Payment Architecture Audit

An independent, deep-dive review of your payment stack covering architecture quality, partner dependencies, security posture and scalability constraints. We deliver a clear findings report, a prioritised risk register and a concrete ninety-day remediation roadmap that your engineering team can act on immediately. This is the diligence work investors, acquirers and boards expect before major capital or strategic decisions.

Managed Payment Evolution

An ongoing, SLA-backed partnership providing engineering capacity, monitoring and regulatory change management for your live payment platform. As card scheme mandates, SCA rules and partner APIs evolve, we keep your systems compliant and production-ready without you needing to staff a full internal team for every change. A shared backlog and quarterly architecture review keep the relationship transparent and outcome-focused.