Moving from ePDQ to Unified Checkout

Most ePDQ to Unified Checkout migrations succeed technically. Issues usually surface later, when transactions need to be traced and reconciled across systems. This article looks at where those gaps come from and how to avoid them.

Moving from Barclaycard ePDQ (API‑first) to Smartpay Fuse Unified Checkout is less about swapping SDKs and more about reframing how payment logic is split between code and gateway configuration.

With ePDQ, much of the checkout behaviour lived inside application code. This often included card capture, redirects, error handling, retries and, in some cases, compensating logic for failed or partial transactions. That gave developers fine‑grained control but also meant higher PCI exposure, more bespoke logic and greater long‑term maintenance risk.

Unified Checkout shifts this balance. Card capture, SCA/3DS handling, wallet support and security concerns move into hosted gateway components, embedded within the site, rather than custom built in the application. From a development standpoint, this reduces surface area but it also means:

• You no longer fully “own” the payment experience in code

• Behaviour changes are often configuration-led, not deployment-led

• Debugging requires an understanding of both application state and gateway state

The most important architectural adjustment we found was introducing explicit transaction states and treating payments as an asynchronous, state-driven process rather than a single synchronous API call.  This involves separating:

• checkout initiation

• payment authorisation

• final confirmation (via callbacks or webhooks)

This makes it easier to design for idempotency and resilience and to handle edge cases such as 3DS challenges, user cancellation, timeouts and retries. It is especially important in real-world flows where customers abandon or re-enter checkout mid-process.

Another practical lesson is that Unified Checkout works best when developers resist the urge to re‑implement gateway behaviour in application code. Instead, the application should focus on:

• validating intent before checkout

• persisting and reconciling transaction state

• reacting consistently to gateway callbacks

This requires clearer contracts between engineering, payment providers and operations. Decisions such as when fraud tools (e.g. Decision Manager) are enabled, how TRA exemptions are applied, or which payment methods appear under different conditions are no longer purely technical choices. They are shared responsibilities that must be explicitly defined and owned.

Finally, from a developer experience perspective, Unified Checkout delivers clear benefits when implemented well. Native support for Click to Pay, Apple Pay, and Google Pay reduces custom development, improves mobile user experience and aligns with modern authentication patterns, while keeping sensitive data out of the application stack.

These gains only materialise if teams invest upfront in discovery, clearly defined ownership and well-structured operational flows, rather than treating the migration as a like‑for‑like replacement.

What changes in practice

Treat Unified Checkout as a platform shift, not an integration task. Design for state, callbacks, and configuration first. Keep application code intentionally thin around payments and define ownership boundaries early, particularly around fraud strategy and authentication behaviour as the system evolves.

Our approach to delivery

The primary risk in these migrations does not sit in the integration itself. It sits in the points where application logic, gateway behaviour and operational ownership do not fully align.

Left unaddressed, those gaps tend to surface later, during reconciliation, support activity or when systems are placed under real user load.

Our approach is to address these areas early and deliberately. That typically includes:

• establishing a clear transaction model that can be understood across systems

• aligning engineering, payments and operational stakeholders from the outset, rather than resolving ownership reactively

• designing payment flows that reflect how users actually behave, including retries, drop-off and re-entry, rather than relying on an idealised journey

These are design decisions rather than implementation details but they have a direct impact on how the system performs over time.

Done well, the outcome is a payment architecture that remains predictable and easier to operate as transaction volumes and complexity increase.