## What Is 3DS Authentication Orchestration?
3DS authentication orchestration is the layer that decides which Access Control Server (ACS), which PSP, and which authentication flow handles a given transaction, instead of every transaction running through one hardcoded path. A standard [3D Secure](/glossary/#3d-secure) integration ties authentication to a single processor’s 3DS Server. Orchestration sits above that: it evaluates each transaction against exemption rules, historical approval data, and PSP availability, then routes the authentication request accordingly.
The distinction matters because 3DS2 was never designed as an all-or-nothing gate. EMVCo’s protocol supports frictionless flows, risk-based exemptions, and multiple valid paths to a liability shift. Most merchants running 3DS through a single PSP’s implementation use none of that flexibility, because the decision logic lives inside one processor’s ACS relationships. Orchestration is what makes the flexibility usable at the request level.
For a CTO evaluating this, the practical question isn’t “should we use 3D Secure” (SCA rules across the EU and UK already answer that). It’s whether authentication decisions live in one processor’s black box or in a layer you control across every processor you use.
## The Problem With Point-to-Point 3DS Integrations
Point-to-point 3DS means each PSP runs its own 3DS Server, its own exemption logic, and its own connection to card network directory servers. Add a second PSP and you’re maintaining a second, separate 3DS configuration with its own quirks, its own data field mapping, and its own performance characteristics.
Two failure modes show up repeatedly in this setup.
### Inconsistent frictionless rates across processors
One PSP’s 3DS Server might submit richer device and browser data to the ACS, earning more frictionless approvals. Another might submit a sparser payload and get challenged more often for identical transactions. According to [Gr4vy’s 2026 merchant guide](https://gr4vy.com/posts/what-is-3d-secure-3ds2-a-complete-merchant-guide-for-2026/), 10-30% of customers abandon at the challenge step in poorly optimized flows, and that abandonment rate can vary by processor for reasons that have nothing to do with actual fraud risk. A customer buying from the same card on the same day can get waved through frictionlessly on one PSP and challenged on another, purely because of how each PSP’s 3DS Server packages the authentication request.
### Silent liability-shift failures
When authentication and [authorization](/glossary/#authorization) are tightly coupled inside one PSP, the risk is contained. The moment a merchant tries to route authorization to a second [acquirer](/glossary/#acquirer) while authentication happened somewhere else, the authentication artifacts, ECI, CAVV or AAV, DS Transaction ID, ACS Transaction ID, have to carry across that boundary intact. If they don’t, [the liability shift breaks silently](https://www.pci-proxy.com/blog-posts/decouple-3ds-authentication-authorisation-payment-orchestration): the transaction still authorizes, the customer still gets charged, and nobody notices until [chargebacks](/glossary/#chargeback) start showing up on transactions that were supposed to be protected.
Neither failure mode is visible in a sandbox test. Both show up months later in production, usually as a slow authorization-rate drift or an unexplained chargeback pattern that takes a fraud analyst several weeks to trace back to a routing change made by an engineering team that had no reason to think of it as a 3DS problem.
There’s a third, quieter cost: engineering time. Each PSP’s 3DS Server has its own data field requirements, its own error codes, and its own quirks in how it reports challenge outcomes back to the merchant. A team running three PSPs point-to-point maintains three separate mental models of how 3DS behaves, and that maintenance burden grows every time a scheme updates its 3DS specification or a PSP changes its ACS connectivity.
## How Orchestration Decides Where a 3DS Request Goes
An orchestration layer treats each transaction as an independent routing decision rather than a fixed pipe to one PSP. The inputs to that decision typically include:
– **Exemption eligibility**: does this transaction qualify for low-value, trusted-beneficiary, or transaction risk analysis (TRA) exemption under PSD2, and is the PSP’s current fraud rate low enough to request it?
– **Historical frictionless performance**: which PSP/ACS combination has produced the best frictionless rate for this card BIN, region, or transaction profile over the last measurement window?
– **Data completeness**: does the merchant have the device fingerprint, browser metadata, and account history the ACS needs to make a frictionless decision, or will a thin payload force a challenge regardless of PSP choice?
– **PSP and ACS availability**: is the intended path currently healthy, or has it been degraded or failed over recently?
This is the same category of decision Orchestra’s [payment routing optimization](https://orchestrasolutions.com/payment-routing-optimization/) applies to authorization: route based on current, measured performance rather than a static configuration set once at integration time. Applied to 3DS, it means the exemption and challenge logic isn’t rewritten per PSP. It’s centralized, and every PSP the transaction might route to inherits the same rules.
The Access Control Server itself, the [issuer](/glossary/#issuer)-side component that actually approves or challenges the transaction, doesn’t change in this model. What changes is which 3DS Server and which merchant/PSP context reaches that ACS, and what data accompanies the request when it does. For background on the ACS role itself, see [what an Access Control Server does in 3DS](https://orchestrasolutions.com/what-is-an-access-control-server-in-3ds/). The routing rules are configured once, at the account or merchant-category level, and the orchestration layer applies them to every transaction that matches.
## Exemptions and Frictionless Flow: Reducing Unnecessary Challenges
[PCI DSS](/glossary/#pci-compliance)’s SCA exemptions exist specifically to reduce unnecessary friction, but a transaction only gets the benefit if the exemption is requested correctly and the acquirer qualifies for it. Four exemption categories do most of the work:
| Exemption type | Threshold | Condition |
|—|—|—|
| Low-value | Under €30 / £25 | Capped at 5 consecutive or €100 cumulative before SCA is required again |
| Transaction Risk Analysis (TRA) | Up to €500 | Scaled to acquirer’s rolling fraud rate: €100 at ≤0.13%, €250 at ≤0.06%, €500 at ≤0.01%; refreshed every 90 days |
| Trusted beneficiary | No limit | Cardholder has whitelisted the merchant with their issuer |
| Recurring transaction | Any amount | Applies to charges after the initial authenticated payment in a subscription series |
Getting the exemption request right matters more than most merchants assume. A merchant sending a 3DS2 authentication request without device fingerprint data, browser metadata, or account history signals gives the ACS no basis for a frictionless decision, and it defaults to a challenge regardless of exemption eligibility. Orchestration standardizes that data payload across every PSP in the stack, so the exemption logic doesn’t depend on which processor happens to be handling a given transaction that day.
The payoff shows up in the data. When Japan mandated 3DS for card-not-present transactions in April 2025, transaction volume through 3DS quadrupled, but 60% of that volume routed through the frictionless pathway and merchants saw a 93% average conversion rate, with dispute rates dropping more than 30% year over year, according to [Stripe’s analysis of 3DS trends in regulated markets](https://stripe.com/blog/3ds-trends-in-regulated-markets). The lesson from that data isn’t that mandatory 3DS is safe. It’s that correctly implemented exemption and frictionless logic determines whether mandatory 3DS costs you conversion or not. Stripe’s own data separately shows frictionless authentication flows grew 40% in the first half of 2024 even as 3DS request volume rose 15%, and merchants running optimized 3DS2 flows see authorization rates increase 5-10%, per [Ixopay](https://www.ixopay.com/blog/how-to-reduce-authentication-failures-and-improve-conversion-rates-with-3ds).
## What Happens When an ACS or PSP Times Out
Even mature PSPs and issuers have ACS timeouts, especially during peak load. In a single-PSP setup, an ACS timeout typically ends the transaction: the customer sees a decline or an error, and retrying means starting the authentication flow over from the beginning.
Orchestration changes the failure mode by detecting the timeout and rerouting to an alternate PSP/ACS path rather than surfacing a hard decline. This is the same waterfall logic used for processor declines applied to the authentication step specifically: processor A errors or times out on the 3DS request, and the orchestration layer immediately attempts the equivalent request through processor B, without asking the customer to re-enter payment details or restart checkout.
This is also where compliance scope and operational risk intersect. Handling ACS/PSP failover consistently, and doing it in a way that doesn’t quietly break the liability shift, is one of the reasons merchants outsource this layer rather than building failover logic PSP-by-PSP. Orchestra’s [payments compliance outsourcing](https://orchestrasolutions.com/payments-compliance-outsourcing/) service covers exactly this kind of cross-PSP consistency, alongside PCI DSS Level 1 and ISO 27001 obligations that apply regardless of which PSP ultimately processes a given transaction.
Building this failover logic in-house means instrumenting timeout detection for every PSP’s ACS connection separately, since timeout thresholds and error codes aren’t standardized across processors. A team has to decide, per PSP, what counts as a timeout worth failing over versus a slow-but-successful authentication, and get that threshold wrong in either direction: too aggressive and healthy transactions get rerouted unnecessarily, adding latency; too conservative and customers sit through a stalled challenge screen before anything happens.
## Carrying Authentication Context Across PSPs
The technical core of 3DS orchestration is preserving four data elements as a transaction moves from authentication to authorization, potentially across a PSP boundary:
– **ECI (Electronic Commerce Indicator):** signals the authentication outcome to the acquiring bank
– **CAVV or AAV (Cardholder/Accountholder Authentication Verification Value):** the cryptographic proof of authentication generated by the ACS
– **DS Transaction ID:** the Directory Server’s identifier for the authentication session
– **ACS Transaction ID:** the issuer ACS’s own identifier for the session
When authentication and authorization happen inside the same PSP, those four values transfer invisibly. When they don’t, because the orchestration layer authenticated through one PSP and routed authorization to a different acquirer with better current rates or healthier status, all four have to travel with the transaction intact. This is what “agnostic 3DS” or “external MPI” architectures are built around: authenticate once, before processor selection, then carry that result through whichever authorization path the routing layer chooses.
The practical benefit is retry behavior. If a payment fails after authentication and the orchestration layer waterfalls to a second processor, the customer doesn’t get re-challenged. The authentication already happened; only the authorization path changed. Without preserved authentication context, every retry becomes a second challenge, and the conversion benefit of automatic retry logic gets eaten by repeated friction.
Reuse isn’t automatic across every acquirer, though. Whether a second PSP will accept an authentication result generated somewhere else depends on that PSP’s own scheme certification and its willingness to process third-party authentication data. Some acquirers require a direct connection to the Directory Server for a given card scheme before they’ll accept CAVV or AAV values they didn’t generate themselves. This is why scheme certification, not just software configuration, ends up being a real constraint on how much waterfall flexibility a multi-PSP 3DS setup actually has. Checking that certification status per PSP, per card scheme, before relying on cross-PSP authentication reuse is worth doing during PSP onboarding rather than discovering the gap during an incident.
## Where Orchestra Fits
[Orchestra](https://orchestrasolutions.com/) handles 3DS as part of the same routing layer that handles processor selection and failover, not as a separate product a merchant has to integrate and maintain on its own. Orchestra’s [integrations directory](https://orchestrasolutions.com/integrations/) lists 3D Secure Support and PSD2 Strong Customer Authentication among its connection categories, meaning 3DS2 authentication runs through the same JavaScript library integration that handles PSP routing.
Orchestra sits in the 3DS Server / requestor-side role. It does not operate the ACS, since ACS is issuer-side infrastructure by definition and no orchestration vendor changes that. What Orchestra does change is the number of separate 3DS integrations a team has to build and maintain: one integration point applies consistent exemption logic, consistent data field handling, and consistent failover behavior across however many PSPs a business connects to, rather than a bespoke 3DS configuration per processor.
For a CTO comparing the three main implementation approaches, the trade-off comes down to where the maintenance burden sits:
| Approach | How it works | Maintenance implication |
|---|---|---|
| PSP-managed | Each processor runs its own 3DS Server and exemption logic | N separate 3DS configurations for N processors; inconsistent frictionless rates |
| Standalone 3DS Server | A dedicated 3DS provider sits between the merchant and the PSPs | Centralizes logic but adds a vendor relationship on top of existing PSP integrations |
| Orchestration-managed | 3DS logic lives inside the same orchestration layer as PSP routing and failover | Adding a PSP doesn’t mean adding a 3DS integration; one layer, one config |
## Frequently Asked Questions
### What is 3DS authentication orchestration?
It’s the layer that decides which ACS, PSP, and 3DS flow handles each authentication request, instead of hardcoding a single path per integration.
### How is this different from a standard 3DS2 integration?
A standard integration sends every transaction through one PSP’s 3DS Server. Orchestration evaluates each transaction and routes it dynamically, applying exemptions, selecting the best-performing path, and handling failover, across multiple PSPs and ACS providers.
### Does 3DS orchestration replace my 3DS Server?
No. It sits above the 3DS Server layer and decides which provider’s 3DS Server handles a given request. The underlying EMV 3DS protocol and ACS relationships stay intact.
### What happens if an ACS times out mid-authentication?
Orchestration detects the timeout and reroutes to an alternate PSP/ACS path rather than returning a hard decline. Without orchestration, a single ACS timeout typically ends the transaction and forces the customer to restart checkout.
### Can 3DS orchestration work across multiple PSPs at once?
Yes, that’s the primary use case. One integration point routes 3DS requests across however many PSPs a business uses, rather than maintaining a separate 3DS integration per processor.
### Does adding 3DS orchestration increase PCI DSS scope?
No, as long as the orchestration layer doesn’t touch raw PAN data. Cardholder data flows through the PSP and ACS; the orchestration layer sees routing metadata and authentication results, not card numbers.
### What authentication artifacts need to carry across PSPs for the liability shift to hold?
ECI, CAVV or AAV, DS Transaction ID, and ACS Transaction ID all have to pass intact from authentication through to authorization. If any of them break across a routing boundary, the liability shift fails silently, and the first sign is usually an unexplained chargeback pattern.
