PSP consolidation saves real money but takes longer than the case studies suggest. The merchant in this study went from 4 PSPs to 1 over 9 months. The net saving was 22% of processing cost, not the 35-40% the PSP sales decks had projected.
5 Key Facts
Multi-PSP setups typically cost 15-30% more in processing fees than a single-PSP setup at the same volume. The anonymised merchant in this study was paying 28% more before consolidating.Consolidation takes 6-12 months for a mid-sized merchant. The anonymised merchant in this study took 9 months from kickoff to the last PSP decommissioned.Engineering cost of consolidation is typically 8-16 weeks of engineering, depending on the number of touchpoints with PSP-specific logic in the checkout flow.Most of the cost savings come from renegotiating with the surviving PSP, not from operational simplification. The merchant saved 22% on processing fees, of which only 4 percentage points came from operational gains.Consolidation creates single-point-of-failure risk. The merchant addressed this with a fallback PSP integration that activates only during outages
Most PSP consolidation case studies skip the messy parts. The real story takes longer, costs more, and produces smaller gains than expected.
Disclosure: This case study uses an anonymised composite based on multiple merchant engagements. Specific numbers, names, and timeline details have been changed to protect client confidentiality. The patterns and lessons are real; the details are illustrative.This is the unedited version, told with the actual numbers, the actual timeline, and the actual decisions that had to be reversed.
The merchant is a UK-based ecommerce business doing roughly £40m/year in card volume across the UK, EU, and US. They were running four PSPs: a UK acquirer for domestic volume, an EU acquirer for European cards, a US acquirer for US cards, and Stripe as a fallback for everything else.
Why they had four PSPs in the first place
The four-PSP setup was not designed. It grew. Each PSP was added for a specific reason at a specific time.
The UK acquirer came from a banking relationship. The EU acquirer was added when the merchant expanded into Europe and needed a local entity. The US acquirer was added when US volume hit a threshold where US routing became viable. Stripe was added as a fallback when one of the acquirers had a multi-day outage.
The result was a checkout flow with four routing paths, four reconciliation streams, four sets of fees, and four relationships to manage. Each PSP had its own statement format, its own dispute process, its own SLA.
The finance team was the first to push for consolidation. The reconciliation alone was eating 4 days a month. The engineering team pushed back on the integration cost. The CEO wanted clarity on the cost-benefit.
The cost-benefit analysis
Total processing fees before consolidation: £1.05m/year on £40m of volume, an effective rate of 2.62%.
PSP sales decks (each of the four) projected consolidation savings of 35-40%. That would have brought the effective rate to roughly 1.7%, a £400k/year saving.
The actual saving after consolidation: £230k/year, taking the effective rate from 2.62% to 2.05%. That is 22% of processing cost, not 35-40%.
The gap between the projected and actual savings came from three sources: the surviving PSP could not match the cost profile across all geographies (US routing in particular), the operational savings (4 days of reconciliation) were harder to realise than projected, and the renegotiated markup was lower than the sales deck had implied.
The 9-month timeline
Month 1-2: scoping. Engineering team audited every PSP touchpoint in the codebase. Found 47 places where PSP-specific logic lived. Realised the migration was bigger than the sales decks had implied.
Month 3-4: PSP selection.Three of the four PSPs bid to be the surviving partner. The selected PSP won on US routing capability and willingness to negotiate on the EU surcharge. The losing two were amicable.
Month 5-6: integration. Built the new routing layer against the surviving PSP. The hardest part was the US acquirer decommission, which required retokenising customer cards.
Month 7-8: cutover.Moved UK and EU traffic first. Held US on the legacy acquirer for an extra month to validate the new routing.
Month 9: decommission.Closed the three non-surviving PSP accounts. Finance team reconciled all outstanding balances.
What was harder than expected
Three things surprised the team.
First, retokenisation. The US acquirer held 80,000 saved customer cards. Moving them to the surviving PSP required either asking customers to re-enter their cards (conversion hit) or running a token migration (engineering hit). The merchant chose token migration, which cost 4 extra weeks of engineering.
Second, dispute handling. Each PSP had its own dispute API. The merchant's support team had to learn the surviving PSP's flow. The transition period saw dispute response time increase by 2 days, which affected customer satisfaction scores.
Third, FX. The merchant had been optimising FX through their EU acquirer. The surviving PSP's FX pricing was less competitive. The team had to renegotiate FX separately, which added 6 weeks to the timeline.
What was easier than expected
Two things went much better than we feared.
Reconciliation. The 4 days of finance team reconciliation did reduce, but it reduced to 1 day, not zero. The surviving PSP's statement format was better but not magical. Net savings: 3 days of finance time per month!
Engineering maintenance. The merchant had been carrying four PSP integrations. Going to one reduced ongoing maintenance meaningfully. The engineering team estimated a 30% reduction in payments-related bug fixes and a 50% reduction in PSP-related support tickets.
The single-point-of-failure concern
The original four-PSP setup was partly justified by reliability: if one PSP went down, the others picked up the load. The merchant addressed this by keeping Stripe as a fallback integration, routing to it only when the primary PSP was unavailable.
The fallback integration was 3 weeks of additional engineering. It runs in shadow mode by default, activating only on circuit-breaker trip. The merchant has not had to use it in production, but the integration gives the operations team confidence.
The result
Nine months, £230k/year saved, 4 PSPs down to 1, reconciliation cut from 4 days to 1 day, payments-related engineering maintenance reduced meaningfully. The merchant would do it again.
Their honest advice to other merchants considering consolidation: take the sales decks seriously but adjust for the operational savings being smaller than projected. The cost benefit is real. The timeline is real. The messiness is real too.
Working out whether consolidation makes sense for your specific PSP setup is a 60-minute conversation worth having before any engineering commitment. Organise a call with the Tonkr team
