3DS2, SCA, and payment success rates. 7 chapters and a final quiz.

Chapter 1. PSD2 and strong customer authentication: the framework.

PSD2 (Directive (EU) 2015/2366) made SCA (strong customer authentication) a legal requirement for all payer-initiated electronic payments in the European Economic Area. The technical rules are set out in the RTS (Delegated Regulation (EU) 2018/389). The RTS, not the directive itself, define the factors, dynamic linking, and above all the exemptions covered in this course. For an online merchant, SCA is more than a compliance constraint. Handled poorly, it costs several points of conversion. Handled well, it becomes a measurable competitive advantage.

The three authentication factors

• Knowledge: something only the customer knows, such as a password or PIN. The card number, expiration date, and CVV do not count (they are printed on the card).
• Possession: something only the customer has, such as an enrolled phone (banking app, SIM), the card itself via a dynamic cryptogram, or a hardware token.
• Inherence: something the customer is, such as a fingerprint, facial recognition, or behavioral biometrics (accepted by the EBA under certain conditions).
• SCA requires at least two factors from different categories that are independent: compromising one must not compromise the other (PSD2 art. 4(30) and RTS art. 9). An SMS OTP alone (possession) is not SCA. An SMS OTP plus a password is, but the EBA considers it weak (SIM swap risk).

Chapter 2. The 3DS2 flow: frictionless and challenge.

EMV 3DS connects three domains. The 3DS Server sits on the acquirer/PSP side (the merchant domain), the Directory Server (DS) is run by the card scheme (the interoperability domain), and the ACS, or Access Control Server, sits on the issuer side (the issuer domain). The protocol’s value lies in a single message, the AReq (Authentication Request), which carries about a hundred context fields. The ACS uses them to score the risk before deciding whether to challenge the cardholder.

Frictionless or challenge: the ACS decides

{
  "messageType": "AReq",
  "messageVersion": "2.2.0",
  "threeDSRequestorAuthenticationInd": "01",  // 01 = payment; 02 = top-up; 04 = add card
  "threeDSRequestorChallengeInd": "01",       // 01 = no preference; 05 = TRA exemption request (v2.2)
  "acctNumber": "4970100000004321",           // PAN or network token
  "purchaseAmount": "14250",                  // EUR 142.50 (exponent 2)
  "purchaseCurrency": "978",
  "browserIP": "92.184.105.17",
  "browserUserAgent": "Mozilla/5.0 ...",
  "browserTZ": "-120",                        // device time zone offset in minutes
  "deviceChannel": "02",                      // 01 = app SDK, 02 = browser, 03 = 3RI
  "acctInfo": {
    "chAccAgeInd": "05",                      // customer account > 60 days: issuer-friendly signal
    "nbPurchaseAccount": "11",                // purchases over 6 months
    "suspiciousAccActivity": "01"             // no suspicious activity observed
  },
  "merchantRiskIndicator": {
    "shipIndicator": "01",                    // shipping to the billing address
    "deliveryTimeframe": "03",                // ships within 24 h (overnight)
    "reorderItemsInd": "02"                   // reorder of a previously purchased item
  }
}

Chapter 3. Device data and risk scoring.

Where 3DS1 carried about a dozen fields, EMV 3DS carries more than a hundred (up to about 130 via the mobile SDK). These fields are what powers frictionless authentication. The more usable signals the ACS receives, the more often its risk engine can authenticate without a challenge. An integrator that sends only the mandatory fields automatically pushes its customers into challenges, or declines.

• Browser data (deviceChannel 02): IP address, user agent, language, time zone, screen resolution, color depth, Java/JS support, collected via the “3DS Method” (a hidden ACS iframe) before the AReq.
• SDK data (deviceChannel 01, mobile apps): device identifiers, OS version, system settings, integrity indicators. Much richer and more reliable than browser data.
• Merchant risk indicators: shipping method, shipping vs. billing address, delivery timeframe, gift card, preorder, reorder.
• Customer account history (acctInfo): account age, number of purchases over 6 months, card-add attempts in the past 24 hours, suspicious activity observed, age of the shipping address.
• Optional issuer-specific data: 3RI fields and travel and hospitality data (EMV 3DS 2.2/2.3) for industries with deferred authorizations.

{
  "acctInfo": {
    "chAccAgeInd": "05",           // account created more than 60 days ago
    "chAccChangeInd": "04",        // last account change > 60 days ago
    "chAccPwChangeInd": "05",      // last password change > 60 days ago
    "nbPurchaseAccount": "11",     // 11 purchases in the last 6 months
    "provisionAttemptsDay": "0",   // 0 card-add attempts in 24 h
    "txnActivityDay": "1",         // 1 transaction in 24 h
    "txnActivityYear": "14",       // 14 transactions in 12 months
    "shipAddressUsageInd": "04",   // shipping address in use for > 60 days
    "shipNameIndicator": "01",     // shipping name = account holder name
    "suspiciousAccActivity": "01"  // no suspicious activity
  }
}

Protocol versions: 2.1, 2.2, 2.3

• 2.1.0 (2017): the EMV 3DS baseline. No dedicated exemption field, so exemptions are shoehorned into threeDSRequestorChallengeInd.
• 2.2.0 (Dec. 2018): the reference version in Europe. Adds native exemption indicators, decoupled authentication, extended 3RI, and whitelisting indicators (trusted beneficiaries).
• 2.3.1 (2021–2022): device binding, WebAuthn/passkey support (groundwork for SPC), better app-to-app handling, and a richer browser channel. ACS rollout is still gradual.

Chapter 4. Liability shift: who pays for fraud?

The liability shift moves financial liability for fraud (fraud-coded chargebacks) from the merchant to the issuer. It applies in two situations: when the transaction was authenticated, or when the issuer had the opportunity to authenticate it. Authentication costs conversion but protects against fraud chargebacks. That tension is the core economic incentive of 3DS, and it makes every exemption strategy an explicit trade-off between conversion and fraud exposure.

The liability shift is carried technically by the ECI + cryptogram pair sent in the authorization. At Visa, ECI 05 indicates full authentication, 06 an attempt, and 07 an unauthenticated transaction. At Mastercard, 02 means full, 01 attempt, and 00 unauthenticated. A PSP that downgrades the ECI (bad mapping, lost CAVV) silently strips the merchant of its protection. It is a standard audit check.

Chapter 5. SCA exemptions: the complete picture.

The RTS provide for exemptions: the transaction is in scope for SCA but can be exempted from it. Do not confuse these with out-of-scope cases (MIT, MOTO, one-leg, anonymous prepaid), where SCA simply does not apply. The golden rule: the issuer always has the final say. An exemption requested by the acquirer can be refused, in which case the issuer responds with a soft decline to force authentication.

TRA: the key exemption and its thresholds

The rate is calculated for the requesting PSP (the acquirer, for an acquirer exemption), across all its remote transactions, not for the individual merchant. A very clean merchant with a poorly performing acquirer inherits that acquirer’s ceiling. This criterion should weigh in the choice of acquirer, yet it is too often overlooked. Above €500, there is no TRA exemption. A challenge becomes mandatory unless another exemption applies (trusted beneficiaries, recurring) or the transaction is out of scope.

MITs and out-of-scope transactions. A merchant-initiated transaction (subscription, usage-based charge, top-up) is out of scope rather than exempt, because the cardholder is not present to authenticate. In return, the initial transaction that sets up the mandate (card registration, first payment) must be authenticated with SCA. Each MIT must then be chained to that initial transaction via the network transaction ID. Issuers increasingly decline MIT flags without valid chaining.

Chapter 6. 65/1A soft declines: the decline that isn’t one.

A soft decline is not a refusal to pay: the issuer is saying, “I want authentication before I authorize.” It happens when an authorization arrives with neither authentication nor an accepted exemption, for example a rejected TRA exemption request, a badly flagged MIT, or a legacy non-3DS flow. Treating it as a hard decline loses the sale. This conversion leak is one of the most expensive, and one of the easiest to fix.

1) POST /authorize        amount EUR 89.00, ECI 07, acquirer TRA exemption flag
   < response_code: 65    Visa -- "Authentication requested" (soft decline)
                          Mastercard equivalent: code 1A

2) The PSP automatically triggers 3DS2 authentication
   AReq -> ARes transStatus "C" -> banking app challenge -> RReq "Y"
   CAVV generated, ECI changes to 05

3) POST /authorize        same amount, ECI 05 + CAVV
   < response_code: 00    Approved

Total added time: 15 to 45 s (the time the challenge takes).
Recovery rate observed after authenticated retry: 70% to 90%.

Instrumentation relies on three distinct metrics, each tracked separately. The share of soft declines among all declines reveals an overly aggressive exemption strategy or badly flagged MITs. The authenticated retry trigger rate should approach 100% of 65/1A responses. Finally, the recovery rate should land at 70% to 90%. Below that, look for a problem with the challenge UX or an ACS failing on certain BINs.

Chapter 7. Exemption strategy and payment success optimization.

An exemption strategy is more than a list of flags. It takes the form of a per-transaction decision tree, driven by the amount, the customer segment, the issuer BIN, and each issuer’s response history. The best setups make it dynamic: they learn, issuer by issuer, which exemption requests are accepted and adjust routing accordingly.

• Out of scope first: properly chained MIT? MOTO? One-leg? → direct authorization with the right indicators, no 3DS.
• Authenticating wallet (Apple Pay/Google Pay with CDCVM)? → SCA is delegated to the device, no merchant 3DS.
• Amount ≤ €30 → try LVP (accepting the risk of a surprise challenge when the counters are hit).
• Amount ≤ the acquirer’s TRA ceiling and a clean segment → request the TRA exemption, either in a direct authorization or via the 3DS2 flag (v2.2).
• Otherwise → full 3DS2 with as much data as possible (acctInfo, merchant risk indicators) to aim for frictionless.
• In all cases → automatic handling of 65/1A soft declines with an authenticated retry.

Measure the end-to-end payment funnel

• Issuer-friendly data: complete acctInfo, consistent name and address, unmasked IP address. The cheapest lever.
• Smart retries: beyond soft declines, separate retryable declines (05 “do not honor,” retried later) from final ones (14, 41, 43: never retry).
• Multi-acquirer routing: route each BIN to the acquirer that gets the best authorization rate and the highest TRA ceiling; typical gains of 1 to 3 points.
• Network tokens: authorization rates 2 to 3 points higher on average for card-on-file transactions (see the Tokenization course).
• Delegated authentication / SPC: delegate SCA to the merchant or the device (passkeys) to eliminate the challenge. Still emerging, and worth watching.