3D Secure in a Payment Orchestration Architecture: Why Authentication and Authorisation Should Be Decoupled

Payment orchestration discussions focus on authorisation routing: which acquirer handles which transaction, based on cost, performance, and geography. What they rarely address is what happens to 3DS authentication when that routing changes. If authentication context is not carried correctly across routing boundaries, the liability shift breaks silently. Merchants discover this only when chargebacks spike on routed transactions.

This matters because 3DS authentication and payment authorisation are separate protocol flows, often treated as tightly coupled but architecturally independent. How you handle this separation, or fail to, has direct consequences for your frictionless rate, your liability shift coverage, and the operational overhead of managing a multi-acquirer payment stack.

How authentication and authorisation are typically coupled, and why that creates problems

In a standard single-acquirer setup, 3DS authentication and authorisation are managed by the same party — your PSP or payment gateway handles both. The authentication values (ECI and CAVV/AAV) flow automatically from the authentication step into the authorisation request. You do not need to think about the connection because it is managed for you.

In a payment orchestration setup, this assumption breaks. You may authenticate a transaction through one PSP's embedded 3DS flow and then decide, based on routing logic, to authorise through a different acquirer. In this scenario, the authentication values from the first PSP need to be passed correctly into the authorisation request submitted by the second. If they are not, or if the routing happens at a layer that does not carry the authentication context, you lose the liability shift, and the transaction is treated as unauthenticated at the authorisation stage.

This is not a theoretical edge case. It is a common failure mode in orchestration architectures where the 3DS integration was built assuming a single acquirer and was never updated to pass authentication context across routing boundaries.

The case for a standalone 3DS Server

The cleanest solution to the orchestration-authentication problem is to decouple 3DS authentication from authorisation entirely, using a standalone 3DS Server that sits independently of any specific acquirer or PSP relationship.

In this architecture:

• The standalone 3DS Server authenticates every transaction, independently of which acquirer will process the authorisation.
• The authentication result — ECI code, CAVV/AAV, 3DS Server Transaction ID — is returned to the merchant's orchestration layer.
• The orchestration layer routes the authorisation to whichever acquirer is selected, carrying the authentication values from step 2 in the authorisation request.
• The acquirer submits the authorisation to the issuer with the authentication values included, establishing the liability shift.

In this model, authentication is acquirer-agnostic. You can add a new acquirer, change your primary routing destination, or run parallel A/B tests across acquirers without touching your 3DS integration. Authentication performance — frictionless rate, challenge completion rate, data element quality — is managed in one place and applies uniformly across all authorisation routes.

Scheme certification: why it matters in an orchestration context

Each card scheme — Visa, Mastercard, Amex, JCB, and others — operates its own Directory Server, and any 3DS Server must be independently certified for each scheme it supports. In a PSP-bundled model, the PSP manages these certifications on your behalf. In a standalone 3DS Server model, the certifications are owned by the 3DS Server provider.

For orchestration architectures, scheme certification coverage is a critical evaluation criterion. If your orchestration layer routes a JCB transaction (relevant for Japan and some APAC markets) or an Amex transaction, your 3DS Server must hold the relevant certifications. Gaps in certification coverage create silent authentication failures — the transaction falls back to an unauthenticated flow without necessarily surfacing as an error.

When evaluating standalone 3DS Server providers for an orchestration architecture, confirm:

• Which card scheme Directory Servers is the provider certified for?
• How quickly does the provider update certifications when schemes release new version requirements (e.g. the 2024 deprecation of 3DS 2.1)?
• How are scheme certification updates surfaced to integration partners, and what notification lead time is provided before mandatory migrations?

Authentication context across the orchestration stack: what to check

For payment and finance teams auditing an existing orchestration architecture, the key questions are:

Where does authentication happen in the transaction flow?

Is authentication performed before routing decisions are made? Or is it embedded within a specific PSP's checkout flow, making the outcome dependent on which PSP is selected? If the latter, there is a risk that routing changes will affect authentication outcomes in ways that are not immediately visible.

Is the full authentication payload being passed to every acquirer?

Pull a sample of authorisation requests across your acquirer relationships and verify that ECI, CAVV/AAV, and 3DS Server Transaction ID are present in every request where authentication was performed. Missing values on any subset of authorisations represent a liability shift gap.

How are fallback and retry flows handled?

When an authorisation is declined and retried with a different acquirer, does the retry carry the original authentication values? Or does it retry without authentication context, effectively converting an authenticated transaction to an unauthenticated one? This is a common gap in orchestration implementations that handle retries at the routing layer without preserving authentication state.

What happens during 3DS Server downtime?

If your standalone 3DS Server experiences an outage, what is the fallback? A hard block on all transactions? A fallback to PSP-embedded authentication (with potential acquirer routing constraints)? Or unauthenticated flow (losing liability shift)? The fallback behaviour should be documented and tested, not discovered during an incident.

Authentication is still treated as an afterthought in most orchestration implementations. It should not be. The merchants with the strongest authorisation performance across their acquirer mix are the ones who decoupled authentication before adding acquirers, not after discovering that liability shift was breaking silently on routed transactions.