Demivolt logo

3D Secure SCA for EU Merchants: Prove PSD2 Compliance with 3DS2

Published 31 August 2026

Practical SCA guide for EU payment teams: implement EMV 3DS2 2.2, run two week shadow tests, capture CAVV and ECI, and reduce PSD2 challenge rates.

3D Secure SCA for EU Merchants: Prove PSD2 Compliance with 3DS2

EMV 3D Secure version 2 is the primary technical mechanism merchants use to satisfy PSD2 Strong Customer Authentication for card-not-present payments. Deploying it correctly means supporting two independent authentication factors, honoring dynamic linking, and handling exemptions with clean data. Get those three things right, and you meet EMVCo’s technical bar while keeping checkout friction low. Get them wrong, and you risk both a compliance gap and a liability exposure that no amount of customer service can undo after the fact.

TL;DR:

  • Supporting complete and accurate data fields in 3DS2 requests directly reduces challenge rates and improves frictionless approval chances.
  • Implementing version 2.2 or later and tracking issuer-specific declines can identify data gaps causing unnecessary challenges.
  • Validating and retaining the ECI, CAVV/TAVV, and result codes is critical for proving liability shift in disputes, minimizing chargebacks.
  • Using exemptions like TRA, low-value, trusted beneficiaries, and corporate status helps maintain low challenge rates but requires proper monitoring and data collection.
  • Fallback processes for unsupported or failed 3DS2 transactions are essential, with version fallback to 3DS1 and testing failure scenarios to maintain authentication resilience.

Table of Contents

How EMV 3DS2 Maps to PSD2 SCA Requirements

PSD2’s Strong Customer Authentication rule requires two of three independent elements: something the customer knows (a PIN or password), something they have (a phone, a card, a hardware token), and something they are (a fingerprint or face scan). EMV 3DS2 was engineered specifically to carry these factors through a card-not-present transaction. A customer entering a one-time code sent to their registered mobile app satisfies possession; a biometric prompt inside a banking app satisfies inherence. Neither factor works in isolation under the regulation, and 3DS2 is built to request and relay both.

Dynamic linking is the piece merchants underestimate most. The European Commission’s SCA rules require that the authentication code generated for a transaction be cryptographically tied to the exact amount and the exact payee. That code, delivered as a CAVV or TAVV value depending on the card network, proves to the issuer that the customer authenticated this purchase, not a generic login. Change the amount after authentication and the code no longer validates.

What makes 3DS2 meaningfully different from its predecessor is the volume of contextual data it carries into the issuer’s risk engine:

  • Device data, including device ID, browser fingerprint, and IP reputation signals
  • Merchant category code and prior transaction history with that cardholder
  • Shipping address match against billing address
  • Account age and behavioral patterns tied to the cardholder profile
  • Transaction amount, currency, and time-of-day context

EMVCo recommends adopting version 2.2 or later wherever your acquirer and gateway support it, since earlier 2.x releases carry a thinner data set and fewer exemption signals.

SCA Exemptions and When Frictionless Authentication Applies

Not every transaction needs a challenge screen, and PSD2 was written with that in mind. Four exemptions cover most of the frictionless traffic you will see in production:

  1. Transaction Risk Analysis (TRA), available to payment service providers whose fraud rates stay under set thresholds, scaled to transaction value. Only PSPs that report and maintain low fraud ratios can invoke it.
  2. Low-value exemption, which applies to transactions under €30, subject to a cumulative counter that forces a challenge once prior exempted spend crosses a running limit.
  3. Trusted beneficiaries, where the cardholder has added the merchant to an issuer-maintained allowlist, removing the need for repeat authentication on recurring purchases.
  4. Corporate exemption, reserved for business card payments processed through dedicated secure protocols not accessible to consumers.

TRA carries the heaviest ongoing obligation. Claiming it means continuously monitoring and reporting your fraud rate to your acquirer, since exceeding the threshold pulls the exemption for future transactions. The 3DS2 message itself carries the exemption flag and supporting risk data the issuer needs to approve a frictionless flow, so incomplete data fields are the most common reason a requested exemption gets silently overridden into a challenge.

Before flagging a transaction for exemption, run through this quick check: confirm the PSP’s current fraud rate against the relevant threshold, verify the transaction value against the low-value cap and its rolling counter, confirm whether the cardholder has whitelisted the merchant with their issuer, and confirm the 3DS message includes complete device and merchant context data. Miss any one of these and the issuer will likely default to a challenge regardless of what your system requested.

Liability Shift, Chargebacks, and Authentication Outcomes

Liability shift is the financial reason this whole framework matters to a merchant’s bottom line. When a transaction completes authentication, whether frictionless or through a challenge, liability for fraud-related chargebacks typically moves from the merchant to the issuer. Visa’s PSD2 guidance documents this shift as conditional on the merchant correctly capturing and storing the authentication value returned by the network.

Three distinct outcomes matter here, and they carry different risk profiles:

  • Frictionless success: the issuer approved based on risk data alone, no challenge shown, liability generally shifts.
  • Challenge success: the customer completed a step-up (OTP, biometric, banking app approval), liability generally shifts and you gain the strongest evidence trail.
  • Failed or abandoned authentication: the transaction should not proceed, or proceeds without liability protection if pushed through as a soft decline workaround.

To prove any of these outcomes after the fact, you need to capture and retain the Electronic Commerce Indicator (ECI), the CAVV or TAVV authentication value, and the specific authentication result code returned by the directory server. Missing even one of these fields when a chargeback arrives puts you back in the position of arguing liability without documentation.

Merchants without complete evidence retention for these transaction indicators frequently lose disputes they would otherwise have won, since issuers and acquirers require the authentication value on file to validate the liability shift claim. Track your challenge rate, your issuer-specific decline patterns, and your frictionless approval rate monthly. A sudden spike in declines from one issuer often signals a data field problem, not a fraud problem, and misconfigured authentication flows contribute meaningfully to the billions merchants lose annually to avoidable payment declines.

Implementation Checklist: What to Build, Test, and Monitor

Rolling out EMV 3DS2 correctly is a sequencing problem as much as a technical one. Start with your gateway and Access Control Server relationship, then work outward to data, testing, and monitoring.

Foundation first:

  • Confirm your acquirer or gateway supports EMV 3DS version 2.2 or later before you build anything, since older versions cap the data you can send and the exemptions you can request.
  • Plan your SDK or API integration path with explicit version negotiation, so a fallback to an earlier protocol version does not silently degrade your authentication quality.
  • Map every required and optional data field your ACS accepts, including device fingerprinting parameters, shipping and billing address detail, and merchant risk indicators.

Testing before launch:

  • Simulate soft-decline scenarios deliberately, sending intentionally incomplete requests to confirm your system handles the rejection gracefully rather than failing the transaction outright.
  • Run full challenge flows end-to-end, including the customer-facing step-up screen, to confirm your checkout does not break or time out during redirect.
  • Test fallback and fall-forward paths for cases where 3DS is unavailable, unsupported by the issuer, or returns an error.
  • Build regression tests that run against every gateway update, since ACS behavior can shift without much notice from your provider.

After launch, monitoring becomes the real compliance work. Track your challenge rate and successful authentication rate weekly, set automated alerts for soft-decline spikes tied to a specific issuer, and retain authentication evidence, including CAVV/TAVV values and result codes, for at minimum the dispute window your acquirer specifies. A secure payment workflow built around structured monitoring catches most integration drift before it becomes a chargeback problem.

Pro Tip: Run your exemption logic through a shadow test against live traffic for two weeks before flipping it on for real transactions. You will usually find at least one data field silently missing that would have pushed exempted transactions into unwanted challenges.

Common Integration Mistakes and a Practical Testing Checklist

Soft declines are the single most preventable source of lost revenue in a 3DS2 integration, and they almost always trace back to one of three root causes.

  1. Missing or malformed transaction indicators. A blank device data field, an incorrectly formatted merchant category code, or an omitted cardholder account age field can each independently trigger a soft decline, even when the underlying payment details are correct.
  2. Outdated protocol versions. Integrations still running 3DS version 2.0 or 2.1 send a thinner data payload, which gives issuers less basis for a frictionless decision and pushes more traffic into challenges than necessary.
  3. Incomplete evidence capture on the response side. Some integrations correctly send the authentication request but fail to parse and store the ECI value or the CAVV/TAVV returned, which means the liability shift proof simply does not exist when a dispute arrives later.

Validate your integration by confirming that every successful authentication response includes a stored ECI value, a stored CAVV or TAVV, and a stored result code, checked against a sample of real transactions rather than test data alone. Set automated alerts for any issuer showing a decline rate that jumps well above its historical baseline, since that pattern usually points to a data or protocol issue on your side rather than a change in fraud risk. When a soft decline does occur, a smart retry with corrected data, or offering an alternative payment method at checkout, recovers far more revenue than simply displaying a generic error to the customer.

Pro Tip: Keep a running log of which issuer BINs generate the most soft declines. Patterns by issuer often reveal a specific missing field that a single fix resolves across dozens of transactions at once.

Demivolt’s Perspective on Supporting Compliant Payment Workflows

Demivolt operates as a regulated European fintech, and the infrastructure behind dedicated IBAN accounts, SEPA and SWIFT payment processing, and virtual and physical business cards was built with exactly this kind of evidence trail in mind. When a payment team needs to demonstrate that a transaction was properly authenticated, having clean account structures and role-based access controls in place makes that documentation retrieval far less painful than reconstructing it after the fact.

For businesses building or auditing their own SCA workflows, that operational clarity matters as much as the authentication protocol itself:

  • Dedicated IBAN accounts keep transaction records segregated and traceable per business unit
  • Role-based user management supports clean audit trails when a dispute requires proof of who approved what
  • Card programme infrastructure for virtual and physical cards ties spend controls directly to authentication events

Deeper configuration guidance on securing cross-border payment flows lives in Demivolt’s checklist for secure cross-border payments.

What the Authentication Flow Actually Looks Like for the Customer

From the shopper’s side, EMV 3DS2 is designed to be invisible more often than not. A customer enters their card details, clicks pay, and in the majority of well-configured frictionless flows, the transaction simply completes. No redirect, no code to type, no waiting.

When a challenge does trigger, the flow typically unfolds in seconds rather than minutes. The customer sees a branded overlay from their card issuer, not the merchant, requesting either a one-time passcode sent by SMS, a push notification approved inside a banking app, or a biometric prompt if the issuer’s app supports it. This happens within the same browser session or checkout window, with no separate app download required in most implementations.

The design intent behind 3DS2, compared to its predecessor, was to shrink this window of friction as much as possible while still meeting the regulatory bar. A customer who abandons a cart because a challenge screen felt slow, confusing, or unfamiliar represents a real cost, and issuers have gradually improved their challenge screen design (biometric-first prompts, in-app push approvals) specifically to reduce that abandonment. Merchants have limited control over what the issuer’s challenge screen looks like, but they have significant control over whether a challenge triggers at all, through the quality of data sent in the authentication request.

Does 3D Secure SCA Hurt Conversion, and What Can Merchants Do About It

Every additional screen in a checkout flow carries some conversion risk, and a 3DS challenge is no exception. The mitigation lever available to merchants is not avoiding 3DS2, which is not realistically optional under PSD2, but minimizing how often a challenge triggers unnecessarily.

Sending complete, accurate data in the authentication request is the single biggest lever here. Richer device and transaction context gives issuers the confidence to approve frictionlessly rather than defaulting to a challenge out of caution. Merchants who treat the 3DS data payload as an afterthought, filling only the mandatory fields, tend to see meaningfully higher challenge rates than those who populate every optional field their ACS accepts.

Beyond data quality, a few operational moves help directly:

  • Encourage repeat customers to add your business to their issuer’s trusted beneficiary list, removing future challenges entirely for that relationship.
  • Monitor your fraud rate closely enough to maintain TRA exemption eligibility, since losing that exemption pushes previously frictionless traffic into challenges.
  • Review issuer-specific decline and challenge patterns monthly, since some issuers apply more conservative risk logic than others and may need a targeted data fix.

A review of device data and risk signal handling is worth revisiting periodically, since risk-scoring models on both the merchant and issuer side evolve, and data that reduced friction a year ago may no longer carry the same weight.

Where PSD2 Sits Within the Broader Global Picture

PSD2 is a European Union directive, and its Strong Customer Authentication mandate legally applies only within the EEA. That scope matters for any business processing payments across multiple regions, since the compliance obligations that govern a Lithuanian or French transaction do not automatically extend to a customer paying from the United States or Singapore.

Outside the EEA, adoption of EMV 3DS2 has spread largely for commercial rather than regulatory reasons. Card networks including Visa and Mastercard have pushed 3DS2 adoption globally because the fraud-reduction and data-richness benefits hold regardless of jurisdiction, even where no legal mandate exists. Some markets, including India and parts of Latin America, have introduced their own authentication mandates that closely resemble SCA in structure, though the specific rules and thresholds differ from PSD2’s requirements.

For a merchant operating across both EEA and non-EEA markets, the practical answer is usually to run EMV 3DS2 universally rather than segment logic by region. The legal basis for SCA sits in the PSD2 directive itself, but the fraud-prevention value of the protocol doesn’t stop at the EEA border, and maintaining two separate authentication logic paths introduces more integration risk than it saves.

What Happens When 3DS Isn’t Available or Fails

Not every transaction gets a clean path through 3DS2. Issuers occasionally don’t support the protocol version a merchant requests, an ACS server can time out, or a customer’s card simply wasn’t enrolled at the time of the transaction. Each of these scenarios needs a defined fallback rather than an outright decline.

The most common fallback is version fall-back, where a 3DS2 request that the issuer’s ACS cannot process gets automatically retried under 3DS1 protocol if the acquirer supports it. This preserves some authentication attempt rather than abandoning the transaction, though it comes with weaker liability protection than a full 3DS2 completion, since 3DS1’s thinner data set gives issuers less to work with.

When authentication genuinely cannot be attempted, whether due to an ACS outage or a card that isn’t 3DS-enrolled, merchants face a choice between processing the transaction without SCA protection, which carries no liability shift and higher fraud exposure, or declining it outright. Most gateways document a fall-forward parameter that lets a merchant specify this preference in advance rather than making the decision transaction by transaction.

Building resilience here means testing these failure paths deliberately rather than discovering them during a real ACS outage. A checklist covering secure online transaction handling should include simulated ACS timeout scenarios specifically, since that failure mode is rare enough in normal testing that many integrations never exercise it before it happens in production.

3DS1 vs EMV 3DS2: What Actually Changed

The original 3D Secure protocol, now generally called 3DS1, worked, but it earned a reputation for wrecking checkout conversion. It relied almost entirely on static passwords set up in advance, redirected customers to often-unstyled bank pages that looked like phishing attempts, and worked poorly or not at all on mobile browsers.

EMV 3DS2 addressed each of these weaknesses directly. It supports native in-app authentication instead of forcing a browser redirect, meaning a customer paying inside a mobile app authenticates without ever leaving that app’s interface. It carries roughly ten times the data fields of 3DS1, which is precisely what allows issuers to approve many transactions frictionlessly instead of challenging by default. And it supports biometric authentication methods, including fingerprint and facial recognition, that didn’t exist as practical options when 3DS1 launched.

The practical user impact is significant. Where 3DS1 challenged nearly every enrolled transaction with a static password prompt, 3DS2’s risk-based data model lets a meaningful share of transactions skip the challenge screen entirely when fraud risk signals are low. For merchants who migrated late or ran a thin data integration, the difference between the two protocols in practice often comes down to how much of that richer data set they actually populate, not just which protocol version their gateway reports.

Get Your Payment Infrastructure Ready for SCA Compliance

Demivolt supports business clients building compliant payment operations with dedicated IBAN accounts, SEPA and SWIFT processing, and virtual and physical business cards, all structured within a regulated European framework designed for cross-border operations. Clean account architecture and role-based access controls give payments and compliance teams the documentation trail that SCA disputes often demand.

If your business is validating IBANs as part of onboarding new payment relationships, Demivolt’s free IBAN validator checks format compliance against the ISO 13616 standard before a transaction ever reaches an authentication step. Get started with Demivolt to explore account structures built for businesses managing SCA-compliant payment flows across multiple markets.

The Compliance Work Nobody Wants to Admit Is Mostly Data Hygiene

The industry conversation around SCA tends to fixate on the regulation itself, when the actual failure point for most merchants is far more mundane: incomplete data fields in the 3DS2 request. Nobody gets excited about checking whether a shipping address field is populated correctly, but that unglamorous detail determines whether a transaction gets a frictionless approval or an unnecessary challenge.

The conventional advice, “implement 3DS2 and you’re SCA compliant,” is technically true and practically useless. Implementation quality is the entire game. A merchant running 3DS2 version 2.0 with sparse data fields is nominally compliant and functionally worse off than one running version 2.2 with a fully populated payload, because the thin integration pushes far more traffic into challenges, and challenges are where conversion dies.

If there’s one place to focus first, it’s evidence retention. Compliance teams tend to treat the authentication event as the finish line, when the real test comes months later during a chargeback dispute, and that’s precisely when missing CAVV or ECI records turn a winnable case into a lost one.

— dd

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Sources

Related to this article

Business accounts

Business accounts, dedicated IBANs, payments, cards and currency for companies working directly with Demivolt.

Learn more