Payment Gateway Consolidation — 4 Providers to 1 Orchestration Layer

The Problem

At a Fortune 500 retailer, the e-commerce platform had accumulated four payment gateway integrations over five years. Each had been added for a different reason — one for domestic credit cards, one for international transactions, one for digital wallets, and one that was a legacy holdover nobody wanted to touch.

Each integration was built by a different team at a different time. There were four separate codebases with four different error-handling patterns, four retry strategies, and four logging formats. When a payment failed, diagnosing the root cause required checking four systems. Reconciliation was a monthly ordeal that consumed an entire analyst's time.

The maintenance burden was staggering. Any change to the checkout flow required coordinating across all four integrations. A simple tax calculation update took three sprints because each gateway handled it differently. The team spent 40% of their capacity just keeping the lights on.

Transaction success rates sat at 94% — not terrible, but every failed transaction represented lost revenue. When one gateway went down, there was no fallback. Customers simply saw an error page.

What I Did

I led the design and delivery of a payment orchestration layer — a single service that sat between the checkout experience and all four gateways. The core principle was abstraction: the checkout flow would speak to one API with a consistent contract, and the orchestration layer would handle provider selection, routing, and error management.

I worked with the architecture team to define the unified API contract. We standardised payment request/response schemas, error codes, and webhook formats. Every gateway-specific quirk was encapsulated within provider adapters that translated to and from the common contract.

We built intelligent routing logic based on transaction type, currency, amount thresholds, and historical success rates per provider. If the primary gateway for a given transaction type failed, the orchestration layer automatically retried with a fallback provider — transparently to the customer.

I managed the rollout as a phased migration. We started with the lowest-volume gateway, validated the orchestration layer in production, then migrated each subsequent provider over six weeks. At no point did we cut over everything at once — every phase had a kill switch to route directly to the original integration if needed.

The Outcome

Maintenance effort on payment integrations dropped by 60%. What previously required changes across four codebases now required a single update to the orchestration layer or an individual adapter. Reconciliation went from a multi-day process to an automated daily report.

Transaction success rates improved from 94% to 98.5%, driven almost entirely by the fallback routing. When one provider experienced degraded performance, the system automatically shifted traffic — customers never noticed. The retailer estimated the improved success rate recovered over $2M in annual revenue that was previously lost to failed transactions.

The orchestration layer also made it trivial to evaluate new payment providers. Adding a fifth gateway later took two weeks instead of the months it would have previously required.