A legacy system rarely has a modern payment API waiting to be called. To integrate a payment gateway with a legacy system, you place a middleware bridging layer between the old core (mainframe, on-premise ERP, or aging POS database) and the gateway's SDK, so the legacy code keeps running unchanged while the bridge handles authentication, tokenisation, and Strong Customer Authentication (SCA) on its own.
Three broad approaches exist depending on how much of the legacy stack you can touch and how much risk your business will accept.
| Approach | Best for | Typical timeline | Risk level |
|---|---|---|---|
| Middleware bridge / adapter | Systems with a stable core you can't rewrite | 4-10 weeks | Low-medium |
| Direct SDK integration | Cores with an existing modern API layer | 1-3 weeks | Low |
| Full replatform / rebuild | Cores past end-of-life or blocking growth entirely | 3-6+ months | High |
| Protocol bridge (ISO 8583 or similar) | Payment switches, POS terminals, batch processors | 6-12 weeks | Medium |
| Screen scraping / RPA | Short-term stopgap only, no API available at all | 2-4 weeks | High (fragile) |
Most payment gateways today, whether hosted checkout or embedded SDK, are built for REST APIs, JSON payloads, and TLS 1.2 or higher. A legacy core built a decade or two ago speaks none of that natively. It might expose fixed-width flat files, SOAP endpoints, or nothing at all beyond a direct database connection.
The mismatch shows up in four places. Old databases often can't hold a modern payment token or a webhook payload without a schema change. Character encoding differences turn customer names and addresses into garbled strings mid-transaction. Authentication was built around static API keys or none at all, not OAuth 2.0 or rotating secrets. And batch-oriented cores that reconcile overnight can't handle a payment gateway's expectation of a near-instant response.
None of this means the legacy system has to go. It means the integration has to happen at a layer that understands both sides, which is exactly what a legacy integration strategy focused on isolation, not disruption, is built to do.
Start by mapping what the legacy system actually exposes: database version, existing API or file-export formats, authentication method, and where PCI-DSS scope currently sits. Skipping this step is the single most common reason legacy integration projects run over budget.
Ask three questions before any development starts:
This audit also decides your API integration approach for the rest of the project, since a core with zero API surface needs a very different plan than one with an outdated but usable REST layer.
Once you know what the legacy core can and can't do, pick the bridging pattern that matches. A finance connectivity layer sits between the old core and the gateway, translating formats and holding retry logic so neither side needs to change its native behaviour, an approach detailed in recent finance connectivity architecture guidance for legacy cores.
For systems built around older protocols like ISO 8583 payment switches, a protocol bridge is the more precise fit: it lets the switch keep running exactly as it does today while a translation layer speaks REST or JSON to the outside world, an approach used in practice for modernizing legacy payment switches without replacing them.
For businesses running a more conventional on-premise ERP or database, finance middleware patterns built for legacy banking and ERP platforms apply the same idea to batch files, message queues, and COBOL copybooks.
Whichever pattern you choose, the middleware itself should own three jobs: format translation, retry and idempotency handling for failed transactions, and a queue that absorbs timing mismatches between a fast gateway and a slow legacy write. This is the same principle behind our own approach to ERP integration for web apps, where the sync layer, not the ERP itself, absorbs the risk.
The three main paths differ sharply in cost, control, and how much of the existing system you have to touch.
| Factor | Middleware bridge | Direct SDK integration | Full replatform |
|---|---|---|---|
| Touches legacy code | Minimal, isolated adapter only | Some, if core already has an API | Extensive to total rewrite |
| PCI-DSS scope | Kept narrow via tokenisation | Kept narrow if hosted checkout used | Depends on new architecture |
| Business disruption | Low, runs alongside existing flow | Low | High, requires cutover window |
| Best when | Core is stable but closed | Core already exposes modern APIs | Core blocks growth beyond payments |
Under PSD2, most card-based transactions from UK and EU customers require Strong Customer Authentication, meaning two of three factors (something the customer knows, has, or is) before a payment completes. This is written into the current consolidated version of the Payment Services Directive, and it applies regardless of how old your backend is.
The problem is that legacy checkout flows were often built as a single form submit, with no room for a redirect to a bank's 3DS2 challenge screen and back. Your middleware layer needs to hold the transaction state during that round trip, something a stateless legacy form-post was never designed to do.
We cover the specific failure patterns this causes in our dedicated guide to avoiding PSD2 pitfalls in payment gateway integration, which is worth reading alongside this one if your checkout still posts synchronously.
SCA exemptions exist for low-value transactions and recurring payments already authorised once, but they're granted by the card issuer's risk engine, not guaranteed. Build your integration assuming the challenge screen will appear, and treat any exemption as a bonus, not a plan.
Four failure patterns show up repeatedly in legacy gateway integrations, and all four are avoidable if you plan for them before go-live.
Timeouts on legacy database writes happen when the gateway confirms a payment faster than the old core can commit the record. Queue the write and acknowledge the gateway immediately, don't make the customer wait on the slowest system in the chain.
Character encoding mismatches corrupt names and addresses when a legacy database still runs on Latin-1 while the gateway sends UTF-8. Normalise encoding at the middleware boundary, not inside the legacy code.
Duplicate transaction handling matters because network retries are normal in modern APIs, but a legacy core without idempotency keys will happily process the same charge twice. The middleware layer needs to generate and check its own idempotency keys, since the legacy side won't.
Finally, webhook reliability trips up systems that expect a live callback but only poll on a schedule. If your legacy core can't receive webhooks directly, have the middleware catch them and write to a queue the legacy system can poll on its own terms.
Never cut a legacy system straight over to a new gateway on launch day. Run the new integration in shadow mode first, processing real transactions through both the old process and the new gateway path, then compare results before disabling the old one.
A phased rollout typically looks like: sandbox testing with the gateway's test cards, a shadow-mode pilot on a small percentage of live traffic, then a full cutover once error rates match or beat the old process. Our UAT checklist before launch covers the specific edge cases worth testing here, including expired sessions and failed payment states that are easy to miss in a rushed go-live.
Cost depends almost entirely on how much of the legacy stack the integration has to touch, not on the gateway itself. A straightforward SDK-level integration using a gateway's hosted checkout, where card data never reaches your servers, typically runs in the $8,000 to $30,000 range over two to six weeks, according to recent payment gateway integration cost analysis.
A custom middleware bridge into a genuinely old core, with retry logic, queueing, and PCI scoping, sits at the higher end of that range or above it.
The biggest cost driver isn't the gateway integration itself, it's the audit and remediation work on the legacy side: schema changes, encoding fixes, and building the retry queue that keeps a slow core from timing out a fast API. Businesses that skip the audit and jump straight to building often discover this the expensive way, mid-project.
For UK and wider European SMBs, factor in one more line item: SCA compliance testing across the specific card issuers your customers actually use, since 3DS2 challenge behaviour varies by bank. This is a fixed cost regardless of company size, and it's one reason a lean, focused development partner often ends up more cost-effective than a large agency billing by the hour for the same audit work.
A direct SDK integration into a core that already has usable APIs takes one to three weeks. A middleware bridge into a genuinely legacy core, including audit, build, and phased testing, typically takes four to ten weeks depending on how much retry and queueing logic the legacy side needs.
Protocol bridges for older payment switches or POS terminals tend to run six to twelve weeks, since they involve translating a proprietary protocol rather than just wrapping an existing API. Full replatforming, where the legacy core itself is rebuilt rather than bridged, is a multi-month undertaking closer to what we cover in our custom software development cost breakdown.
Yes. Stripe's Payment Intents API can sit behind a middleware layer that translates its webhooks and JSON responses into a format your legacy core can consume, though integrating Stripe with legacy architectures still requires handling outdated APIs and mismatched data formats on the legacy side.
Rarely for payments alone. Most legacy cores can accept a gateway through a middleware bridge without a rebuild. A full replatform only becomes the right call when the core is failing for reasons unrelated to payments, such as blocking every other integration your business needs.
It can, if both systems write to the same order or customer records. Map the data flow between the payment middleware and your ERP before building either, which is the same principle behind our guide to ERP integration for web apps and avoiding sync errors.
Building the gateway connection before auditing the legacy core's actual limits. That order gets the project stuck halfway, once someone discovers the database can't hold a token or the core can't receive a webhook.
If your checkout still runs through a system built before modern payment APIs existed, a middleware bridge is usually faster and safer than a rebuild, but it has to be scoped against your specific database, auth method, and PCI posture, not a generic template.
Axire Infotech's development team builds these bridges for SMBs and enterprises across the UK, Ireland, and wider Europe, working through the same discovery-first process we use for every web development and app development project. Browse our past integration projects or explore the full range of services, then get in touch to scope your legacy payment gateway integration before your next PCI review comes due.
Let's discuss your project and create something amazing together.
