3D Secure 2 and PSD2 SCA: Card Authentication Flow, Exemptions and Liability Shift (2026)

Most teams describe 3D Secure as a checkout step that sometimes asks for a one-time code. That description hides the real design problem. Every online card payment in the European Economic Area is an opportunity for three parties, the merchant, the acquirer and the issuer, to decide who must authenticate the customer, who is allowed to skip authentication, and who pays if the decision turns out to be wrong. EMV 3DS is the message protocol that carries that negotiation, and PSD2 strong customer authentication (SCA) is the law that gives it teeth.

This matters in 2026 because the protocol is mature, the exemptions are well defined, and the money is in the routing logic: a few points of frictionless approval rate, or a few basis points of fraud rate, move a payment business materially. You leave with a working mental model of the message flow, the exemption rules with their exact thresholds, the liability map, and a design for an authentication decision service.

What this covers: the actors and message flow of EMV 3DS, how PSD2 SCA and its exemptions map onto protocol fields, how liability shift really works, a decision-engine design with code, failure modes, and an operating checklist.

Context and Background

Payment authentication used to be a single question: does the card number, expiry and security code match? Card-not-present fraud grew precisely because those three values are static and leak in breaches. The industry answer was 3-D Secure, first released by Visa in 2001 as 3DS 1.0: redirect the shopper to the issuing bank, who checks a password. It worked for fraud and badly for conversion. Full-page redirects, forgotten static passwords and pop-ups inside iframes made checkout abandonment a known cost of the protocol.

EMVCo took over the specification and published EMV 3-D Secure 2.x, which replaced the redirect with a structured data exchange. The merchant side now sends dozens of data elements about the device, the account and the purchase, so the issuer can approve most low-risk payments without ever showing the shopper a screen. That path is called frictionless. Versions have moved on since 2.1: the EMVCo 2.3 announcement from November 2021 added device binding, support for WebAuthn and Secure Payment Confirmation, automated out-of-band app switching, and richer recurring-payment data. EMVCo now publishes the v2.3.1 document set, and its bulletin on specification version configuration is dated February 2025. The legacy 3DS 1.0.2 protocol was retired by the card schemes in October 2022 (date from scheme announcements of that period; confirm against your scheme rules for your region).

The regulatory half arrived with the revised Payment Services Directive. PSD2 Article 97 requires the payer’s payment service provider (PSP) to apply strong customer authentication when the payer initiates an electronic payment, and the technical detail sits in Commission Delegated Regulation (EU) 2018/389, usually called the RTS on SCA and common secure communication, drafted by the European Banking Authority. SCA means at least two elements from three independent categories: knowledge, possession and inherence. The elements must be independent, so that a breach of one does not compromise the others. Because the RTS is technology neutral, card-not-present SCA in practice meant EMV 3DS plus an issuer authentication method such as a banking-app approval or a biometric.

If you want the sibling view of the same stack from the protocol side, our deep dive on EMV 3-D Secure 2 authentication and the frictionless flow covers message internals. This post takes a different cut: it treats the whole thing as a decision and liability system, and it is written for the people who build the routing logic, not the people who implement the cryptogram plumbing.

A word on scope. This is systems analysis of a regulated payment flow. It is not legal or compliance advice, and thresholds and scheme rules change; verify against the current RTS text, your scheme rulebooks and your acquirer contract before you build on any number here.

Why the thesis is “authentication as an option on liability”

Here is the framing that the rest of this article uses. A 3DS request is not only a security check. It is an option the merchant or acquirer exercises on liability. When you ask for a challenge and the issuer authenticates the shopper, the scheme rules generally move fraud chargeback liability toward the issuer. When you ask for an exemption instead, you keep the shopper’s journey short and you keep the fraud risk. Every exemption you request is a decision to hold risk in exchange for conversion, and your own fraud rate determines how much of that you are allowed to hold.

That reframing turns a compliance chore into an optimisation problem with known costs on both sides. The remaining sections build the machinery to solve it, starting with who sits where.

Reference Architecture: Actors, Domains and the Message Flow

In short: EMV 3DS splits the world into three domains. The acquirer domain holds the merchant, the 3DS Requestor and the 3DS Server. The interoperability domain holds the card scheme’s Directory Server (DS). The issuer domain holds the Access Control Server (ACS). Authentication messages travel merchant to DS to ACS and back, separate from the authorization message that later travels over the card network.

Figure 1: The 3D Secure domains. Authentication flows through the Directory Server to the issuer ACS. Authorization flows separately through acquirer, scheme and issuer.

Figure 1 shows the two parallel paths that people routinely conflate. The authentication path runs from the merchant through the 3DS Server and the scheme’s Directory Server to the issuer’s ACS. The authorization path is the ordinary card message, typically ISO 8583 or a scheme-specific API, from acquirer through the scheme network to the issuer’s authorization system. Authentication produces evidence. Authorization consumes that evidence. If you want the message format side of the second path, see our comparison of ISO 8583 and ISO 20022 card messaging.

The actors, precisely

The 3DS Requestor is the merchant or the entity acting for it, such as a payment facilitator. The 3DS Server is the software component that builds and sends protocol messages. Most merchants do not run their own; their PSP or a specialist vendor hosts one that is certified by EMVCo. The 3DS SDK lives in the mobile app and collects device data, and in the browser channel the same job is done by a script that gathers browser attributes and posts them in the request. The Directory Server is operated by the card scheme. It routes requests by card range, keeps the table of which issuer ACS serves which BIN range, and acts as a trust anchor. The ACS belongs to the issuer, or to a vendor acting for it, and it holds the risk engine and the authentication methods.

The channel matters. EMV 3DS defines three device channels: app-based (01-APP), browser-based (02-BRW) and 3DS Requestor Initiated, or 3RI (03-3RI). The 3RI channel carries authentication requests that the merchant starts without the cardholder present, for example when a subscription needs a fresh decision on a later billing date. It cannot display a challenge, so it is useful only for the exempt, frictionless or already-authenticated cases.

The core message pairs

The protocol is a handful of request and response pairs, and learning their names pays off when you read logs.

PReq/PRes (preparation). The 3DS Server asks the Directory Server which card ranges and ACS versions are supported and caches the answer. It is how you know before checkout whether a BIN can do 3DS 2.x at all.
AReq/ARes (authentication). The central call. The 3DS Server sends the Authentication Request containing the account number, amount, merchant data, device data and the requestor’s preferences. The Directory Server forwards it to the ACS, which returns an Authentication Response with a transaction status, transStatus.
CReq/CRes (challenge). If the ARes says a challenge is required, the app or browser sends a Challenge Request to the ACS and gets a Challenge Response containing the screen to show. The cardholder interacts with the ACS directly, so the merchant never handles the OTP or biometric.
RReq/RRes (results). After the challenge ends, the ACS posts a Results Request through the Directory Server to the 3DS Server with the final status and the authentication value.

The transStatus field is where outcomes live. The values you will see most often are Y (authenticated), N (not authenticated), U (unable to authenticate), A (attempted, where authentication was tried but could not complete, for example the issuer ACS was unavailable), C (challenge required), R (rejected by the issuer, do not proceed to authorization) and, since 2.2, D for decoupled authentication and I for informational only. A good engineer treats this field as a state machine, not a boolean.

Authentication value and ECI: how evidence reaches authorization

A successful result carries two items that the authorization message must echo. The first is a cryptographic authentication value, a cardholder authentication verification value (CAVV) for Visa-family schemes or an accountholder authentication value (AAV) for Mastercard. The second is the Electronic Commerce Indicator (ECI), a two-digit value telling the issuer what happened. The common mapping, which you should confirm in your scheme documentation, is Visa-style ECI 05 for fully authenticated, 06 for attempted, and 07 for non-authenticated, with Mastercard using 02, 01 and 00 respectively. The ECI is the single field that most disputes eventually reduce to, because the scheme’s liability rules key off it.

Frictionless, challenge and the device-data bargain

Figure 2 shows the typical flow. The merchant’s request carries enough data for the issuer to make a risk decision in a few hundred milliseconds. If the ACS is satisfied, the ARes returns Y and the flow ends without any cardholder interaction. If not, it returns C, and the cardholder is sent through a challenge.

Figure 2: The EMV 3DS message sequence. The ARes decides whether the flow is frictionless or needs a challenge. The result travels back to the merchant, which then submits authorization.

The figure compresses two branches into one sequence. In the frictionless branch, the ARes carries the authentication value and ECI directly. In the challenge branch, the ARes only carries C, the challenge runs against the ACS, and the evidence arrives later in the RReq. In both cases the merchant, through its PSP, ends with the same artefact: an authentication result it can attach to the authorization.

The practical lesson is that the quality of the data in the AReq changes the issuer’s decision. Sparse requests look risky to an ACS. Complete requests, with a stable device identifier, billing and shipping addresses, account age, previous successful payments and a recognisable cardholder name, let a good ACS approve more without a challenge. That is the “device-data bargain”: you give the issuer more signal, and in exchange it asks the customer for less. We return to this in the decision-service design below.

The PSD2 SCA Rule Set and How It Maps to Protocol Fields

In short: PSD2 requires SCA for payer-initiated electronic payments unless a rule takes the payment out of scope or an exemption applies. EMV 3DS carries your exemption intention in threeDSRequestorChallengeInd, and the issuer ultimately decides whether to accept it. The party that applied the exemption generally holds the fraud liability.

Before looking at exemptions, separate two categories that people mix up: out-of-scope transactions and exempt transactions. An out-of-scope payment is not subject to SCA at all, so no exemption is needed. An exempt payment is in scope, but a rule lets the PSP skip SCA under specified conditions.

What is out of scope

The usual out-of-scope categories are merchant-initiated transactions (MIT), mail order and telephone order (MOTO), anonymous prepaid instruments, and, with caveats, “one-leg-out” payments where either the issuer or the acquirer is outside the EEA. For MIT, the cardholder must have given a mandate that was itself authenticated, typically at the first customer-initiated transaction that set up the agreement. After that, the merchant can charge without SCA, within the terms of the mandate. For one-leg-out, regulators expect the PSP to apply SCA on a best-efforts basis rather than a mandatory one. The practical effect is that a subscription business needs its first payment strongly authenticated and flagged correctly as setting up a mandate, because every renewal then relies on that setup record.

Misclassification is where money gets lost. Marking a customer-initiated payment as MIT to dodge SCA is not a clever exemption. It is a scheme-rule violation that surfaces in disputes and audits. Marking a legitimate MIT as a standard customer-initiated payment sends a challenge to a customer who is not there, and the renewal fails.

The exemptions, with their real thresholds

The RTS lists several exemptions. The ones that matter for card payments, and the thresholds the RTS fixes, are these. The article numbering below follows the adopted regulation; the draft EBA report numbered some articles differently, so check the current consolidated text.

Low-value payments. A remote electronic payment of no more than EUR 30 can skip SCA. A cumulative limit applies: SCA must be applied once the total since the last SCA exceeds EUR 100 or the count of consecutive exempt transactions reaches five. The counters are maintained per payment instrument by the PSP that applies the exemption, and the issuer can maintain its own counters regardless of the merchant’s view. This is why a low-value exemption you request is not one you can rely on: the issuer’s counters may say the fifth transaction has arrived.

Transaction risk analysis (TRA). A PSP can skip SCA for remote card payments up to a ceiling that depends on its fraud rate, and only if a real-time risk analysis finds the specific transaction low risk. The thresholds from the RTS are:

Exemption threshold value	Reference fraud rate, remote card payments
Up to EUR 500	0.01% (1 basis point)
Up to EUR 250	0.06% (6 basis points)
Up to EUR 100	0.13% (13 basis points)

The fraud rate is calculated over a rolling quarter of 90 days, as the total value of unauthorised and fraudulent remote card transactions, whether or not SCA was applied, divided by the total value of all remote card transactions. It is measured per PSP, and separately for the issuer and the acquirer. A PSP that exceeds a band’s fraud rate must stop using the exemption for that band and report to its supervisor. These figures are taken from the EBA’s RTS text, which I checked against the EBA final draft report; the adopted regulation is Delegated Regulation (EU) 2018/389 and later amendments adjust some other thresholds, so confirm the current consolidated version.

Trusted beneficiaries. The payer can add a payee to a list kept by the account servicing PSP, and later payments to that payee can skip SCA. The list is created or confirmed by the payer through the issuer. In EMV 3DS 2.2 and later this is signalled with a request to the issuer to whitelist the merchant, and the issuer’s ACS decides whether to present that option to the cardholder.

Recurring payments of the same amount and payee. A series with the same amount and payee needs SCA when set up or changed, and not on later payments. If the amount varies, the merchant is outside the strict exemption and relies on the MIT route with an authenticated mandate.

Secure corporate payment processes can also be exempted where the issuer’s regulator is satisfied the process achieves equivalent security, and contactless and unattended transport payments have their own rules. They matter for card-present flows more than for online checkout, so they appear in the figure below only as scope notes.

Requesting an exemption in the protocol

In an AReq, the merchant side expresses its preference through threeDSRequestorChallengeInd. The values are numeric codes. In rough terms: 01 is no preference, 02 is “no challenge requested,” 03 is “challenge requested because the 3DS Requestor prefers it,” and 04 is “challenge requested because a mandate applies,” meaning the challenge is required by law or rule. Version 2.2 added further codes: 05 for “no challenge requested, transaction risk analysis already performed,” 06 for “no challenge requested, data share only,” 07 for “no challenge requested, SCA already performed,” 08 for “no challenge requested, utilise trusted beneficiary exemption,” and 09 for “challenge requested, trusted beneficiary prompt requested if challenge required.” Check these codes against the exact version your 3DS Server uses; the code set is version dependent.

The important property of all of these is that they are requests. The ACS can still choose to challenge, and under PSD2 the issuer has the final say. If you request an exemption and the issuer insists on SCA, the transaction continues as a challenge, and you get liability shift as though you had asked for it. If you request an exemption and the issuer accepts, the exemption stands and so does the risk allocation that goes with it.

Figure 3: The SCA scope and exemption decision flow. Every exempt branch can still be overridden by the issuer, which falls back to a challenge.

Figure 3 makes the ordering explicit. First decide scope. Then work through exemptions in the order that favours the merchant. Then, if nothing applies, request the challenge and accept the friction. The final loop in the figure is the one that surprises teams: an issuer override sends you back to the challenge path whether you planned for it or not.

Deeper Analysis: Liability Shift, Who Pays, and the Economics

In short: Liability shift is a rule set, not a protocol feature. When a transaction is fully authenticated, the scheme rules generally move fraud chargeback liability to the issuer. When an exemption is applied, the party that applied it keeps the risk. Under PSD2 law the payer’s PSP refunds the customer first, and then recovers from others where the rules allow.

Two layers of liability exist and people routinely merge them. The first is the legal layer between the PSP and the customer. The second is the scheme layer between acquirer and issuer. They solve different problems.

The legal layer

PSD2 Article 74(2) says that where the payer’s PSP does not require SCA, the payer bears no financial loss unless they acted fraudulently. Where the payee or the payee’s PSP fails to accept SCA, they must refund the payer’s PSP for the financial damage. In plain words: if a fraudulent card payment goes through without SCA and SCA was required, the customer is made whole, and the party that failed to apply or accept SCA ends up paying. Combined with the PSD2 refund rules (Article 73, generally by the end of the next business day after the payer notifies the PSP), the incentive is clear: nobody wants to be the party that skipped authentication on a fraudulent payment.

The scheme layer and the ECI

On the scheme side, liability shift for e-commerce works through chargeback reason codes. If a merchant submitted a fraudulent card-not-present transaction without authentication, the issuer can charge it back as fraud and the loss lands on the merchant. If the transaction was authenticated with 3DS, the fraud chargeback right is blocked or reversed in the issuer’s disadvantage. The scheme rulebooks specify which ECI values and which authentication outcomes qualify, and they differ in detail between Visa, Mastercard, American Express and the domestic schemes.

A sound working summary, which should be validated against your scheme documents, looks like this:

Situation	Authentication outcome	Typical fraud liability
Frictionless approval, `transStatus` Y	Fully authenticated, ECI 05 or 02	Issuer
Challenge passed	Fully authenticated	Issuer
Attempted authentication, `transStatus` A	ECI 06 or 01	Generally issuer, but check scheme rules for your region
Authentication failed, `transStatus` N	Do not proceed	Merchant if you go ahead anyway
Exemption requested and accepted, no SCA	No authentication value, or flagged exempt	The party that applied the exemption, often the acquirer for TRA
Out-of-scope MIT with valid mandate	Not applicable	Merchant or PSP, per contract

The row that causes the most arguments is attempted authentication. If the issuer’s ACS was unavailable and the scheme’s access control “stand-in” generated an attempt value, scheme rules usually still grant protection, but some issuers and regions treat it differently. If you route a lot of volume through attempts, measure your fraud chargeback outcomes on them separately before assuming they behave like full authentications.

Who holds liability when you apply an acquirer exemption

When an acquirer exempts a transaction from SCA under the TRA exemption, it takes the risk of a fraud chargeback on that transaction, because the issuer did not authenticate the payer. The acquirer typically passes that risk on to the merchant through its contract, either as a pass-through chargeback or as a higher rate. This makes the merchant’s TRA ceiling a function of two fraud rates, its acquirer’s and its own history, and it is why many acquirers prefer to decide exemptions centrally rather than leave them to merchants.

The economics: a worked, illustrative model

Numbers below are illustrative, not benchmarks, to show the shape of the trade-off. Suppose a merchant processes 1,000,000 euro of card volume a day at an average basket of 80 euro, so 12,500 orders. Assume a baseline fraud rate on unauthenticated payments of 0.20% of value, and assume that a challenge costs the merchant 4% of orders in abandonment on the challenged flow.

If the merchant challenges everything, fraud liability moves to the issuer: expected fraud cost to the merchant is near zero, but 4% of 12,500 is 500 lost orders, or about 40,000 euro of daily revenue. If the merchant requests TRA exemptions on 60% of volume under an accepted exemption, it holds fraud on that share: 0.2% of 600,000 euro is 1,200 euro per day of expected fraud, against saved abandonment on those 7,500 orders of 300 lost orders, or 24,000 euro. In this toy case the exemption saves far more in revenue than it costs in fraud, but only because the assumed fraud rate is low and the assumed abandonment is high. The break-even moves with the fraud rate, the average basket and the actual abandonment cost.

The lesson is not that exemptions are always better. The lesson is that a decision engine needs a measured fraud rate per segment and a measured abandonment cost per issuer. The cost of friction is not uniform: a bank with a smooth app approval flow challenges at a much lower cost than a bank that sends an SMS code to a number the customer no longer has.

What happens when the issuer disagrees

Issuers do not follow the merchant’s exemption request blindly. Issuer-side ACS risk engines routinely override exemption requests, and the override rate varies by issuer and by region. The observable symptom is that a request for “no challenge” returns transStatus C. The monitoring consequence is that your exemption request rate and your exemption success rate are two different metrics, and you want both per issuer BIN range. You can’t improve what you only log in aggregate.

3DS 2.3 and what it changes for the decision

Several 2.3 features change the economics. Device binding lets an issuer recognise a returning device after one successful strong authentication, which increases the share of payments the issuer is comfortable approving frictionlessly. WebAuthn and Secure Payment Confirmation let the challenge itself be a platform authenticator, a fingerprint or face scan with the browser handling the user interface, which lowers the abandonment cost of a challenge. For the passkey side of that story, see our walk-through of passkeys, FIDO2 and payment authentication under PSD2 SCA. Automated out-of-band transitions reduce the pain of the “jump to banking app and back” flow, which was historically one of the highest-abandonment steps.

In decision terms, all three reduce the cost of a challenge. That moves the break-even in the toy model: a cheaper challenge makes a forced-challenge strategy more attractive on higher-risk transactions, and the exemption strategy should be reserved for transactions where the fraud estimate is truly low.

Building the Authentication Decision Service

In short: Treat the 3DS request as the output of a decision service that takes transaction features and issuer history as input and returns one of three actions: request an exemption, request frictionless without an exemption claim, or force a challenge. Log every outcome so that you can compute fraud rate per band, override rate per issuer and abandonment per path.

Figure 4 shows the shape of such a service. It is deliberately boring: a feature builder, a rules engine that knows which exemptions are legally available, a cost model, and a closed feedback loop.

Figure 4: A 3D Secure decision service. Eligibility rules gate the cost model, and outcome logs feed the quarterly fraud-rate monitor that decides which exemptions are still available.

Layer one: eligibility is a legal constraint, not a model output

Do not let a machine-learning model decide whether the TRA exemption is allowed. Eligibility is a rule: the PSP’s trailing 90-day fraud rate must be within the reference band for the transaction amount. Compute it from your own data, per band, and expose it as a read-only input to the engine. When the rate drifts above a band’s reference rate, the engine must stop selecting that band’s exemption the same day, not at the end of the quarter. In practice teams keep a safety margin, stopping at some fraction of the legal limit, because fraud confirmation lags by weeks.

The same layer enforces the low-value counters and knows whether an MIT mandate exists. It also holds hard overrides: certain merchant categories, sanctions-screened countries and amounts above the TRA ceiling always go to a challenge path.

Layer two: the cost model

Given the set of legal actions, the engine picks the one with the lowest expected cost. A minimal formulation is:

from dataclasses import dataclass

@dataclass
class Option:
    name: str
    p_abandon: float      # chance the shopper leaves on this path
    p_fraud: float        # chance transaction is fraudulent given path
    holds_liability: bool # does the merchant/acquirer keep fraud loss

def expected_cost(opt: Option, amount: float, margin: float,
                  chargeback_fee: float) -> float:
    lost_margin = opt.p_abandon * amount * margin
    fraud_loss = 0.0
    if opt.holds_liability:
        fraud_loss = opt.p_fraud * (amount + chargeback_fee)
    return lost_margin + fraud_loss

def choose(options: list[Option], amount: float,
           margin: float, chargeback_fee: float) -> Option:
    return min(options,
               key=lambda o: expected_cost(o, amount, margin, chargeback_fee))

options = [
    Option("tra_exemption", p_abandon=0.01, p_fraud=0.0006, holds_liability=True),
    Option("frictionless",  p_abandon=0.02, p_fraud=0.0006, holds_liability=False),
    Option("challenge",     p_abandon=0.06, p_fraud=0.0001, holds_liability=False),
]
best = choose(options, amount=120.0, margin=0.30, chargeback_fee=15.0)
print(best.name)

The probabilities in the example are illustrative placeholders, not measured values. In production, p_abandon comes from per-issuer, per-channel history, and p_fraud comes from your risk model with calibration checks. The structure is the useful part: abandonment multiplies margin, fraud multiplies amount, and the liability flag decides whether fraud appears at all.

Two details save you from subtle bugs. First, the frictionless option here means requesting no challenge without claiming an exemption, in which case the issuer may still challenge; model the probability of that explicitly. Second, the holds_liability flag for the exemption option should depend on whether the issuer accepts the exemption, so a more realistic model blends the accepted and overridden outcomes using the per-issuer override rate.

Layer three: the request builder

The decision converts to protocol fields. A TRA decision sets the challenge indicator to “no challenge requested, TRA performed” and passes the evidence the acquirer’s risk engine used. A forced challenge sets the indicator to “challenge requested, 3DS Requestor preference” or, where a rule requires SCA, the mandate value. A trusted beneficiary request sets the 2.2-family indicator for whitelisting. A 3RI request for a subscription renewal references the original authenticated transaction, so the issuer can link renewals to the original setup.

The builder is also where data quality gets enforced. Reject or repair requests with empty device fields, mismatched billing and shipping countries that look like typos, or missing account-age data. An incomplete AReq costs approvals, and the merchant often cannot see why.

Layer four: feedback and monitoring

The last layer is what makes the system trustworthy. Log, per transaction: the action requested, the transStatus returned, the ECI, the final authorization outcome, the issuer BIN, the device channel, and the eventual fraud and chargeback result when it arrives. From those logs compute, at least daily:

Exemption request rate and exemption acceptance rate, per issuer.
Frictionless rate and challenge completion rate, per issuer and per channel.
Rolling 90-day fraud rate per exemption band, on the PSP definition.
Authorization approval rate by authentication outcome.

A drop in challenge completion rate for one issuer is usually an issuer-side outage or an SMS delivery problem, not a consumer behaviour change. A rise in the soft-decline rate on authorization after authentication usually means the evidence was not properly passed on, which is a bug in your own integration. For retry handling after a soft decline that asks for authentication, see our write-up on payment retries and smart retry architecture.

Trade-offs, Gotchas, and What Goes Wrong

In short: The failures that hurt are rarely cryptographic. They are misclassified transactions, silent issuer overrides, stale fraud-rate data, and evidence that gets lost between the 3DS Server and the authorization message.

Evidence lost between authentication and authorization. The most common production bug is a successful authentication followed by an authorization message that omits the authentication value or the ECI. The issuer sees a card-not-present payment with no evidence, declines it as a soft decline asking for SCA, and the customer gets challenged a second time. Add an invariant test: any authorization submitted with a prior Y or attempted result must carry the cryptogram and ECI from that exact authentication, and the 3DS server transaction ID must be stored with the order.

Authentication expiry. The authentication value is not valid forever. Schemes and issuers expect authorization to follow authentication within a bounded window, and long baskets that sit for hours between challenge and capture can fail. Treat the time between authentication and authorization as a monitored metric, and for split shipments or delayed capture check the scheme guidance on whether a fresh authentication or a different transaction type is required.

Amount changes after authentication. If the final amount differs from the authenticated amount, for example a tip, a shipping surcharge or a hotel incidental, the issuer may treat the authorization as unauthenticated. For flows with adjustable amounts, use the authorization types designed for them (pre-authorization, incremental authorization) and verify what your scheme says about which authentication carries over.

Exemption fraud-rate cliffs. Because the TRA bands are keyed on a rolling 90-day fraud rate, a single large fraud event can push a PSP above a band’s limit and remove the exemption for the whole portfolio. Merchants then see a sudden jump in challenge rate and a drop in conversion that is unrelated to anything they changed. The mitigations are portfolio-level: monitor the rate with a margin, and negotiate with your acquirer to understand what trigger levels they apply to you as a merchant, since an acquirer may set stricter internal limits than the legal bands.

Fraud definitions differ. The fraud rate in the RTS counts unauthorised or fraudulent transactions as reported under the PSP’s regulatory reporting. Your own risk team’s fraud definition, which may include friendly fraud or first-party misuse, may be wider or narrower. Reconcile the definitions before you build a band monitor, or your engine will disagree with the figure your acquirer reports.

Issuer inconsistency. Different issuers implement the same protocol differently. Some challenge almost everything above EUR 30 regardless of what you request. Some treat missing optional fields as a red flag. The only defence is data: track outcomes per issuer BIN range and keep a configuration layer that lets you override behaviour per issuer without redeploying.

The challenge is also a fraud surface. SMS one-time passwords can be defeated by SIM swap, and push approvals suffer from approval fatigue and social engineering. SCA reduces card-not-present fraud but it moves attackers toward authorised push scams and account takeover, where the victim authenticates the payment. That is a different control problem, covered in our analysis of authorized push payment fraud and confirmation of payee.

Browser constraints. The 3DS 2.x browser channel uses an iframe and a hidden iframe for device data collection. Third-party cookie restrictions, content security policy headers, and ad blockers can break either. Test the checkout with strict CSP and common privacy settings, because failures show up as silent timeouts rather than errors.

Fallback logic can double charge risk. A common pattern is: try an exemption, and if it is declined with an SCA-required soft decline, retry with a challenge. That is correct, but the retry must reuse the right idempotency scope, otherwise a customer can be charged twice if the first attempt actually succeeded late. Our sibling guidance on payment idempotency keys explains why this class of bug is so persistent.

Regulatory movement: PSD3 and the PSR

The EU is replacing PSD2 with a new Directive (PSD3) and a directly applicable Payment Services Regulation (PSR). According to the Adyen PSD3 explainer, the compromise texts were published on 23 April 2026, approved by the European Parliament’s ECON committee on 5 May 2026, and formal adoption is expected by December 2026, with general application about 21 months after entry into force, which would put it around late 2028 on that timeline. That timeline is a secondary source’s reading and could move; check the Official Journal before you plan on it. The same source reports that the core two-of-three SCA rule remains, that the contactless limit and the TRA exemption conditions may change, and that the PSR introduces an automatic refund right for some impersonation fraud cases with liability on the customer’s bank.

For engineers the implication is modest in the short term: the 3DS protocol will not change because of PSD3, but the exemption thresholds and the liability allocation might, and the impersonation-refund rule shifts incentives toward better detection of authorised-but-coerced payments. Build the exemption thresholds as configuration with an effective date, not as constants in code.

Practical Recommendations

Start from the premise that authentication is a revenue lever with a regulatory ceiling, and manage it like one. Put the decision in one service, keep eligibility rules separate from the cost model, and give risk and payments teams a shared dashboard so that conversion and fraud are never argued from different data.

Sequence the work by payoff. First fix data quality in the AReq, since richer device and account data raises frictionless approval for every merchant with no regulatory downside. Second, make the authorization message carry the authentication evidence correctly, and test that invariant end to end. Third, introduce exemptions, starting with MIT classification for subscriptions and the trusted beneficiary and low-value paths, which need no fraud-rate measurement. Fourth, add TRA exemptions only once you have a reliable 90-day fraud rate per band and an agreement with your acquirer on who holds liability. Fifth, adopt 2.3 features such as passkey-based challenges, and measure the change in challenge completion.

Checklist:

[ ] Every transaction classified as customer-initiated, MIT, MOTO or other, with the mandate reference stored for MIT.
[ ] 3DS Server version and ACS version coverage checked via the preparation message, with a fallback for BINs without 2.x support.
[ ] AReq completeness monitored: share of requests with device ID, addresses and account age populated.
[ ] Authentication value, ECI and server transaction ID stored with the order and echoed to authorization.
[ ] Exemption eligibility computed from a rolling 90-day fraud rate per band, with a safety margin.
[ ] Exemption request rate versus acceptance rate tracked per issuer BIN range.
[ ] Challenge completion and abandonment tracked per issuer and channel.
[ ] Fallback from exemption to challenge is idempotent and does not duplicate charges.
[ ] Thresholds and effective dates stored as configuration, ready for PSD3 changes.
[ ] Contracts reviewed so that liability for acquirer-applied exemptions is explicit.

For the neighbouring problems, interchange fees and least-cost routing interacts with authentication choices because routing and authentication evidence both affect approval rates, and FAPI 2.0 for open banking covers the account-to-account side where SCA is performed by the bank directly through OAuth flows instead of 3DS.

Frequently Asked Questions

What is 3D Secure and how does it relate to PSD2 SCA?

3D Secure is a messaging protocol, now EMV 3DS maintained by EMVCo, that lets a merchant ask the card issuer to authenticate the shopper before authorization. PSD2 SCA is the legal requirement to use two independent factors for most electronic payments. In card-not-present commerce, EMV 3DS is the standard way to carry out and prove SCA. The protocol also transports exemption requests, so the same message flow can result in frictionless approval, a challenge, or an exempt payment.

What is the difference between frictionless and challenge flow?

In a frictionless flow the issuer’s access control server approves the authentication using the data in the request, such as device, account history and amount, with no cardholder interaction. The response returns transStatus Y with the authentication value. In a challenge flow the issuer asks for an action, such as a banking-app approval, biometric or one-time code, and the result arrives afterwards. Frictionless rates depend heavily on data quality and issuer risk appetite, so they vary by issuer.

Which SCA exemptions apply to online card payments?

The main ones are low-value payments up to EUR 30 with cumulative limits of EUR 100 or five consecutive transactions, transaction risk analysis with ceilings of EUR 100, 250 or 500 tied to PSP fraud rates of 0.13%, 0.06% and 0.01%, trusted beneficiaries, and recurring payments of the same amount to the same payee. Merchant-initiated transactions and MOTO are out of scope, not exempt. The issuer can always override an exemption request and require SCA.

Who is liable for fraud when a payment uses 3DS?

For a fully authenticated transaction, scheme rules generally move fraud chargeback liability from the merchant to the issuer. If an exemption is applied instead, the party that applied it, commonly the acquirer for a TRA exemption, bears the fraud risk and usually passes it to the merchant by contract. Under PSD2 law the customer is refunded first by their PSP if SCA was not applied when required. Exact rules vary by scheme, so check your rulebook and acquirer agreement.

Does requesting an exemption guarantee no challenge?

No. The exemption flag in the authentication request is a preference. The issuer’s ACS makes the final decision and can respond with a challenge status even when you asked for none, usually because its own risk engine, counters or policy disagree. In that case the transaction becomes a normal challenged payment and the usual liability shift applies if it succeeds. Track the exemption acceptance rate per issuer so you know how reliable your requests are.

Will PSD3 change how 3D Secure works?

The wire protocol is maintained by EMVCo and does not depend on PSD3. What may change is the regulatory layer: exemption conditions, the contactless limit, accessibility requirements and liability for certain impersonation frauds. According to secondary reporting, formal adoption is expected by the end of 2026 with application around two years later, but the timeline is not final. Keep thresholds configurable and watch the Official Journal publication for the final text.