The Consolidation Wave Is Not Slowing Down
The payment processing industry has been through a decade of aggressive consolidation, and the pace is accelerating rather than stabilising.
The transactions read like a roll call of the industry's biggest names. Fiserv acquired First Data for $22 billion in 2019, creating one of the largest payment technology companies in the world. FIS acquired Worldpay for $43 billion in the same year, in what was then the largest ever fintech acquisition. Global Payments acquired TSYS for $21.5 billion in 2019. Nexi, Nets, and SIA completed a three-way combination in Europe worth roughly €15 billion in 2021.
And now: Global Payments is acquiring Worldpay from GTCR for approximately $24 billion, reuniting Worldpay with a major acquirer after FIS divested the business in 2023 following years of integration difficulty.
Each of these deals follows the same industrial logic. Acquiring processors need scale to compete on pricing. Network effects create winner-take-most dynamics in specific geographies and verticals. Technology integration promises cost efficiencies that rarely materialise as cleanly as the deal models suggest. Shareholders get a premium. The press release is optimistic.
What the press releases rarely discuss is what happens to the software platforms that built their payment infrastructure on top of these businesses.
What Happens to Platforms When Their PSP Gets Acquired
When a PSP gets absorbed into a larger acquirer, the effects on dependent platforms are not immediate. The first few months typically look fine. The existing integration still works. Support channels still respond. The account manager is still in the same role.
The structural changes come later, and they compound.
Roadmap Reprioritisation
Post-acquisition, the acquired PSP's engineering organisation gets absorbed into the parent company's technology strategy. Product roadmaps get consolidated. Features that were six months away get pushed to eighteen months, or get cancelled as redundant with the parent's existing capabilities. API versioning commitments made before the deal may or may not survive the integration.
For a platform that built a deep integration against a specific PSP's API, roadmap divergence is an operational risk. The features your merchants rely on — or the ones you were counting on launching — may simply not be built on the timeline you planned.
Support Tier Renegotiation
Enterprise support agreements are treated as costs to be rationalised in post-merger integration. Support tiers get restructured. SLAs get renegotiated at the enterprise level, and the terms that smaller or mid-market platforms had often come off worse in the standardisation process. The dedicated technical contact who knew your integration gets reassigned to a larger account.
Pricing Leverage Shifts
This is the bluntest mechanism. Before the acquisition, your platform had negotiated pricing based on its volume, its trajectory, and the competitive tension between the PSP and its rivals. After the acquisition, the combined entity has a larger installed base, more cross-sell leverage, and less need to maintain aggressive pricing to win your business. Contract renewals after major acquisitions routinely come back with higher rates, restructured incentives, or terms that push platforms toward the parent company's broader product suite.
Integration Priorities Get Aligned to the Parent's Strategy
The most subtle effect is strategic alignment. The acquired PSP's partnerships team, previously focused on platform distribution, now operates within the parent company's partner strategy. That parent company has its own priorities — often centred on direct merchant acquisition rather than enabling platforms. Resources that were previously devoted to helping platforms integrate and scale get redirected toward initiatives that are more valuable to the combined business.
The platform is not abandoned. It just becomes lower priority. And lower priority, in payment infrastructure, means slower iteration, less responsive support, and reduced leverage in commercial discussions.
The Multi-PSP Hedging Response — and Its Costs
Experienced platform operators have learned to anticipate this pattern. The response, almost universally, is to add a second PSP. Sometimes a third.
The logic is sound. If your business is dependent on a single processor, you are exposed to the full operational and commercial risk of whatever happens to that processor — whether that is an acquisition, a service disruption, a pricing change, or a strategic pivot away from your segment. Diversifying across two or more PSPs reduces concentration risk.
But multi-PSP architectures built by direct integration create their own set of problems.
The Integration Tax
Every PSP integration is custom work. Each processor has its own API design, its own webhook format, its own tokenisation approach, its own quirks in how it handles refunds, disputes, and subscription billing. A platform with three direct PSP integrations has three separate codebases to maintain, three separate sets of API credentials to manage, and three separate upgrade cycles to track.
This integration tax compounds over time. When a PSP releases a new API version, your team has to assess the impact on your integration and schedule the upgrade work. When a new payment method becomes commercially relevant — pay-by-bank, buy now pay later, or a regionally important local method — it has to be implemented against each PSP separately. Every new PSP you add multiplies the maintenance surface.
Enterprise PSP Mandates Create Pressure from the Other Direction
While acquisitions push platforms toward multi-PSP defensively, enterprise customer requirements push them there commercially. Enterprise customers — those with negotiated rates, existing compliance certifications, and multi-year contracts with specific processors — will not switch their PSP to use your platform. If your platform can only accept payments through Stripe, you cannot close the enterprise customer who processes through Worldpay.
The practical result: platforms that serve mid-market and enterprise customers find themselves needing to support an expanding list of PSPs. Not because they planned to, but because each major prospect they want to close mandates a different one.
The Hedged Architecture Still Has a Single Point of Failure
Even platforms that have built integrations against two or three PSPs typically have one primary and one backup. The primary handles most volume. The secondary handles edge cases or regional requirements. When the primary PSP gets acquired, the platform is not actually well-positioned — the secondary integration has seen far less use, may have accumulated technical drift, and is not operationally ready to absorb primary-level volume without significant additional work.
The Structural Solution: A PSP-Neutral Layer
The multi-PSP hedging response addresses the symptom — concentration risk on a single processor — without addressing the structural cause, which is that each PSP integration is a bespoke build with its own maintenance cost.
The structural solution is to separate the platform's payment interface from the underlying processor. Instead of building directly against each PSP's API, the platform integrates once against a PSP-neutral layer. That layer handles all downstream PSP integrations, maintains API compatibility as processors evolve, and exposes a consistent interface to the platform regardless of which processor is executing the transaction.
When a PSP gets acquired and its API changes, that change is absorbed by the payment layer, not by the platform. When an enterprise customer mandates a specific processor the platform hasn't previously used, connecting that processor is a configuration change against an already-existing integration, not a new build project.
This architecture makes PSP relationships interchangeable from the platform's perspective. The platform maintains commercial relationships with whichever processors are relevant to its business. The technical dependency on any individual processor's implementation is eliminated.
It also changes the nature of the consolidation risk. When Global Payments acquires Worldpay, a platform using a PSP-neutral layer has options. It can continue using Worldpay via the same integration. It can shift volume to a competing processor. It can use the deal as leverage in a pricing conversation. It has optionality that a platform with a direct single-PSP integration does not.
This is the commercial insight behind PSP-neutral architecture: processing is commoditised. The pricing pressure and volume economics that drive PSP consolidation are evidence of this. What matters for platforms is not which processor you use — it is that you have the optionality to use any processor your business requires, without rebuilding your integration every time market structure changes.
How to Consolidation-Proof Your Payment Stack
The consolidation pattern is not going to stop. The economics that drive it — scale requirements, margin pressure, geographic expansion — are structural features of the payment processing industry. Platforms that build their payment infrastructure around PSP-neutral architecture are positioning themselves to be resilient to M&A activity that is almost certain to continue.
Here is what that looks like in practice.
Audit your current PSP dependencies. Map every place in your codebase where you have a direct dependency on a specific processor's API, tokenisation scheme, or webhook format. This is your consolidation exposure surface. The larger it is, the more disruption you absorb when your PSP gets acquired or changes direction.
Model the cost of multi-PSP with direct integration. If you are currently on a single PSP and planning to add a second, price the real engineering cost honestly — initial integration, ongoing maintenance, support for new payment methods, PCI scope expansion, and the operational overhead of managing multiple processor relationships. That is the build cost of multi-PSP resilience. It is usually higher than it appears in initial scoping.
**Evaluate PSP-neutral architecture as a build vs. buy decision.** A purpose-built PSP-neutral layer — one that already has 40+ processor integrations, handles PCI compliance, and exposes a consistent API regardless of which processor is running underneath — is not the same cost as building your own multi-PSP integration from scratch. The economics are different. Compare the approaches directly.
Treat processor relationships as commercial, not technical. In a PSP-neutral architecture, your relationship with each processor is a commercial negotiation, not a technical dependency. You are free to add processors, change primary processors, and negotiate pricing based on the credible option to move volume elsewhere. That leverage is worth something — particularly at contract renewal time, when an acquired PSP's parent is restructuring pricing.
**Plan for PSP mandates in enterprise deals, not around them.** If your platform sells to mid-market or enterprise customers, the next major prospect you want to close probably has a mandated processor. Solving for this reactively — one bespoke integration at a time — is expensive and slow. Solving for it architecturally is a one-time project that compounds in value with every enterprise deal you close afterward.
Assess your channel coverage. PSP consolidation affects not just embedded checkout, but every payment channel your platform operates or plans to operate. Voice, payment links, chat — all of them have PSP dependencies that follow the same consolidation risk pattern. A platform that solves for multi-PSP in checkout but has a single-processor dependency in voice has not fully addressed its exposure.
Processing Is Commoditised. Optionality Is Not.
The $24 billion that Global Payments is paying for Worldpay is not a bet that processing margins are going to expand. It is a bet on scale, on distribution, and on owning the infrastructure inside which merchants operate.
The same logic applies to platforms. Processing margin is not where platform value accrues. Platform value accrues from the workflows, the merchant relationships, and the enterprise deals that flow through your product. Payment processing is a required function, not a differentiator.
What is a differentiator — commercially and competitively — is the ability to support whatever payment infrastructure your enterprise customers require, without your own engineering team absorbing the cost every time M&A activity reshapes the processor landscape.
The platforms that will be most exposed to the next consolidation wave are the ones with the deepest direct dependencies on the processors being acquired. The ones best positioned are the ones for whom the underlying processor is an interchangeable detail.
Related Reading
PSP-Neutral vs Single-PSP: Which Approach Is Right for Your Platform?
Enterprise PSP Mandates: Why Platforms Need Multiple Gateways
Work With Shuttle
Shuttle is a PSP-neutral payment layer for platforms. A single integration connects your platform to 40+ payment processors — with white-label merchant onboarding, a management portal, and PCI DSS Level 1 compliance included. When your PSP gets acquired, you have options. When an enterprise customer mandates a processor you don't currently use, connecting it is a configuration change, not a build project.
Book a Discovery Call to discuss your current payment architecture and where consolidation risk sits in your stack.
See How Platforms Use Shuttle to understand the integration model and the commercial case.