Payment consolidation after a merger

Payment consolidation after a merger: why it is different from a normal processor change

Payment consolidation after a merger is a phased migration of stored tokens, routing rules and reconciliation from two payment stacks onto one orchestrator. The short answer is that a self-hosted Hyperswitch deployment can sit in front of both legacy stacks at once, so checkout and routing can be unified while each acquired processor contract, vault and settlement path is moved on its own timetable. The deadline usually comes from integration plans and reporting obligations, not from the processors, which means the sequence has to be planned backward from what the finance and compliance teams must be able to show.

An ordinary processor change moves one merchant's traffic from one gateway to another, under one legal entity and one set of controls. A merger adds three things. First, the acquirer's staff, and sometimes the acquirer's own tooling, may need access to the target's vault, routing configuration or transaction data, and under EU rules remote access from a non-EEA country counts as a transfer that needs a Chapter V transfer tool. Second, transactions and tokens now belong to more than one legal entity, so routing rules, data processing records and processor contracts must be kept separate by entity. Third, the SEC allows management to exclude a newly acquired business from its internal control assessment for no more than one year from the acquisition date, and the exclusion must be disclosed, so the target's payment controls and IT general controls need evidence collected from day one. Confirm with your auditors and legal counsel which of these apply to your deal.

Start with three decisions: which vault holds the tokens after cutover, which entity owns each route, and who in each organization can read the reconciliation output. In a Hyperswitch deployment, the vault model determines whether PAN data is re-tokenized or migrated, and the Control Center supports single sign-on through OpenID Connect only, with roles managed inside Hyperswitch rather than mapped from the identity provider. Confirm those constraints with your identity team before the access model is designed, because acquired staff often arrive with different directories and no shared roles. Ask any implementation partner for a written list of the entity, vault and access decisions, and for the evidence each phase will produce.

Which rules shape a merged payment stack and what each means for the build

This table maps the regulatory and card-scheme rules that apply when two companies combine processor contracts and checkout flows, and states what each rule means for the orchestration build. Read each row as a requirement, the source that sets it, and the design choice it forces. Rules that apply depend on whether the company is an SEC registrant, an EU entity, a US financial institution or a card-accepting merchant, so confirm applicability with counsel and your assessor before scoping.

Rule or requirement	What it asks for	Build consequence
SEC ICFR acquisition exclusion	Management may exclude an acquired business from its internal control assessment for a limited period, with the exclusion and its significance disclosed (SEC ICFR FAQ, Question 3)	Map the acquired processor accounts, ledgers and reconciliation feeds early so the excluded scope and its significance can be stated accurately
SEC IT general control areas	Program development, program changes, computer operations and access to programs and data are example IT general control areas (SEC Release 33-8810)	Put routing rule changes under change control, restrict who can edit connectors and routing, and keep operations logs for both legacy and merged environments
Form 8-K Item 1.05 and third-party oversight	Registrants file Item 1.05 for a material cybersecurity incident, generally within four business days of a materiality determination, and describe oversight of third-party providers (17 CFR 229.106)	Log processor and vault incidents with timestamps that support a materiality decision, and keep a current list of processors in each route
DORA Article 28 register and exit plans	EU financial entities keep a register of ICT arrangements and tested exit strategies for critical or important functions (Regulation (EU) 2022/2554, Article 28)	Record each processor and vault in the register, and build a tested path to move routes and stored tokens to another provider
NIS2 change notification	Covered entities give their competent authority contact details, sector and service countries, and report changes without delay and within two weeks (Directive (EU) 2022/2555, Article 3(4))	Confirm whether the merged entity changes name, contacts, IP ranges or service countries, and assign an owner to file each change
GDPR Article 28 and EDPB 05/2021 for non-EEA acquirer access	Processors act only on documented instructions, including for transfers, and remote access from a third country to EU personal data is a transfer needing a Chapter V tool (GDPR Article 28(3)(a); EDPB Guidelines 05/2021)	Restrict acquirer staff access to EU payer data through role-based controls, document transfer instructions, and block console access from outside approved regions unless a transfer tool covers it
PCI DSS validation responsibility	Payment brands, not the PCI SSC, decide which entities must validate, and validation is documented on official PCI SSC templates with an Attestation of Compliance (PCI SSC FAQs 1004 and 1220)	Confirm with each acquiring bank and brand which entity validates for the merged stack, and separate cardholder data environments until that answer is settled
FTC Safeguards Rule controls	Covered financial institutions encrypt customer information in transit and at rest, require multi-factor authentication for system access, follow change management, and log authorized user activity (16 CFR 314.4)	Enforce MFA for every operator of the orchestrator and vault, encrypt merged data stores, route all config changes through approvals, and retain access logs
SEC Rule 17a-4 record retention	Broker-dealers preserve certain records, including bills receivable or payable and bank statements, for at least three years, the first two in an easily accessible place (17 CFR 240.17a-4)	Where it applies, keep settlement and statement records from both legacy processors readable and retrievable during and after the migration

How the merger structure changes the consolidation path

When the acquirer keeps both legal entities transacting for a period, the orchestrator becomes the place where two merchant identities coexist. Each entity keeps its own processor merchant IDs, settlement accounts and descriptors, and the routing rules must send each payment to the correct entity's connectors. Tokens usually stay in the vault that issued them during this phase, so the main work is mapping entity identifiers into the orchestrator and proving that no payment can cross entities by mistake.

Entity-keyed routing: Set routing rules per merchant account and test that a payment from one entity can never fall through to the other entity's connectors.
Token location: Decide whether stored tokens remain in the original vault during this phase or move early. Moving early adds migration risk while both entities are still in use.
Contract ownership: Confirm which entity signs and holds each processor contract, and whether the acquirer can add the target's processors under its own agreements.
Reconciliation by entity: Settle and reconcile each entity separately, so that payouts and chargebacks map to the right ledger.
Exit criteria: Define in writing when the second entity stops accepting new transactions.

Ask the implementation partner to show the routing configuration for both entities and the test cases that prove cross-entity isolation before any live traffic moves.

Which open-source options fit a merged payment stack, and why Hyperswitch leads

A merger rarely ends with one processor contract, one checkout and one ledger. The cards below cover the components that usually decide whether two payment stacks can be combined behind one orchestrator, and what to confirm before each choice is locked in.

Hyperswitch as the routing layer

Hyperswitch is the orchestration and routing layer in this design. It is open source under Apache 2.0, connects to more than 100 payment processors including Stripe, Adyen, PayPal, Worldpay and Checkout.com, and supports retries and routing rules that can be set per entity while both legacy gateways stay live during the switchover. Confirm that every processor and payment method in both companies' markets has a connector before you commit, because a missing connector turns a routing rule into a manual workaround.

Three vault models

The card vault decides where stored card data lives, and it is a platform decision rather than a routing detail. Hyperswitch documents an in-house PCI vault, an external PCI vault provider such as VGS or Tokenex, and the SaaS Hyperswitch Vault. In the in-house model, the merchant is fully responsible for PCI DSS certification and data handling. Agree the vault model with both companies' PCI assessors before any stored token moves.

Kill Bill for merged subscriptions

Kill Bill is an open source subscription billing and payments platform under Apache 2.0. It fits where the acquired company runs recurring plans that must be carried over with their billing cycles, proration and invoices intact. Pairing it with Hyperswitch separates plan logic from payment routing, so a card token can move to a new processor without rewriting subscription records. Check whether the acquired business actually bills on recurring plans before adding this component, since one-off checkout merges do not need it.

Odoo or ERPNext for ledger inputs

Odoo (LGPL v3 core with Enterprise editions) and ERPNext (GPL-3.0) can hold the general ledger that payment settlements post into. In a merger, the practical value is a single chart of accounts and clean settlement journals that reconcile against processor payout files from both companies. Confirm how each candidate ERP maps settlement, fee and chargeback entries, and whether the two entities can run separate books during the transition, since that choice drives the reconciliation effort.

The vault choice is a platform decision

Whether the combined company keeps one vault, moves tokens into a new vault or uses a third-party PCI vault is settled before any tool is selected. This choice sets PCI DSS scope, the cost of moving stored cards, and which party must hold the keys. Treat it as a board-level platform decision with input from security, legal and the processors that issue the tokens. Ask each processor whether its network tokens can be migrated and under what terms.

A phased switchover from two stacks to one orchestrator

The sequence moves two companies' processor contracts, stored tokens and checkout flows onto one Hyperswitch layer in controlled stages, with a documented output and evidence check at each step so that no market moves to the new path before its data and routing are proven.

Inventory both processor contracts and token stores
Finance, payments operations and legal map every processor, acquirer and vault contract on both sides, including term end dates, supported card brands and payment methods per market, and which entity signed each agreement. In parallel, engineering inventories every stored token set, its vault, its format and the checkout flows that create or use it. The output is a single register of processors, token populations and the owner of each contract. The step is done when both sides agree the register matches the live configuration, and when the team can state which tokens cannot leave their current vault without the processor's cooperation.
Build and connect Hyperswitch in a non-production environment
The platform team deploys Hyperswitch in a non-production environment inside the infrastructure the combined company controls, using the Helm-based self-hosting path, and configures connectors for each processor in the inventory. The team sets up merchant accounts per legal entity in the Control Center and tests authorization, capture, refund and webhook flows against processor sandboxes. The output is a working test environment with a connector matrix. The step is done when every connector passes the agreed test cases and the environment's configuration is kept under version control.
Rehearse token migration and reconcile the vaults
Before any production token moves, the team runs a migration rehearsal on a copy of the token population. They confirm which vault model applies, whether the target vault is the native Hyperswitch Vault or an external PCI vault provider, and whether the processor will issue network tokens or require a re-collection of card data. Each batch is counted and matched against the source vault, with failed and orphaned records logged. The output is a reconciliation report showing migrated, unmigrated and exception counts by entity. The step is done when the rehearsal produces zero unexplained differences and the exception list has an owner and a disposition for each record.
Test entity-based routing rules with shadow traffic
Routing rules are written per legal entity, market and payment method, then tested in shadow mode, where copies of live requests are evaluated by the new routing logic without being sent to a processor for settlement. Engineers compare the chosen connector, fallback order and retry behavior with what the legacy path actually did for the same request. Discrepancies are classified as intended changes or defects. The output is a shadow test log and an approved routing configuration. The step is done when every rule has been reviewed by the owner of the relevant processor contract and every intended change is signed off in writing.
Cut over market by market or entity by entity
Traffic moves to the orchestrator in small, named scopes, one market or legal entity at a time, rather than all at once. Each cutover has a written go or no-go checklist covering the checkout flow, webhook delivery, reconciliation feeds, fraud tool integration and a rollback path back to the legacy route. Payment operations monitors authorization outcomes and exception queues during the switch. The output is a cutover record for each scope. The step is done when the scope has run on the new path under monitoring, the legacy route has been kept available for rollback, and the reconciliation totals for that scope match between the two stacks.
Decommission the legacy path after the evidence window
Once every scope has run on the orchestrator and the reconciliation evidence is complete, the team removes the legacy routes, disables stored credentials for retired processors and archives the migration records. Retention obligations for transaction and communication records are confirmed with legal and finance before any source data is deleted, because some records must be kept for a defined period under the applicable rules. The output is a decommissioning record and an updated processor and vault register. The step is done when the legacy connectors are disabled, access to old vaults is removed, and the retained evidence is stored where auditors can reach it.

Integration points that carry the most risk in a merger

When two companies combine payment stacks, the risk concentrates in a few joints: the orchestration core, the vault that holds stored cards, the admin access model, the processor reconciliation feeds and the ledger that receives the results. Each card below names one joint, what goes wrong there during a merger, and what to verify before cutover.

Router and Scheduler on PostgreSQL and Redis

Hyperswitch runs two app services, Router and Scheduler (Producer and Consumer), backed by PostgreSQL with a master and replica setup and by Redis for caching and the scheduler queue. During a merger, both acquired and legacy routing rules and retry jobs may run against the same database, so queue backlogs and replica lag can delay retries or revenue recovery. Confirm how replica lag, queue depth and failover are monitored, and who owns the database during the overlap period.

Card vault and key management boundary

Stored cards from the acquired company must move into the surviving vault without exposing account data in transit or in logs. The Hyperswitch card vault is a separate service, and the encryption service handles key management. Decide early which vault model applies, since the in-house PCI model leaves the merchant fully responsible for PCI DSS certification and data handling. Ask who holds the keys, where they are stored and how the migration is evidenced.

Control Center access through OpenID Connect only

The Control Center supports single sign-on through OpenID Connect only. SAML is not supported, there is no JIT or SCIM provisioning, users must be invited first, and roles are managed in Hyperswitch rather than mapped from the identity provider. After a merger, this means acquired staff need manual invitations and role assignments, and offboarding must be handled inside Hyperswitch as well as in the directory. Build a joiner and leaver procedure and confirm it against the access review evidence your auditors will request.

Reconciliation feeds from each processor

Each acquired and legacy processor reports settlements, refunds and chargebacks in its own format and on its own cycle. Hyperswitch documents reconciliation as one of its modules, but the mapping from each processor's files to a common transaction model is work the implementation team must scope and test. Check that every processor feed is captured, that totals match between processor, orchestrator and bank, and that unmatched items have a named owner before the first cutover.

ERP and ledger integration

Settled transactions, fees and chargebacks must post to the general ledger under the correct legal entity, and during a merger the entity structure is often in flux. Confirm which system owns the posting logic, how intercompany balances are handled, and how the ledger reflects routing changes made mid-migration. Map each payment event type to a ledger account and test a sample month of postings against the bank statements before retiring the acquired company's posting jobs.

Kubernetes deployment with Helm in your own cloud

Hyperswitch documents self-hosting with Helm charts on Kubernetes, with guides for AWS, GCP and Azure, and Docker for local setups. Deploying into the client's own cloud or data center keeps card data and transaction logs under the client's control, but it also means the client owns cluster upgrades, secrets, network segmentation and backups. Ask who operates each layer, how upgrades run without payment downtime, and how the two environments are kept on the same release during the overlap.

Evidence auditors and regulators ask for during consolidation

This table maps each piece of evidence to the party that typically requests it and the platform component or record that produces it. Use it to plan what the orchestration layer must log, export and retain before the first processor cutover. Confirm each requirement with your own auditors, regulators and counsel, since applicability depends on your entity structure and jurisdictions.

Evidence item	Who asks for it	Which component or record produces it
Change management records for routing rules and connector changes	External auditors testing IT general controls, PCI DSS assessor, internal audit	Version-controlled routing configuration and approval tickets; Control Center change history, to be confirmed against your deployment
Access logs for Control Center and card vault	External auditors, PCI DSS assessor, information security	Control Center user activity records and vault access logs; confirm retention and export with your platform team
Reconciliation reports per processor and per acquired entity	Finance controllers, external auditors, SEC registrants' ICFR testing teams	Reconciliation module output per connector, compared with processor settlement files and the general ledger
Token migration reconciliation	PCI DSS assessor, data protection officer, acquirer and processor partners	Migration run logs with counts of source and migrated tokens, exception lists and sign-off records
ICFR scoping documentation for the acquired business	SEC registrant management, external auditors	Management memo excluding or including the acquired business from ICFR assessment, with the significance disclosed as required
DORA register of information entries for ICT arrangements	Financial entity compliance, competent authority supervisors	Third-party register entries for the orchestrator, vault, hosting and processors in each entity's arrangements
GDPR records of processing and transfer tool documentation	Data protection officer, EU supervisory authorities, acquirer's legal team	Records of processing updated for the merged entity, plus the chosen Chapter V transfer tool where non-EEA staff access EU systems
PCI DSS scope documentation and responsibility matrix	PCI DSS assessor, payment brands, acquirer	Scope diagram of the cardholder data environment, data flow maps and the split of PCI DSS responsibility between you and the platform provider

What do buyers ask before consolidating payments after a merger?

How long does it take to consolidate two processors behind one orchestrator?

There is no fixed duration that applies to every merger, and any number quoted without a scope is a guess. The timeline is driven mainly by the volume of stored tokens that must move, the notice periods and exit terms in each legacy processor contract, the number of checkout flows and payment methods in play, and how many entities and currencies the routing rules must cover. Ask for a phased plan in writing that separates the token migration, the routing cutover and the legacy shutdown, with a named dependency for each. A written scope lets you compare the plan against your contract calendar before work starts.

What do we need from our processor and finance teams during consolidation?

Consolidation depends on decisions and data that sit outside the engineering team. Processor-side, you need the contract owners to confirm notice periods, termination terms, token export options and who at each processor can release stored credentials or network tokens. Finance-side, you need reconciliation owners who can confirm settlement files, fee schedules, chargeback handling and the ledger mapping for each entity. Both teams should agree on which entity each merchant account belongs to before routing rules are written. Ask the implementation partner to list these inputs in the scope so gaps surface before the cutover date is fixed.

Can our internal team run a payment consolidation without an outside partner?

An internal team can run it if it already operates payment infrastructure, has PCI DSS experience in its own environment, and can dedicate engineers and reconciliation staff for the full period. Most mergers lack that capacity at the same time, because the same people are also handling integration, access and compliance work. Be clear about who holds the card vault keys, who owns the PCI DSS responsibility split and who signs off on routing changes. If those roles are unclear, a fixed-scope engagement with written deliverables can cover the gaps. Ask a partner to show which tasks they would hand back to your team.

What drives the cost of a payment consolidation project?

Cost comes from who is paid for what. One-time work includes connector setup for each processor, the token migration plan and execution, routing rule design, reconciliation mapping and cutover testing. Recurring costs include infrastructure for the orchestration layer, any card vault or HSM service, licensing or subscription fees for vendors you choose, and ongoing operations. The main cost drivers are the number of connectors, the vault model you select, the PCI DSS assessment of your own environment, and the volume and format of the stored tokens that must migrate. Ask for a quote that prices each of these separately, states the assumptions about token volume and the processors included, and lists any third-party fees you will pay directly.

How do we handle staff at an acquirer who need access to EU personal data?

Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, counts as a transfer. If the acquirer's staff outside the EEA can reach the target's payment systems or payer data, a Chapter V transfer tool is needed before that access starts. The GDPR also requires processors to act only on the controller's documented instructions, including for transfers (Article 28(3)(a)). Limit access by role, record it in the processing records, and confirm the transfer basis with counsel. Ask your partner to design access so that EU payer data stays inside EU-hosted systems, with logged, approved access paths only.

What happens to stored cards during the token migration?

Stored cards can move only if the source processor or vault allows the data to be exported or re-tokenized in a lawful way, and the destination vault is set up to receive it. Confirm with each legacy processor whether card data, network tokens or only tokens can be exported, and under what conditions. Plan for a period where both vaults are live, with routing rules that send new transactions to the target and fall back for cards not yet migrated. Validate a sample of migrated tokens against live authorizations before switching the rest. The scope must state who signs off on each migration batch and how failed records are handled.

When can we close the legacy processor contract?

Close the legacy processor only after four conditions are met: all required tokens are migrated or retired, new transactions route reliably to the target processors, reconciliation for the overlap period balances, and the contract's notice and exit terms have been satisfied. Keep the legacy account available for refunds, chargebacks and disputes on earlier transactions for as long as those can arrive. The EU Data Act requires data processing providers to support switching with a maximum two-month notice period and a 30-day transitional period, which can help when a provider is a cloud or data service, but the processor contract is what governs payment processing. Ask for the shutdown criteria in writing and confirm them with your legal and finance teams.

Questions to ask a partner before the migration plan is signed

Ask the partner to show, in writing, how token formats from each legacy vault map into the Hyperswitch card vault before any stored credential moves. The question is not whether tokens can be migrated, but which format the target uses, whether network tokens or processor-specific references are involved, and who signs off each mapping table. Ask for the reconciliation of token counts per source vault and per card brand, and for a rollback path if a batch fails. Also ask how the partner handles credentials that the acquired processor will not export, since those customers will need a re-collection flow, and confirm the expected share of those cases with the processor before the plan is set.

Ask how entity routing rules are tested before cutover. A strong answer names a rule set per legal entity, a replay of recent production transaction attributes through the new rules in a non-production environment, and a comparison of the chosen connector against the previous one for each market and payment method. Ask who approves a rule change and whether the approval is recorded in the Control Center audit trail. For reconciliation, ask how the partner matches authorizations, captures, refunds and settlement files from both processors into one ledger, which teams sign each day's variances, and what happens to items that remain unmatched after the agreed cutoff.

Ask how PCI DSS responsibility is split for the merged environment. The partner should produce a responsibility matrix showing which entity holds the attestation for each cardholder data environment, which processors and service providers are in each route, and who owns segmentation testing across both legacy estates. Ask how Control Center access is handled, since the Hyperswitch Control Center supports single sign-on through OpenID Connect only, has no SAML support, no JIT or SCIM provisioning, and manages roles inside Hyperswitch. Ask how invitations, role changes and removals for acquired staff will be run by hand, and how that process is evidenced. Finally, ask for a written exit and transition plan covering each processor, the vault and the data export format, and how upgrades to the Hyperswitch releases will be rehearsed in a staging environment so that the switchover does not coincide with a version change.

How DeployOpen scopes and runs a merged payment migration

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a payment consolidation after a merger, we start with a written scope covering both companies' processor contracts, stored tokens and checkout flows, then build and test the orchestration layer in your environment before any live traffic moves.

How we scope

Inventory both companies' processor contracts, payment methods, markets and stored token populations before any design work starts.
Agree in writing which entity, market and checkout flow each routing rule will cover after the merger.
Define the reconciliation, reporting and data location requirements that each acquired and acquiring entity must meet.
Confirm the PCI DSS responsibility split between your team, the vault model and each processor before scope is signed.

How we build

Configure Hyperswitch connectors for each processor and map routing and retry rules to the agreed entity structure.
Plan the migration of stored tokens between vaults, with test batches and documented checks before any production run.
Test routing changes, fallback behavior and reconciliation matches in a non-production environment that mirrors your setup.
Document the architecture, key management, runbooks and evidence needed for your internal control and compliance reviews.

How we hand over

Run a phased switchover plan with defined rollback points, agreed sign-off gates and named owners on both sides.
Hand over configuration, routing logic, runbooks and reconciliation procedures so your team can operate the platform.
Deliver a record of tests, token migration results and open items at the close of each phase of the engagement.
Walk through how processor onboarding and future acquisitions will be added to the same orchestration layer.

How we support

Offer ongoing support, upgrades and continuous testing through a retainer after the initial migration is complete.
Plan platform upgrades so that routing changes and connector updates are tested before they reach live payment traffic.
Keep documentation current as processors, entities and routing rules change over time after the merger.
Review new processor contracts and data location requirements with your team as the combined business evolves.

Payment consolidation after a merger