3-D Secure 2 (EMV 3DS) Architecture: PSD2 SCA, Frictionless vs Challenge Flows and Risk-Based Authentication (2026)

Most online card payments in Europe now pass through an authentication protocol the cardholder never sees. 3-D Secure 2 (formally EMV 3-D Secure, or EMV 3DS) lets a merchant send the issuing bank around a hundred data points about a purchase, and lets the bank decide in a few hundred milliseconds whether the buyer needs to prove who they are. When it works, the checkout is silent. When it does not, the shopper is bounced into a one-time-password screen, and a meaningful share of them never come back.

That trade-off is the real design problem. Regulation (the EU’s second Payment Services Directive, PSD2) demands strong customer authentication, the card schemes assign fraud liability based on how a transaction was authenticated, and the merchant’s conversion rate depends on how rarely the issuer asks for a challenge. Three parties optimise three different objectives through one protocol.

This article is for architects and payment engineers who need the machinery, not the marketing. You will leave with a precise model of the actors and messages, the logic that separates frictionless from challenge outcomes, how PSD2 exemptions map onto protocol fields, and the failure modes that cost real money.

What this covers: the 3DS1 to 3DS2 evolution, actors and message flow, a sample AReq, exemption and liability mechanics, the issuer-side risk engine, and the timeouts and edge cases that break production integrations.

Non-advisory note: this is a systems and architecture analysis, not legal, compliance or financial advice. Verify regulatory details against the primary texts and your acquirer’s rules.

Context and Background

3-D Secure began in 2001 as Visa’s answer to card-not-present fraud: redirect the shopper to the issuer’s page, have them type a static password, and return a pass or fail. The “3-D” refers to the three domains involved: the issuer domain, the acquirer domain and the interoperability domain (the card schemes’ infrastructure). Version 1 had three structural weaknesses. The redirect was a full-page hop that broke on mobile and in embedded webviews, the data passed to the issuer was thin, and every transaction was a binary challenge-or-nothing decision, so conversion suffered.

EMVCo, the standards body owned by the major card networks, took over the specification and published EMV 3DS 2.0 in 2016. The redesign introduced risk-based authentication, a native mobile SDK, and a structured data exchange so that issuers could approve low-risk payments without any shopper interaction. Later versions refined this. According to a PCI Proxy summary, 2.1 arrived in 2017 and broadened the data model, 2.2 followed in December 2018 with decoupled authentication, delegated authentication, 3DS Requestor Initiated (3RI) messaging and exemption signalling, and 2.3 was published in October 2022 with a more customisable challenge interface and improved data elements. EMVCo’s own announcement describes 2.3 as bringing more implementation flexibility, faster fraud identification for issuers and a smoother consumer experience. Treat exact dates as a secondary-source reading and confirm against EMVCo’s specification pages.

The schemes have since retired the old protocol. The same summary reports that Visa and Mastercard deprecated 3DS1 in October 2022, with other schemes following, and that older 2.x versions are being sunset on scheme-defined schedules (it cites 2.1 being deprecated by Mastercard in July 2024 and Visa in September 2024). For a new build in 2026 the practical floor is 2.2, and 2.3 support is something to ask your 3DS Server vendor and acquirer about rather than assume.

Regulation is what turned an optional fraud tool into mandatory plumbing in Europe. PSD2, together with the Regulatory Technical Standards on strong customer authentication (Commission Delegated Regulation (EU) 2018/389), requires authentication using at least two independent factors from knowledge, possession and inherence for most electronic payments, with a defined set of exemptions. 3DS2 is the dominant mechanism by which card-not-present payments satisfy that requirement. If you are building around payment flows more broadly, our guide to payment orchestration platform architecture shows where authentication sits relative to routing, retries and acquirer failover. For the message formats that carry the resulting authorisation, see ISO 8583 versus ISO 20022 card messaging.

The central claim of this article is simple. 3DS2 is not an authentication step. It is a negotiation of risk between a merchant who knows the basket and an issuer who knows the account, with the challenge as the costly fallback. Architectures that treat it as a mandatory pop-up lose conversion. Architectures that treat it as a data-quality and exemption-strategy problem win it back.

The 3DS2 Reference Architecture

In 3-D Secure 2, a 3DS Requestor (the merchant) sends an Authentication Request (AReq) through its 3DS Server to the card scheme’s Directory Server, which routes it to the issuer’s Access Control Server (ACS). The ACS scores risk and answers either “authenticated” (frictionless) or “challenge needed”. Challenges run through a browser frame or the mobile 3DS SDK, and the final result carries a cryptogram that the authorisation message later references.

Actors and their trust boundaries

Figure 1: EMV 3DS actors. The merchant side collects data and the issuer side decides; the Directory Server in the middle routes and brokers.

Figure 1 shows the cast. Each plays a narrow role, and the narrowness is deliberate because each sits in a different trust and compliance domain.

Cardholder and device. The browser (device channel 02 in the specification’s enumeration, unverified here) or a mobile app embedding the 3DS SDK (channel 01, also unverified). A third channel, 03, is 3RI, used when no cardholder is present.
3DS Requestor. The merchant’s checkout environment. It initiates authentication and decides when to request or suppress a challenge, within the limits the issuer will honour.
3DS Server. Software operated by the merchant, its PSP or a third-party provider. It assembles the AReq, talks to the Directory Server, and validates results. EMVCo certifies these components, and the PCI Security Standards Council publishes a separate PCI 3DS Core Security Standard covering the environments that host them.
3DS SDK. A library embedded in the merchant’s mobile app that collects device parameters and renders the challenge natively, replacing the redirect that made 3DS1 painful on phones.
Directory Server (DS). Operated by each card scheme. It holds the ranges of cards enrolled for 3DS, routes messages to the correct issuer ACS, and enforces message validation. It is the interoperability domain from the original “3-D”.
Access Control Server (ACS). The issuer’s (or its processor’s) authentication engine. It holds the risk model, the cardholder’s enrolled authenticators and the challenge UI.

The architecture is a hub-and-spoke: the 3DS Server never talks to an ACS directly in the normal flow, and the ACS never sees the merchant’s systems beyond the data the 3DS Server chose to send. That boundary matters for data protection, because the data the merchant forwards becomes issuer-visible, and for resilience, because the Directory Server is a shared dependency whose outage affects every merchant on that scheme.

Why data richness is the whole game

The protocol’s value comes from what the AReq carries. The 3DS1 issuer saw a card number and an amount. The 3DS2 issuer receives the shopper’s device fingerprint, billing and shipping addresses, the account’s age and change history on the merchant side, recent purchase counts, a flag for whether the shipping address is new, email, phone, and for 3DS 2.2 and later the requestor’s exemption indication. PCI Proxy’s summary puts the 2.2 data model at roughly 150 data elements, versus about 100 in 2.1. I treat those counts as approximate.

Richer data does two things. It improves the issuer’s discrimination between genuine and fraudulent buyers, which lowers false-positive challenges. And it creates a merchant-side responsibility: poor or missing data makes the issuer cautious, because an unknown device with a first-time shipping address looks the same as a stolen card. In practice the single highest-leverage integration task is not choosing a library, it is populating the optional-but-influential fields correctly. Mobile integrations that omit SDK device data, and browser integrations that fail to run the browser-information collection, tend to see higher challenge rates, though I have no published benchmark to cite for the size of the effect and it varies by issuer.

Message types at a glance

The core protocol uses a small set of paired messages, all JSON over HTTPS between the components that talk directly:

AReq / ARes (Authentication Request and Response) between 3DS Server, DS and ACS.
CReq / CRes (Challenge Request and Response) between the cardholder’s device (via the SDK or browser frame) and the ACS.
RReq / RRes (Results Request and Response) from the ACS back through the DS to the 3DS Server after a challenge completes.
PReq / PRes (Preparation Request and Response) used by the 3DS Server to download the DS’s card ranges and ACS information, so it can skip authentication for unenrolled ranges.
Erro messages for protocol-level failures.

A fifth concept worth knowing is the method URL. Before sending the AReq, the 3DS Server may be told that the ACS has a “3DS Method” page. The browser loads it invisibly so the ACS can gather device data. If the AReq is sent without waiting for it, the issuer has less to work with.

Message Flow: Frictionless vs Challenge

Figure 2: The two main paths. A frictionless authentication ends at ARes. A challenge continues through CReq, CRes and RReq.

The fork in Figure 2 is the heart of the frictionless flow concept. After the ACS evaluates an AReq it sets a transaction status in the ARes. Different documentation (for example PCI Proxy’s terminology page) lists the values returned after the ARes as Y authenticated, N failed, U not available, C challenge needed, R rejected and A attempted. The same page lists Y, N, U, A and C as the values after the RReq, where C means the process was incomplete. The specification defines further statuses in later versions (for instance for decoupled flows and informational outcomes), so treat these as the core set rather than the full enumeration.

The frictionless path

In the frictionless path, the ACS returns status Y in the ARes together with an Electronic Commerce Indicator (ECI) and an authentication value, commonly called the CAVV for Visa or the AAV for Mastercard. The merchant takes those two values and includes them in the subsequent authorisation request to the acquirer. The issuer verifies the cryptogram when the authorisation arrives. No cardholder interaction occurs. Total added latency is the round trip through the DS and ACS plus the optional method URL wait.

A status of A (attempt) is subtler: it means authentication was attempted but not fully completed, for example because the issuer or cardholder was not enrolled. Whether this still carries a liability shift depends on the scheme’s rules, so do not infer shift from the status letter alone.

The challenge path

When the ARes returns C, it also returns the ACS URL and a transaction identifier. The 3DS Server passes these to the merchant front end. In a browser, the merchant creates a hidden form or iframe posting a Base64URL-encoded CReq to the ACS URL, and the ACS renders its challenge in the frame, sized by the requestor’s declared window size. In an app, the SDK handles the same exchange natively with encrypted messages. The cardholder responds with an OTP, an in-app approval or a biometric. The ACS then sends the final CRes to the frame, notifies the merchant side via RReq (through the Directory Server) and receives an RRes acknowledgement.

Two details trip up implementers. First, the browser challenge result reaches the merchant through the notification URL the 3DS Server supplied in the AReq, not through the iframe contents. If that URL is unreachable or misconfigured, the shopper completes the challenge and the merchant never finds out. Second, the RReq is delivered server-to-server and can arrive before or after the front-end redirect, so a correct implementation reconciles both signals against a stored transaction rather than trusting whichever arrives first.

Decoupled authentication and 3RI

3DS 2.2 added decoupled authentication, where the challenge runs outside the checkout session. According to the PCI Proxy summary, the cardholder confirms in their banking app within a time window, which suits call-centre and set-up scenarios where the buyer is not on a webpage. The AReq carries a decoupled-authentication request indicator and a maximum time the merchant is prepared to wait; the ARes tells the merchant whether the issuer will honour it.

3DS Requestor Initiated (3RI) is for authentication without the cardholder present, such as instalments or subscription renewals that need a fresh authentication request tied to earlier consent. A 3RI message cannot trigger a challenge. The ACS can approve, decline or say it cannot authenticate without the cardholder. This is also why merchants running subscriptions need to authenticate the first payment properly: later merchant-initiated charges lean on that original authentication.

A sample AReq

The following JSON is a trimmed, illustrative AReq for a browser-channel purchase. It is not a complete valid message: the real message has many more required fields, every value here is a placeholder, and field names and enumerations must be checked against the EMVCo specification version you implement. Field names follow the specification’s camelCase convention as I know it.

{
  "messageType": "AReq",
  "messageVersion": "2.2.0",
  "threeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e",
  "threeDSRequestorURL": "https://shop.example.com",
  "deviceChannel": "02",
  "messageCategory": "01",
  "acctNumber": "400000******0002",
  "cardExpiryDate": "2812",
  "purchaseAmount": "4990",
  "purchaseCurrency": "978",
  "purchaseExponent": "2",
  "purchaseDate": "20261028131500",
  "browserJavascriptEnabled": true,
  "browserLanguage": "en-GB",
  "browserScreenHeight": "1080",
  "browserScreenWidth": "1920",
  "browserTZ": "-60",
  "browserUserAgent": "Mozilla/5.0 (placeholder)",
  "browserAcceptHeader": "text/html",
  "browserIP": "203.0.113.7",
  "threeDSCompInd": "Y",
  "notificationURL": "https://shop.example.com/3ds/notify",
  "threeRIInd": null,
  "threeDSRequestorChallengeInd": "02",
  "billAddrCountry": "250",
  "shipAddrCountry": "250",
  "email": "shopper@example.com",
  "acctInfo": {
    "chAccAgeInd": "05",
    "nbPurchaseAccount": "12",
    "shipAddressUsageInd": "04"
  },
  "merchantRiskIndicator": {
    "deliveryTimeframe": "02",
    "shipIndicator": "01"
  }
}

A few notes on the sample. deviceChannel 02 denotes the browser channel and messageCategory 01 a payment (as opposed to non-payment) authentication. The amount is expressed in minor units with the currency as an ISO 4217 numeric code (978 is euro). threeDSCompInd reports whether the 3DS Method completed, which directly affects how much device data the issuer holds. threeDSRequestorChallengeInd is the merchant’s preference signal: whether it wants no preference, no challenge, a challenge, or, in later versions, a mandated challenge or an indication that a data-share-only request is intended. The issuer is not obliged to follow it, and a mismatch between what the merchant asks for and what the issuer returns is normal. The nested acctInfo and merchantRiskIndicator objects are where the risk-relevant signals live.

Exemptions: How PSD2 SCA Maps onto the Protocol

Figure 3: Where PSD2 SCA exemptions fit. Out-of-scope transactions skip it; exemptions are requested by the merchant or acquirer and still decided by the issuer.

The psd2 sca rules are not a single yes-or-no gate. They are a taxonomy, and the protocol only becomes intelligible once you map each branch onto a field. The RTS text on legislation.gov.uk is the primary source for the exemptions below, and I checked the figures for Articles 11, 13, 14, 16, 17 and 18 against it, with the Article 18 amounts and rates confirmed from a secondary page and the Annex wording flagged accordingly.

Out of scope versus exempt

These are different legal concepts with different protocol treatment.

Out of scope transactions are not subject to SCA at all. The main cases are merchant-initiated transactions (MIT), where the payee triggers the charge under an earlier mandate, mail order and telephone order (MOTO), and “one-leg-out” payments where the issuer or acquirer is outside the EEA, subject to a best-efforts expectation. The merchant flags these in the authorisation message rather than invoking 3DS for each charge.

Exempt transactions are in scope, but SCA need not be applied if conditions hold. The issuer retains the final say, and it can still challenge an exempted transaction. That asymmetry is important: requesting an exemption is a request, not a right.

The main exemptions

Low-value remote payments (Article 16). Per the RTS text, a remote transaction is eligible if the amount does not exceed EUR 30, subject to counters: the cumulative amount of previous remote transactions since the last SCA must not exceed EUR 100, or there must be no more than five consecutive remote transactions since the last SCA. The counters are the issuer’s to maintain. A merchant cannot see them, which is one reason the issuer may refuse the exemption.
Transaction risk analysis (Article 18). A low-risk remote transaction can be exempt when the provider’s fraud rate is at or below a reference rate and the amount is within the matching exemption threshold value (ETV). The widely cited bands are an ETV of EUR 100 at a reference fraud rate of 0.13 percent, EUR 250 at 0.06 percent and EUR 500 at 0.01 percent, as listed by a secondary source and consistent with my understanding of the RTS Annex; check the Annex in the consolidated text before relying on them. Real-time analysis must also show no risk indicators such as abnormal behaviour, malware signs, known fraud scenarios or high-risk payee locations. Crucially, the fraud rate that counts is the PSP’s own rate (the party applying the exemption, normally the issuer or acquirer), measured over a trailing period and reportable to the regulator.
Trusted beneficiaries (Article 13). The payer can whitelist a payee, and later payments to that payee are exempt. Creating or amending the list requires SCA.
Recurring transactions (Article 14). SCA applies when the series is created, amended or first initiated; later payments of the same amount to the same payee in the series are exempt.
Secure corporate processes (Article 17). Dedicated corporate payment protocols that competent authorities judge at least equivalently secure.
Contactless (Article 11) applies to physical terminals, not remote 3DS: EUR 50 per transaction with the cumulative EUR 150 or five-transaction counters. It appears in this list only because people conflate it with the remote low-value rule.

Who applies the exemption

A decision that confuses many teams is whether to request the exemption in the AReq or to skip 3DS and send the exemption flag in the authorisation. The two are not equivalent. In the acquirer exemption model, the acquirer applies TRA based on its own fraud rate and asks the issuer to accept it, typically by sending the transaction for authorisation without prior 3DS authentication. The issuer can respond with a soft decline that demands SCA, after which the merchant must retry with 3DS. In the issuer exemption model, the merchant sends the AReq and the ACS itself grants a frictionless outcome based on its own risk analysis. The merchant can also indicate a preference through the requestor challenge indicator.

The practical architecture is a try-then-fall-back loop: attempt the exemption path first, handle the soft decline (a specific issuer response code that scheme documentation defines for “SCA required”) and re-run the payment through the full 3DS flow. That loop needs idempotent state handling so a retry does not double-charge. Our guide to payment API idempotency and exactly-once retries covers the pattern in detail.

Liability shift

The commercial reason merchants bother with 3DS is liability shift. When a transaction is authenticated, or attempted under rules the scheme recognises, fraud chargebacks of the relevant reason codes generally move from merchant to issuer. When the merchant or acquirer requests an exemption and the issuer accepts it, liability generally stays with the party that applied the exemption. The details differ between Visa and Mastercard and between regions, so never encode a liability assumption from this article; take it from the scheme’s current rules and your acquirer contract.

The ECI value returned in the ARes or RReq is the signal that downstream systems use to record how the transaction was authenticated. Persist it with the authorisation, because dispute handling months later depends on proving what happened.

Issuer-Side Risk-Based Authentication

Figure 4: A representative ACS decision flow. Real engines are proprietary; this shows the structure, not any issuer’s thresholds.

Everything the merchant sends is input to the ACS, and the decision logic is where risk based authentication actually happens. No issuer publishes its model, so what follows is a structural description of how such engines are generally built, not a claim about any specific bank.

Inputs and scoring

A typical ACS combines three categories of evidence. The first is the transaction itself: amount, currency, merchant category, merchant identity and the exemption indicator. The second is the device and session: browser fingerprint or SDK-collected parameters, IP address and geolocation, and whether this device has previously authenticated this cardholder. The third is the account history held by the issuer: spending patterns, velocity of recent authorisations, recent changes to contact details or enrolled authenticators, and prior fraud flags. The merchant-supplied account metadata (account age, shipping-address age, recent purchases) is a fourth input that the issuer cannot get anywhere else.

The output is usually a score mapped to bands. Low risk yields frictionless approval, medium risk a challenge, and high risk a rejection or a “not authenticated” status without offering a challenge, since challenging a probable fraudster only teaches them the OTP route. Modern engines add learned models alongside rules, but the rules do not disappear, because regulators want explainable exemption logic: under the TRA exemption, the provider must be able to demonstrate its fraud rates and its real-time analysis.

Step-up design

Once the ACS chooses a challenge, it must satisfy the two-factor requirement with independent factors. Common methods are an SMS or app-delivered OTP combined with possession of the card or phone, or a banking-app approval combined with a biometric or PIN. The SMS OTP is the weakest and most abandoned method: delivery delays, roaming failures and copy-paste friction compound. App-based approval with on-device biometrics has fewer steps and fewer failure points, which is why issuers have pushed migration to it. 3DS 2.3’s reported move toward automated out-of-band transitions fits that direction.

The concept of delegated authentication

3DS 2.2 introduced delegated authentication, where the issuer allows a trusted third party to authenticate the customer on its behalf. According to the PCI Proxy summary, this can skip the issuer’s ACS challenge and may improve frictionless rates. The architecture shifts trust: the issuer must contractually accept the delegate’s assertions, and the liability model changes accordingly. Wallet providers with strong device-bound credentials are the obvious candidates. This is the same direction as the passkey-based approaches schemes are exploring, though I do not cover those as established fact here.

A worked illustration

The following numbers are illustrative only and not measurements. Suppose a merchant processes 100,000 EUR 80 card payments a month from EEA cards. If the issuer challenges 30 percent, 30,000 shoppers see a step-up. If a challenge loses 10 percent of shoppers and an enriched AReq drops the challenge rate to 20 percent, then 3,000 fewer lost orders occur per month at an average of EUR 80, or EUR 240,000 in monthly revenue. The exact percentages vary widely by issuer, country and method, and the point is the structure: abandonment is multiplicative with challenge rate, so every point of challenge reduction is worth a quantifiable number, which makes data quality an investment case rather than a nicety.

Trade-offs, Gotchas, and What Goes Wrong

Authentication adds a distributed protocol to the hot path of checkout, and distributed protocols fail in specific ways.

Timeouts and dead ends

EMVCo specifies timeouts for each leg, but the numbers vary by version and scheme profile, and I have not verified them here, so check the specification’s timeout table before configuring your own. The failure pattern is consistent, though. A slow ACS stalls the AReq, the 3DS Server times out, and the merchant must decide: fail the payment, retry, or proceed without authentication and accept liability. That last option is a business decision encoded in code, and it must be explicit, not a default.

A browser challenge adds a human timeout. Shoppers who leave the OTP screen leave a transaction in “challenge issued” forever unless a reaper job marks it abandoned after a bounded window. Without that, reconciliation breaks and inventory stays reserved.

Data and integration traps

Unreliable notification URL. If the notification endpoint is behind a cache, a strict content-security policy, or a CORS rule that blocks the frame post, the challenge completes invisibly and the order never advances.
Frame-size mismatch. Declaring a challenge window size that the ACS cannot render produces clipped OTP boxes on small phones. Honour the specified size set.
Stale card-range data. If the 3DS Server does not refresh PReq/PRes information, it attempts authentication on unenrolled ranges or skips it on newly enrolled ones.
Duplicate AReq on retry. Retrying with a new transaction identifier after a timeout can leave two authenticated outcomes. Tie retries to an idempotency key.
Currency and exponent errors. Sending amounts in major units instead of minor units can make a EUR 49.90 payment look like EUR 4,990 or EUR 0.50, and either mistakes the exemption eligibility.
Mismatched cryptograms. The authentication value must be forwarded to authorisation unmodified, with the matching ECI. Truncation or encoding errors produce authorisation declines that look like issuer problems.

Conversion and strategy pitfalls

Requesting “no challenge” on every transaction does not make challenges disappear. Issuers that see systematic exemption requests on high-risk baskets lose trust in the signal, and soft declines then force a second, slower attempt. A better pattern is selective: request exemptions where you are confident, honour issuer decisions, and keep your fraud rate low because the TRA thresholds are tied to it. A fraud rate above the reference band removes the exemption for the whole portfolio at that tier, which is a cliff, not a slope.

Another anti-pattern is treating a successful 3DS as proof of a legitimate customer. Account takeover and social-engineering attacks can pass a challenge because the legitimate cardholder’s own authenticator is used under duress. Authentication shifts liability, but it does not stop scams. The overlap with push-payment fraud is covered in our analysis of authorized push payment fraud and confirmation of payee.

Resilience

The Directory Server is a single logical dependency per scheme. Production designs should keep a circuit breaker around each scheme’s DS, emit metrics for AReq latency, challenge rate, frictionless rate, ARes status distribution and RReq arrival lag, and define a fallback policy per amount band. Without those four or five dashboards, a drop in conversion looks identical to a fraud wave.

Practical Recommendations

Start from the premise that you are tuning a risk negotiation, and measure it. The core metrics are the frictionless rate (share of attempts ending at ARes with status Y), the challenge rate, challenge completion rate, and the approval rate after authentication. Segment them by issuer, country, device channel and amount band, because a single global figure hides the issuers who challenge everything.

Invest in data quality before tuning exemptions. Populate the browser or SDK fields completely, send the 3DS Method result, and pass account-history indicators accurately. Then layer the exemption strategy: low value where it is useful, TRA through your acquirer if your fraud rate qualifies, recurring and MIT flags for subscriptions, and trusted-beneficiary prompts for repeat buyers. Always implement the soft-decline fallback.

Make the architecture resilient. Treat the 3DS Server as a stateful service with idempotent transactions, durable storage of the ECI and authentication value, a reaper for abandoned challenges, and explicit timeout policy. Choose a 3DS Server and SDK that are EMVCo-certified for the version you need, ask about 2.3 support, and confirm their PCI 3DS compliance posture.

A short checklist:

Confirm your minimum supported EMV 3DS version with your acquirer and schemes.
Run the 3DS Method and always send the completion indicator.
Fill account-history and shipping fields from real data.
Set an explicit timeout and a documented fallback policy.
Reconcile front-end redirect and RReq against one stored transaction.
Persist ECI, authentication value and transaction identifiers with every authorisation.
Track frictionless rate, challenge rate and abandonment by issuer.
Implement soft-decline retry through full 3DS with idempotency keys.
Re-check exemption thresholds and your fraud rate each reporting period.

Frequently Asked Questions

What is 3-D Secure 2?

3-D Secure 2, standardised by EMVCo as EMV 3-D Secure, is an online card-payment authentication protocol. The merchant’s 3DS Server sends rich transaction and device data to the card issuer’s Access Control Server through the card scheme’s Directory Server. The issuer either approves silently (a frictionless flow) or demands a challenge such as an OTP or biometric. Successful authentication yields a cryptogram and an indicator that supports liability shift and PSD2 compliance.

What is the difference between frictionless and challenge flow?

In a frictionless flow the issuer’s ACS decides from the data it received that the risk is low, returns an authenticated status in the AReq response, and the shopper never sees a prompt. In a challenge flow the ACS returns a challenge-needed status, the shopper completes a second factor in a browser frame or app, and the result returns via the results message. Frictionless is faster and converts better; challenge is the fallback for medium-risk payments.

Is 3-D Secure 2 required under PSD2?

PSD2 and its Regulatory Technical Standards require strong customer authentication for most electronic payments in the EEA, and 3DS2 is the main way card-not-present payments meet that requirement. The law does not name the protocol. It names the outcome, two independent factors, and lists exemptions such as low value, transaction risk analysis, trusted beneficiaries and recurring series. Out-of-scope cases include merchant-initiated and mail or telephone orders. Confirm obligations with counsel or your acquirer.

Does 3DS2 shift fraud liability to the issuer?

Generally yes for authenticated transactions, which is the main commercial incentive for merchants. When a payment is authenticated, or attempted under scheme rules, qualifying fraud chargebacks typically move to the issuer. When an exemption is applied, liability usually stays with the party that applied it, and scheme rules differ by network and region. Read your acquirer agreement and the current scheme rules rather than relying on a status letter alone.

What are the TRA exemption thresholds?

Under Article 18 of the PSD2 RTS, a remote transaction can be exempt from strong authentication if real-time analysis shows low risk, the provider’s fraud rate is at or below the reference rate, and the amount is within the threshold. The commonly cited bands are EUR 100 at 0.13 percent, EUR 250 at 0.06 percent and EUR 500 at 0.01 percent. Verify against the RTS Annex, and note the issuer can still require a challenge.

What happens if the 3DS server or ACS times out?

The merchant must choose between failing the payment, retrying, or proceeding without authentication and bearing the liability. There is no safe default, so encode the policy deliberately by amount and risk. Use idempotency keys so retries do not create duplicate authentications or charges, run a reaper for abandoned challenges, and monitor timeout rates per issuer and per Directory Server so a regional outage is visible before conversion collapses.