3D Secure 2 (EMV 3DS) Architecture: Frictionless Flow, Risk-Based Authentication and Liability Shift (2026)

Disclaimer: this article is a systems and architecture analysis, not legal, compliance, financial or investment advice. Rules differ by region, scheme and issuer; confirm them with your acquirer and counsel.

A card payment on the web looks like one click, but under it sits a negotiation between four organisations that have never met your customer. The merchant wants the sale to complete. The acquirer wants fraud losses contained. The card scheme wants network-wide rules honoured. The issuer, who actually knows the cardholder, wants to be sure it is really them. The protocol that lets those four parties talk about identity in the middle of a checkout is 3D Secure 2, standardised by EMVCo as EMV 3-D Secure.

Its design bet is simple: exchange so much risk data in the background that most payments never need to interrupt the customer, and challenge only the ones that look wrong. When that bet pays off you get frictionless authentication and a liability shift in your favour. When it fails you get timeouts, abandoned challenges and a checkout that quietly leaks revenue.

What this covers: the actors and message flow, the data the issuer scores, how the frictionless-or-challenge decision is made, PSD2 exemptions, liability shift rules, orchestration and delegated authentication, failure modes, and a merchant integration reference design.

Context and Background

The first generation, 3-D Secure 1.0, was introduced around 2001 and gave the protocol its name: the “three domains” are the issuer domain, the acquirer domain and the interoperability domain run by the schemes. In practice most people remember it as a full-page redirect to a bank page asking for a static password or a one-time code. It worked as a fraud control and as a liability instrument, but it was a conversion killer. It was designed for desktop browsers, it carried very little data, and it forced the same friction on a low-risk repeat customer as on a stranger.

EMVCo, the body owned by the major card schemes that maintains the EMV chip specifications, took over the standard and published EMV 3-D Secure in several releases. The commonly deployed versions are 2.1.0, 2.2.0 and 2.3.1; the EMVCo 3-D Secure specification pages currently list 2.2.0 and 2.3.1. Version 2.2.0 added the data and flows needed for the European Strong Customer Authentication rules, including exemption indicators and decoupled authentication. Version 2.3.1 extended the standard with further out-of-band and app-switching options and support for newer authentication methods. I will not claim a full changelog here, because the authoritative detail sits in the licensed specification documents rather than in public summaries.

Two forces pushed the migration. The first was mobile: 3DS1 had no native app experience, so merchants wrapped web views around bank pages and watched abandonment climb. The second was regulation. The EU’s second Payment Services Directive (PSD2) and its Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA), applied from September 2019 with a long enforcement runway, required two-factor authentication for most electronic payments inside the European Economic Area, with defined exemptions. A protocol that could carry exemption requests and risk data was no longer optional. The schemes subsequently retired 3DS1 support; as a rule of thumb, treat any 3DS1 dependency as legacy and verify current scheme dates directly.

If you are looking at the same problem from the cardholder-credential side, our deep dive on passkeys, FIDO2 and PSD2 SCA architecture covers what happens when the authentication factor itself becomes phishing-resistant. For the economics that sit behind routing and authorisation decisions, see interchange fees and least-cost routing.

Here is the thesis I will defend throughout. 3DS2 is best understood not as a “verification step” but as a risk-data exchange protocol with an optional human in the loop. Most engineering problems in production come from treating it as the opposite, an authentication pop-up that you bolt on at the end of checkout. If you design it as a data pipeline with latency budgets, fallbacks and observability, the challenge rate, authorisation rate and liability position all become tunable. If you design it as a pop-up, you inherit whatever the issuer’s default is.

The Core Architecture: Actors and the 3DS2 Message Flow

Direct answer: in EMV 3DS the merchant’s 3DS Server sends an Authentication Request (AReq) through the scheme’s Directory Server to the issuer’s Access Control Server (ACS). The ACS scores risk and answers frictionless (authenticated or not) or challenge. If challenged, the customer authenticates through the SDK or a browser frame, and the result returns to the merchant as an authentication value used in authorisation.

Figure 1: EMV 3DS reference architecture. The Directory Server is the routing hub; the ACS is where the risk decision and any challenge live.

Figure 1 shows the logical roles. Each box has a precise EMVCo name, and mixing them up is the most common source of confusion in integration meetings, so it is worth being exact.

The actors, in EMVCo terms

The 3DS Requestor is the merchant or payment facilitator environment that wants the cardholder authenticated: the website checkout or the mobile app. The 3DS Requestor Environment also includes the 3DS SDK when the channel is an app, a library embedded in the merchant app that collects device data and renders the challenge UI.

The 3DS Server is the component that speaks the protocol on the requestor’s behalf. It builds the AReq, validates messages, and talks to the Directory Server. Most merchants do not run their own; they consume it from a payment service provider or a certified vendor. The 3DS Server must be EMVCo-approved and the SDK likewise, which is a real procurement constraint if you ever consider building your own.

The Directory Server (DS) is operated by each card scheme. It keeps the table of which card ranges are enrolled and which ACS serves them, routes requests to the right ACS, and brokers results. The Access Control Server (ACS) belongs to the issuer, or to a vendor acting for it. This is the system that holds the risk engine, runs the challenge and produces the cryptographic proof of authentication. The interoperability domain is the DS plus the rules that make different schemes’ flows behave consistently.

The messages

The flow uses a small set of named messages, all JSON over HTTPS with mutual TLS between the 3DS Server, DS and ACS.

Message	Direction	Purpose
PReq / PRes	3DS Server to DS and back	Fetch the card-range cache and 3DS Method URLs so the server knows which BINs are enrolled
AReq	3DS Server to DS to ACS	Authentication request with transaction, cardholder and device data
ARes	ACS to DS to 3DS Server	Result: frictionless outcome or instruction to challenge
CReq	Browser or SDK to ACS	Challenge request, starting the challenge session
CRes	ACS to browser or SDK	Challenge screen content, or final status
RReq / RRes	ACS to DS to 3DS Server and back	Results request: final outcome after a challenge
Erro	Either side	Protocol error report

The sequence for a browser payment is the following. First the 3DS Server may trigger the 3DS Method: an invisible iframe that loads an ACS-provided URL so the issuer can run its own device-fingerprinting script before the AReq, and so that the 3DS Server learns whether the method completed. Then the server sends the AReq. The ARes returns a transStatus value. Y means authenticated, N means not authenticated, U means unable to authenticate, A means an attempt was processed, R means rejected, and C means a challenge is required. Version 2.2 also defines D (decoupled authentication in progress) and I (informational only, where the ACS has been told not to authenticate). The mapping to scheme authorisation fields is covered below.

When the ARes says C, the ACS includes a challenge URL (browser) or the information the SDK needs (app). The cardholder interacts with the issuer’s UI, the ACS sends an RReq to the 3DS Server through the DS, and the 3DS Server acknowledges with an RRes. Only then does the requestor proceed. The CRes is how the client learns that the challenge is complete.

Figure 2: Challenge-flow sequence. The frictionless path ends at the first ARes; the challenge path adds CReq, CRes and RReq.

Why the architecture routes through the Directory Server

A merchant could in theory call the issuer directly. The DS exists because the merchant cannot know every issuer’s ACS endpoint, because schemes need to enforce certificates and rules centrally, and because it provides a place to measure and police behaviour. It also creates a dependency: when a scheme DS has an incident, every merchant authenticating cards from that scheme is affected, regardless of how healthy their own stack is.

Channels: app, browser and requestor-initiated

The protocol defines three device channels. The app-based channel (01-APP) uses the SDK. The browser-based channel (02-BRW) uses the 3DS Method plus a challenge iframe sized to one of a few standard dimensions. A 3DS Requestor Initiated channel (03-3RI) covers authentications with no cardholder present, used for things like recurring payment tokens and account verification. Each channel affects what data is available. A browser channel hands the ACS a user agent, screen dimensions, time zone and language, and an app channel can provide a much richer and more tamper-resistant device profile through the SDK.

One more category matters for compliance: the message category. A payment authentication (PA, category 01) is tied to a purchase amount. A non-payment authentication (NPA, category 02) verifies the cardholder for something like adding a card to a wallet or confirming account holder status, with no amount. Mixing them up leads to exemption logic being applied where it makes no sense.

Deeper Analysis: Data, Risk Decisions, Exemptions and Liability

The data the issuer scores

The headline improvement of 3DS2 over 3DS1 is data. EMVCo describes the standard as carrying far more data elements per transaction than its predecessor (the often-quoted figure is “over 100”; check the current specification for an exact count rather than trusting a marketing number). They fall into a few groups.

Cardholder and account data: name, billing and shipping address, email, phone numbers, and the cardholder account information block. That block is where a merchant describes its own relationship with the buyer: account age, days since last password change, number of purchases in the past six months, whether the card was added to the profile recently, and whether the merchant has already flagged suspicious activity. For an issuer, “this card has been used on this merchant account for three years” is a very strong signal.

Transaction data: amount, currency, purchase date, shipping indicator (to billing address, to a different address, digital goods, pick up in store), delivery timeframe, reorder indicator and pre-order flags. Merchant risk indicators like these are exactly what a fraud analyst checks by hand.

Device data: for the browser channel, the data collected by the 3DS Server (user agent, screen colour depth, Java and JavaScript flags, time zone offset, accept headers, IP address) plus whatever the ACS gathers via the 3DS Method. For the app channel, the SDK builds an encrypted device-information blob that only the ACS can read, which includes platform, OS version and a range of device parameters. Because the blob is encrypted with the ACS’s public key, intermediaries cannot read it.

Authentication-context data: the 3DS Requestor Challenge Indicator is where the merchant states its preference and, in Europe, signals exemptions. It has values from 01 to 09 in version 2.2: no preference, no challenge requested, challenge preferred by the requestor, challenge mandated by regulation, no challenge requested because a transaction risk analysis was performed, no challenge requested for data-share only, no challenge because SCA was already performed, no challenge because a trusted-beneficiary exemption applies, and challenge requested to prompt the cardholder to whitelist the merchant. The key detail: it is a request. The issuer decides.

From data to decision: how an ACS chooses frictionless or challenge

The ACS runs a risk engine that is entirely issuer-specific; the standard defines inputs and outputs, not the model. Issuers typically combine rules, historical profiles and a machine-learning score. The same card used on the same device at the same merchant at a normal amount is low risk. A first-time device, a shipping address never seen, a high-value electronics order at 3 a.m. and a mismatch between IP geography and billing country push the score up.

The ACS then maps the score to one of four actions: approve frictionlessly (Y), decline or reject (N/R), challenge (C), or fall back to an attempt (A) when authentication is not possible but proof of attempt can be issued. Within a challenge the ACS chooses the method: an in-app approval push, a one-time passcode by SMS, a biometric via the banking app, or a knowledge factor. The cardholder experience of that challenge is the issuer’s product, not the merchant’s.

Two things are easy to miss. First, the decision includes regulatory logic. If an exemption is requested but the issuer’s policy says to mandate a challenge, it will challenge, and the merchant has no way to override it. Second, issuer behaviour varies enormously. Challenge rates can differ widely across issuers for similar traffic. Treat any single published average with suspicion, and measure your own by BIN.

Figure 3: Decision flow combining merchant-side exemption logic with issuer-side risk scoring. The merchant proposes; the issuer disposes.

Strong customer authentication exemptions

PSD2 requires SCA, meaning two of three independent elements (knowledge, possession, inherence), for most electronic payments where both issuer and acquirer are in the EEA. The RTS lists exemptions. Those that matter for card checkout are below, with thresholds from the EBA RTS as I understand them; confirm in the regulation text and with your acquirer, because national implementations and issuer policy modify how they work in practice.

Exemption	Rule in summary	Who applies it	Liability if fraud
Low value (RTS Art. 16)	Single payment up to EUR 30, issuer counters force SCA after cumulative EUR 100 or 5 consecutive uses	Issuer counts; acquirer may request	Issuer or acquirer side as exempted, no shift to issuer by authentication
Transaction risk analysis (RTS Art. 18)	Fraud rate bands: up to 0.13 percent allows EUR 100, up to 0.06 percent allows EUR 250, up to 0.01 percent allows EUR 500	PSP (acquirer or issuer) whose own fraud rate qualifies	Falls on whoever applied the exemption
Trusted beneficiary (Art. 13)	Cardholder adds merchant to issuer-held list after SCA	Issuer	Without SCA at transaction time, merchant side bears risk
Recurring, same amount (Art. 14)	First payment needs SCA; later fixed-amount payments exempt	Issuer	Depends on the first authentication
Secure corporate payments (Art. 17)	Dedicated corporate processes and protocols	Issuer	Issuer discretion
Merchant-initiated transactions	Out of scope of SCA when cardholder is not present, after an SCA’d mandate	Merchant	Mandate must have been established with SCA

The transaction risk analysis row deserves a longer look, because it shifts the architecture. The fraud-rate bands apply to a payment service provider’s own reference fraud rate over a rolling window, calculated for card payments separately from other payment types. If the acquirer’s fraud rate for the quarter sits above the band, it loses the right to request TRA exemption at that value until the rate recovers. That makes exemption policy a shared risk: your merchant’s fraud behaviour can influence your acquirer’s ability to exempt other merchants.

The practical implication is that the merchant side usually asks for an exemption through the challenge indicator, the acquirer or PSP decides if it qualifies, and the issuer may still say no. Merchants who send 05 (TRA performed) everywhere to avoid challenges frequently see issuers apply SCA anyway and see their own fraud ratio rise, which in turn endangers the bands. Exemption strategy is therefore a controlled experiment, not a switch.

The data-only flow (indicator 06) is a useful middle path for regions without mandatory SCA, such as the United States. The merchant shares rich data with the issuer without asking for authentication. The issuer gets better risk signals for authorisation without any friction, and the merchant does not receive a liability shift. It is one of the least-used and most underrated features.

Liability shift

Liability shift is the commercial reason merchants adopt 3DS. When a transaction is authenticated through 3DS and the result is carried correctly through authorisation, chargebacks coded as fraud (such as Visa reason code 10.4 and Mastercard 4837 for card-not-present fraud) are generally the issuer’s responsibility rather than the merchant’s. The scheme rule sets are precise and change. As a rule:

A fully authenticated transaction (Y) normally shifts fraud liability to the issuer.
An attempted authentication (A, issuer or DS unable to authenticate but proof of attempt generated) also generally shifts it, because the merchant did everything the scheme asked.
Failed (N), unavailable (U) and rejected (R) results do not shift liability, and N and R should normally end in a decline.
Exempted transactions do not shift liability to the issuer. If you ask for the low-value or TRA exemption and fraud occurs, it comes back to the party that took the exemption.

The wiring detail matters. The ACS returns an Authentication Value (a CAVV for Visa, an AAV or UCAF value for Mastercard) and an Electronic Commerce Indicator (ECI). The merchant must pass both, plus the DS Transaction ID (and in version 2.x the protocol version), into the authorisation message. Typical ECI values for fully authenticated payments are 05 for Visa and 02 for Mastercard, with 06 and 01 for attempts. A merchant who authenticates correctly and then forgets to forward the cryptogram to its gateway has done the work and forfeited the shift. This wiring bug is a classic integration failure.

Liability shift is also not a general shield. It covers the fraud chargeback categories, not “item not received,” not merchant disputes, and not friendly fraud claims the issuer chooses to treat as service disputes. It does not stop a card-testing attack from consuming your authentication budget. And a shift is only as good as the scheme programme you are in: some merchant categories, card types or regions are excluded, so read your acquirer’s rules.

Worked example: what a challenge rate does to conversion

Take illustrative numbers, not measurements. A merchant processes 100,000 EEA card checkouts a month with an average order of EUR 80. Suppose a flat 100 percent challenge policy (as in a 3DS1-style rollout) sees 12 percent of customers abandon the challenge, so 88,000 complete. With risk-based flow, assume 85 percent frictionless and 15 percent challenged, and the same 12 percent abandonment applying only to challenged traffic: abandoned checkouts fall to 1,800, so 98,200 complete. The recovered 10,200 orders at EUR 80 are EUR 816,000 of gross merchandise value per month. These figures are made up to show the arithmetic; your frictionless rate depends on issuer mix, data quality, and exemption eligibility, and your abandonment rate depends on the issuer’s challenge UX. The point is that conversion economics hinge on two numbers you can measure: the frictionless rate and the challenge abandonment rate, both segmented by issuer BIN.

Contrast that with a model where the merchant loses the liability shift. If fraud on exempted transactions is 0.10 percent of GMV and the merchant exempts EUR 4,000,000 per month, then expected fraud cost is EUR 4,000 a month plus chargeback fees. Whether this beats the conversion benefit is a spreadsheet question for your own numbers, which is exactly why instrumentation comes first.

Orchestration, Delegated Authentication and Passkeys

3DS inside payment orchestration

Most merchants of any size do not talk to a single acquirer. They sit behind a payment orchestration layer that routes between PSPs, retries declines, and applies local-payment-method logic. 3DS complicates that, because the authentication result is bound to a specific DS Transaction ID and ACS Transaction ID, and the cryptogram can generally be reused only for the authorisation it was issued for.

There are two architectures. In the PSP-bundled model the PSP performs 3DS and authorisation together; it is simple but locks authentication to that PSP. In the standalone 3DS Server model the merchant (or orchestrator) runs authentication independently, then passes the authentication data to any acquirer. The second approach, sometimes called “external MPI” or “bring your own 3DS”, enables routing the authorisation to the cheapest or best-converting acquirer after authentication, which links directly to the cost logic in least-cost routing. The price is that you now own the protocol edge cases: version negotiation, method timeouts, retry semantics, and certificate rotation.

A subtle design issue is when to authenticate relative to fraud screening. Run your own risk engine first. If it says “block,” skip 3DS and save the DS call. If it says “low risk,” send the AReq with an exemption request and let the issuer confirm. If it says “uncertain,” ask for the challenge. This ordering makes 3DS the tiebreaker rather than the first line of defence.

Delegated authentication

Version 2.2 introduced a path to delegated authentication: the issuer’s ACS can delegate the authentication step to a third party, typically a wallet or a merchant whose own app has strong customer authentication, and accept the result. The delegate authenticates the user with its own biometrics and device binding, and the ACS treats that as the second factor. For the merchant this looks like a frictionless flow with data indicating the delegate. It is useful for wallets and super-apps, but it requires agreement between issuer and delegate, so availability is limited and uneven.

Passkeys, FIDO and Secure Payment Confirmation

The more promising 2.3-era direction is binding strong, phishing-resistant authenticators to the challenge. The EMVCo pages list WebAuthn and Secure Payment Confirmation (SPC) among supported challenge flows. SPC is a W3C web standard that lets a merchant page request that the browser show a native, issuer-bound payment confirmation using a FIDO credential, displaying the payee and amount in browser-controlled UI. If a cardholder has a passkey registered with their issuer, the challenge becomes one biometric tap instead of an SMS code typed from another app.

The architecture consequences are significant. The credential lives with the issuer’s relying-party identity, the 3DS flow carries the assertion, and the 3DS Server mostly relays. Our companion piece on FIDO2 and passkey payment authentication works through the registration and assertion details, and shows why one-time-passcode SMS is the weakest link in an otherwise modern flow. Adoption depends on issuers enrolling credentials, which is slow and uneven, so plan for passkeys as an upgrade path within the same protocol rather than as a replacement.

Adjacent rails

3DS applies to card rails. Account-to-account instant payments follow a different authentication and fraud model, with payee verification and push-payment fraud concerns. If your checkout offers both, the contrast is useful, and our analysis of instant payment fraud architecture across SEPA Instant, FedNow and RTP shows where responsibility falls when there is no chargeback and no liability shift at all.

Merchant Integration Reference Design

A production integration is a small distributed system with its own latency budget, state machine and telemetry. This section lays out the version I would build for a merchant that owns its checkout and wants control over authentication.

Component layout

The checkout front end (web and mobile) talks to a payments service. The payments service owns a 3DS orchestrator module with four responsibilities: version and eligibility detection, AReq assembly, challenge handling, and result binding to authorisation. Behind it sit a certified 3DS Server (vendor or PSP), the card-range cache fed by PReq/PRes, and the authorisation connector to one or more acquirers. A decision log records each authentication attempt with BIN, issuer, channel, exemption requested, ARes status, challenge outcome and final authorisation result.

The state machine is the heart of it. A payment attempt moves through: CREATED, ELIGIBILITY_CHECKED, METHOD_PENDING (browser only), AUTH_REQUESTED, then one of FRICTIONLESS_OK, CHALLENGE_REQUIRED, AUTH_FAILED or AUTH_UNAVAILABLE. From CHALLENGE_REQUIRED it goes to CHALLENGE_IN_PROGRESS and then to CHALLENGE_OK, CHALLENGE_FAILED or CHALLENGE_ABANDONED. Only then does it reach AUTHORISING, and finally AUTHORISED or DECLINED. Every transition is idempotent and persisted, because the browser can reload during a challenge and the RReq may arrive before or after the client returns.

What the AReq looks like

The following is a heavily trimmed, illustrative AReq fragment to show the shape. Field names follow the EMVCo naming convention, but the values are invented, and a real message includes many more mandatory fields and is subject to the exact schema of the version you negotiate.

{
  "messageType": "AReq",
  "messageVersion": "2.2.0",
  "messageCategory": "01",
  "deviceChannel": "02",
  "threeDSRequestorAuthenticationInd": "01",
  "threeDSRequestorChallengeInd": "05",
  "threeDSCompInd": "Y",
  "purchaseAmount": "8000",
  "purchaseCurrency": "978",
  "purchaseExponent": "2",
  "acctNumber": "<tokenised or PAN>",
  "browserAcceptHeader": "...",
  "browserIP": "203.0.113.7",
  "browserLanguage": "en-GB",
  "browserTZ": "-60",
  "browserUserAgent": "...",
  "acctInfo": {
    "chAccAgeInd": "05",
    "nbPurchaseAccount": "14",
    "suspiciousAccActivity": "01"
  },
  "shipIndicator": "01",
  "notificationURL": "https://pay.example.com/3ds/notify"
}

Notice threeDSCompInd: it tells the ACS whether the 3DS Method completed, which materially affects how much device data the issuer has. Missing or timed-out method results are a frequent cause of unexpectedly high challenge rates.

Handling the flow in code

A condensed orchestration function shows the decision logic. It is pseudocode in Python style for clarity, not a library call.

def authenticate(payment, risk):
    if risk.action == "block":
        return Decline("risk_block")

    rng = card_range_cache.lookup(payment.bin)
    if not rng.supports_3ds2:
        return fallback_policy(payment, reason="range_not_enrolled")

    ind = choose_challenge_indicator(payment, risk, regulation=payment.region)
    areq = build_areq(payment, challenge_ind=ind, method_done=payment.method_done)

    ares = threeds_server.authenticate(areq, timeout_s=12)   # budget, see below
    if ares is Timeout:
        return fallback_policy(payment, reason="ds_timeout")

    status = ares.trans_status
    if status == "Y" or status == "A":
        return Proceed(cavv=ares.auth_value, eci=ares.eci, dsTransId=ares.ds_trans_id)
    if status == "C":
        return Challenge(ares.acs_url, ares.acs_trans_id)   # then wait for RReq
    if status in ("N", "R"):
        return Decline("auth_failed")
    return fallback_policy(payment, reason="unable_to_authenticate")  # U or other

Two details deserve attention. The timeout budget must be tuned against the protocol’s own timeouts: the standard gives the DS and ACS tight response windows (on the order of ten seconds for the ACS to answer an AReq, with the 3DS Server allowing slightly longer), so your overall wait should sit just above the combined chain rather than hang for a minute. And fallback_policy is where business risk lives: you can decline, you can proceed without authentication and accept liability, or you can retry on another route. That choice should be explicit, configurable by amount and risk tier, and logged.

Latency and capacity thinking

Treat 3DS as a synchronous dependency with three distinct latency hops: the method (browser only, usually a small number of seconds at most before you give up), the AReq/ARes round trip (typically a second or two, with a long tail driven by the issuer ACS), and the human challenge (tens of seconds, up to a protocol maximum challenge timeout which the specification sets at a minimum of five minutes for ACS sessions). The first two are infrastructure problems you can instrument. The third is a UX problem you can only influence by choosing when to challenge.

For capacity, the numbers are modest: one AReq per checkout attempt, not per page view. A merchant doing 50 checkouts per second at peak sends around 50 AReqs per second, which is trivial for the 3DS Server but not trivial for the downstream issuer on a sale day. Because the ACS is outside your control, the right protection is the resilience toolkit described in our post on retries, backoff with jitter and circuit breakers: a per-issuer circuit breaker that opens when a given BIN range’s ACS starts timing out, so you stop paying a 12-second penalty on every attempt.

Observability that pays for itself

Log and graph these, segmented by issuer, BIN range, channel, device and country: frictionless rate, challenge rate, challenge completion rate, abandonment rate, AReq timeout rate, U rate, authorisation success rate after authentication, and the ratio of exemption requested to exemption honoured. Authorisation rate after 3DS is the number the business actually cares about. A drop in the frictionless rate for one issuer is an issuer-side change; a drop across all issuers for browser traffic is probably your 3DS Method iframe being blocked by a content-security-policy change you shipped.

Trade-offs, Gotchas, and What Goes Wrong

Figure 4: Where a 3DS2 flow breaks and where a fallback policy has to decide. Each branch is a business risk decision, not just an error handler.

ACS and DS outages and timeouts. The issuer ACS is the most common point of failure and you cannot fix it. When it times out, the ARes never arrives. The safe response is a configured fallback, not an unconditional decline: for a low-value, low-risk order a merchant may choose to proceed without authentication and accept liability, while for a high-value order it declines or asks the customer to try another card. Without a circuit breaker you will pay the timeout on every attempt against a failing issuer.

Challenge abandonment. A challenge asks the customer to leave your page’s context, switch apps, wait for an SMS, or remember a credential. Abandonment depends heavily on method: in-app biometric approval is far smoother than a one-time passcode texted to an old phone number. You can reduce unnecessary challenges but you cannot design the challenge. If one issuer’s abandonment is poor, the lever you have is exemption eligibility and sometimes routing the customer to a different payment method.

Browser-specific breakage. The 3DS Method runs in a hidden iframe on the issuer’s domain. Third-party cookie restrictions, strict content-security policies, ad blockers and in-app browsers can block it, leaving the ACS with no device data. The challenge itself runs in an iframe whose size must match one of the standard sizes, and layouts that clip it on small screens cause failed challenges that look like customer error.

Data quality. Sending empty or placeholder fields to pass validation degrades risk scoring. The protocol’s mandatory-versus-optional rules vary by region and by scheme, and issuers may reject messages with inconsistent data. Sloppy account-age or shipping fields can make your honest customers look anomalous.

Exemption overreach. Requesting TRA or low-value exemptions on everything raises your fraud exposure and can push your acquirer’s fraud rate over a band, removing exemption rights for you and its other merchants. The exemption indicator is a request; many issuers still challenge.

Liability confusion. Merchants often assume 3DS means “no chargebacks.” Liability shift covers specific fraud reason codes under specific scheme rules. Friendly fraud, merchandise disputes and subscription disputes remain yours. Merchant-initiated recurring payments rely on the original authentication or mandate; if the first payment was not properly authenticated, subsequent charges are exposed.

Replay and binding. The authentication value is bound to the transaction details. Changing the amount after authentication, splitting an order, or re-using a cryptogram for a retry on a different acquirer can invalidate it or break the liability shift. Orchestration retries must therefore be designed around which fields the cryptogram covers.

Regulatory drift. The PSD2 framework is in the process of revision in the EU, with proposals for a Payment Services Regulation and a third directive that update fraud-liability and SCA provisions. I would not hard-code any exemption threshold: keep thresholds in configuration, cite the source in the config comment, and review them when regulation or scheme rules change.

Practical Recommendations

Start by treating 3DS2 as telemetry-driven infrastructure. Before tuning anything, instrument the funnel from checkout start to authorised payment, segmented by issuer and channel, because the aggregate hides the problem cases.

Second, send the best data you can. Fill the cardholder account information block honestly, pass correct shipping indicators and keep the 3DS Method working. Rich, accurate data is the only lever that lowers challenge rates without increasing fraud.

Third, use exemptions deliberately. Gate TRA requests on your own risk score and your acquirer’s current eligibility, start with a small share of traffic, and compare fraud, challenge and authorisation rates against a control. Never apply exemptions to first-time recurring mandates.

Fourth, make fallback an explicit policy by amount and risk tier, protected by per-issuer circuit breakers and bounded timeouts. Fifth, wire the result correctly: pass the authentication value, ECI, protocol version and DS Transaction ID into authorisation, and test that path on every acquirer.

Finally, keep the standard moving. Plan for 2.3.x features, passkeys through SPC, and delegated authentication as they appear in your issuers’ behaviour.

Checklist:

[ ] Frictionless, challenge, abandonment and timeout rates tracked per issuer BIN and channel
[ ] Authentication value, ECI, version and DS Transaction ID forwarded in authorisation, verified per acquirer
[ ] Fallback policy defined by amount and risk tier, with logs
[ ] Per-issuer circuit breaker and bounded timeouts around the AReq
[ ] 3DS Method iframe and challenge iframe tested across browsers, in-app browsers and sizes
[ ] Exemption thresholds in configuration with source references and review dates
[ ] First recurring payment authenticated with SCA; MIT flows flagged correctly
[ ] Idempotent state machine that tolerates reloads and late RReq messages

Frequently Asked Questions

What is 3D Secure 2 and how does it differ from 3D Secure 1?

3D Secure 2 is EMVCo’s EMV 3-D Secure standard for authenticating cardholders on remote payments. Unlike 3DS1, which redirected every customer to an issuer page, it exchanges extensive device, cardholder and transaction data in the background so the issuer can approve low-risk payments frictionlessly and challenge only risky ones. It also supports native mobile apps and carries PSD2 exemption indicators.

What is frictionless authentication in 3DS2?

Frictionless authentication means the issuer’s Access Control Server authenticates the transaction purely from the data it received, with no customer interaction. The ARes returns a Y status with an authentication value and ECI, and the merchant proceeds to authorisation. The customer sees nothing, yet the transaction can still carry a liability shift. Whether a payment qualifies is the issuer’s decision, not the merchant’s.

Does 3D Secure 2 shift liability for chargebacks to the issuer?

Generally yes for fraud chargebacks on authenticated or attempted transactions, provided the authentication value and ECI are passed correctly in the authorisation message. It does not cover non-fraud disputes such as items not received, and it does not apply when a transaction relies on an exemption, such as low value or TRA, where liability stays with the party that applied it. Scheme rules vary, so confirm with your acquirer.

Is 3D Secure 2 required under PSD2?

PSD2 requires strong customer authentication for most electronic payments when both the issuer and acquirer are in the EEA, and 3DS2 is the standard way to perform it for online card payments. Exemptions exist, including low value, transaction risk analysis, trusted beneficiary and certain recurring or merchant-initiated payments. Outside the EEA, 3DS use is a risk and liability choice rather than a legal requirement.

What are the AReq, ARes, CReq, CRes and RReq messages?

AReq is the authentication request the 3DS Server sends toward the issuer through the Directory Server, and ARes is the issuer’s answer. If a challenge is needed, the browser or SDK sends a CReq to the ACS and receives a CRes with the challenge screen. After the challenge the ACS sends an RReq with the final result to the 3DS Server, which acknowledges with an RRes.

Do passkeys work with 3D Secure 2?

Yes, increasingly. EMVCo lists WebAuthn and Secure Payment Confirmation among supported challenge flows, so an issuer can verify a cardholder with a FIDO credential instead of an SMS code. Availability depends on issuer enrolment of credentials and browser support, so deployments are still uneven. Treat passkeys as an upgrade within the existing 3DS flow rather than a separate integration.

EMV 3-D Secure 2 Architecture: Frictionless Flow, Risk-Based Authentication and Liability Shift (2026)