Why architecture matters here
The architecture matters because 3DS sits on the seam between two goals that pull in opposite directions: stopping fraud and not losing sales. Every challenge you show a cardholder is friction, and friction has a measurable, brutal conversion cost — a meaningful fraction of shoppers abandon a purchase the moment they are bounced to an OTP screen, hunt for their phone, or fail to receive the code. But every transaction you let through without authentication is a transaction where a fraud chargeback lands on you, the merchant. The 3DS design is an attempt to resolve this tension by moving the risk decision to the party with the best information — the issuer, who can see the cardholder's whole account history — and giving that issuer a rich enough data feed to make most decisions without bothering the customer.
That is why the data-collection step is architecturally central rather than incidental. In 3DS2 the merchant's 3DS Server gathers dozens of data elements — device fingerprint, browser characteristics, transaction amount and history, shipping/billing match, prior relationship with this cardholder — and packages them into the authentication request. The richer and more honest that bundle, the more confidently the issuer's risk engine can approve frictionlessly. A merchant that sends a thin, sloppy data bundle pushes the issuer toward challenging (or declining) out of caution, so poor integration directly buys you both more friction and more lost sales. The quality of your data feed is, in a real sense, your frictionless rate.
For agent-driven payments the tension sharpens. If an autonomous agent is completing a purchase, a challenge that assumes a human is watching the screen with their phone in hand can stall the whole flow — there may be no human present at that instant. The architecture therefore has to decide, up front, how authentication is delegated: whether the cardholder pre-authenticates and hands the agent a mandate, whether challenges are routed back to the human out-of-band, and which transactions can lean on exemptions to avoid a challenge entirely. Getting that wrong does not just cost a sale; it can strand an agent mid-task with no way to complete a payment it was authorized to make.
It helps to see why the liability shift, and not the fraud-catching itself, is the load-bearing part of the architecture. 3DS does not prevent fraud in any absolute sense — a sufficiently well-resourced attacker who controls both the card and the cardholder's phone can pass a challenge. What 3DS changes is who pays when fraud slips through, and that reallocation is what aligns everyone's incentives. Because liability moves to the issuer on an authenticated transaction, the issuer has every reason to invest in a good risk engine and to challenge only when the risk genuinely warrants it; and because the merchant is protected only when it authenticates properly, the merchant has every reason to send complete data and handle challenges well. The protocol is, in effect, a contract that makes the party best positioned to judge risk — the issuer, who sees the whole account — the party that bears it, in exchange for the data and control that authentication provides. Every architectural knob a merchant turns, from data richness to exemption strategy to how it routes agent challenges, is really a choice about where on that risk-allocation contract it wants to sit, and mis-turning any of them either leaks liability back onto the merchant or imposes friction the risk did not justify.
The architecture: every piece explained
Top row: the request path across the three domains. The merchant or agent initiates a payment and hands off to the 3DS Server — the merchant-side component that assembles the authentication request (AReq) from collected device and transaction data. The 3DS Server sends the AReq to the Directory Server, run by the card network, whose job is routing: it looks up which issuer owns the card range and forwards the request to that issuer's Access Control Server (ACS). The ACS is where the authentication decision actually happens — it belongs to the issuer and embodies the issuer's risk appetite and its relationship with the cardholder.
Middle row: the decision and its inputs. The device data — a browser fingerprint gathered by a hidden iframe, or an SDK fingerprint on a mobile app — feeds the ACS's risk model along with the transaction details. Based on the score, the ACS picks one of two paths. Frictionless: the risk is low enough that the ACS authenticates the transaction with no cardholder interaction and returns success immediately — the shopper never sees anything. Challenge: the risk is high or the issuer's rules require a step-up, so the ACS returns a challenge — a one-time passcode, a push to the issuer's banking app, or a biometric prompt — that the cardholder must complete. When authentication succeeds by either path, the ACS produces the proof tokens: the CAVV (Cardholder Authentication Verification Value, a cryptographic stamp) and the ECI (an indicator of the authentication outcome and who bears liability).
Bottom rows: turning authentication into a paid transaction. Authentication and authorization are separate steps — 3DS proves who the cardholder is; it does not move money. The CAVV and ECI are carried into the authorization message that flows from acquirer through the network to the issuer, where they signal that the transaction was 3DS-authenticated. That is what triggers the liability shift: with a valid CAVV and a qualifying ECI, a later fraud chargeback is the issuer's problem, not the merchant's. The ops strip is the discipline that keeps the economics positive — SLOs on challenge rate and challenge success, continuous tuning of the data bundle to maximize frictionless approvals, robust fallback when the ACS or Directory Server is unavailable, and a deliberate exemption strategy so low-risk transactions skip authentication without losing protection.
End-to-end flow
Walk a frictionless purchase, the common case. A shopper checks out for $60. The merchant's page has already run the 3DS method-data collection in the background, so the 3DS Server has a full device fingerprint. It builds the AReq — card, amount, device data, prior-transaction hints — and sends it to the network's Directory Server, which routes it to the issuing bank's ACS. The ACS's risk engine sees a known device, a modest amount, a shipping address that matches prior orders, and a healthy account; it scores the transaction low-risk and returns an authentication success with a CAVV and a frictionless ECI. Elapsed cardholder interaction: zero. The merchant now sends an authorization carrying the CAVV; the issuer approves it; the sale completes with liability shifted. The shopper experienced an ordinary checkout and never knew 3DS ran.
Now a challenge. A different shopper buys $1,200 of electronics from a device the issuer has never seen, shipping to a new address. The AReq flows the same way, but this time the ACS scores it risky and returns a challenge. The shopper's browser is handed a challenge URL; the ACS renders a step-up — 'we sent a code to your phone ending 4471'. The shopper enters the OTP, the ACS verifies it, and only now returns a CAVV with a challenged-and-authenticated ECI. Authorization proceeds with the proof, liability shifts, and the sale completes — a few seconds of friction bought protection on a genuinely risky order. The architecture spent friction exactly where the risk was and nowhere else.
The agent case adds a wrinkle. An AP2 shopping agent is authorized to buy a specific item up to a cap. When it reaches checkout, the merchant initiates 3DS. If the ACS returns frictionless, the agent completes the payment autonomously — ideal. If the ACS demands a challenge, the agent cannot type an OTP into a screen no human is watching. A well-designed agent-payment architecture anticipates this: either the cardholder pre-authenticated the mandate in a way the issuer recognizes (so the ACS is more likely to go frictionless), or the challenge is routed out-of-band to the human — a push to their banking app they can approve from their phone — while the agent waits. The transaction pauses at the challenge rather than failing, and resumes when the human approves.
Consider the failure that the liability shift is designed to absorb. Suppose the $1,200 order was in fact fraud — a criminal with a stolen card who somehow also had access to the OTP. Because the transaction was authenticated through 3DS with a valid CAVV and a qualifying ECI, when the real cardholder later disputes the charge, the chargeback lands on the issuer, not the merchant. The merchant keeps the goods loss exposure it always has, but the payment reversal — the part 3DS governs — is no longer its liability. That is the entire economic point: the merchant traded a small, tunable amount of checkout friction for the removal of a class of chargeback risk, and the issuer accepted that risk in exchange for the authentication data and control that 3DS gave it. Every architectural decision in the flow — how much data to collect, how aggressively to seek exemptions, how to handle challenges for agents — is ultimately a negotiation over where on that friction-versus-liability curve the merchant wants to sit.