EMV 3-D Secure Guide: Protocol Flows, Data Elements, 3RI and Liability

EMV 3-D Secure decides whether an online card payment is authenticated silently, challenged, or sent to authorisation with no protection, and most merchants control far less of that outcome than they think and far more than they use. EMV 3DS is EMVCo's protocol for authenticating card-not-present payments: the merchant sends transaction, device and cardholder data to the card issuer, which either approves frictionlessly or asks the cardholder to prove who they are. This guide goes below the summary level to the protocol itself: the components and messages, the data elements that drive frictionless approval, challenge indicators, 3DS Requestor Initiated (3RI) and decoupled authentication, delegated authentication, Secure Payment Confirmation and the PCI 3DS security standard. It is written for payments engineers, fraud teams and architects at merchants, payment service providers and issuers. The regulatory side, PSD2 strong customer authentication and its exemptions, is covered in the PSD2/PSD3 Strong Customer Authentication Guide, and the wider fraud and dispute picture in the Payment Fraud Guide.

Key takeaways

• Data quality decides the frictionless rate. EMVCo states that incomplete or dummy values in the authentication request lead to more challenges or declined authentication.
• Use v2.2 or later. EMVCo recommends v2.2 or higher for optimum functionality; 3RI payment authentication, decoupled authentication and the information-only flow depend on it, and Secure Payment Confirmation data elements arrive in 2.3.1.
• The challenge indicator is a request, not a command. The issuer's access control server makes the final decision, whatever exemption or preference the merchant signals.
• 3RI keeps merchant-initiated payments linked. Recurring and instalment payments should reference the original authentication's transaction IDs so the issuer can recognise them.
• The liability shift is a card scheme rule, not part of the protocol. Keep the authentication value, ECI and DS transaction ID with every order, and confirm the rules with your acquirer.

What it is and who it applies to

EMVCo, the body owned by the major card schemes that manages EMV specifications, describes EMV 3DS as a way for issuers and merchants to exchange data to verify the cardholder for card-not-present purchases, approving most transactions without extra steps and stepping up higher-risk ones with a challenge such as a one-time passcode, biometrics or knowledge-based questions. It supports browser and in-app purchases and a non-payment message category used, for example, for account verification.

The protocol is organised in three domains, each with its own components:

Who it applies to: any merchant or PSP accepting cards online in a market where schemes or regulators require or reward authentication. In the EEA and UK it is the main way to deliver strong customer authentication for card payments. Elsewhere it is used selectively for liability shift and higher-risk orders, and some markets mandate it, the W3C cites India as an example.

Versions: EMVCo publishes specification documents for v2.2.0 and v2.3.1. As checked on 8 November 2026, v2.4.0.0 documents (Protocol and Core Functions, SDK and Split-SDK specifications) were published as drafts on 4 November 2026 for associate comment until 8 January 2027. Draft content can change, so do not design to v2.4 details yet.

Structure and key requirements

Message flow

1. Card range and 3DS Method: the 3DS Server checks the card range data to find the ACS protocol versions and any 3DS Method URL. If the issuer requests it, the merchant must run the 3DS Method, a hidden browser call that lets the ACS collect device data. EMVCo says it typically completes within 5 seconds, and the merchant can still send the request if it does not.
2. AReq and ARes: the 3DS Server sends the authentication request (AReq) through the DS to the ACS, which replies with an authentication response (ARes) carrying a transaction status.
3. Challenge (CReq and CRes): if the status is C, the cardholder completes a challenge in a browser iframe or SDK screen, exchanging challenge messages directly with the ACS.
4. Result (RReq and RRes): after a challenge, the ACS sends the final result to the 3DS Server through the DS in a results request, which the 3DS Server acknowledges.
5. Authorisation: the merchant sends the authorisation with the authentication value, ECI and DS transaction ID.

Transaction status values

Data elements that drive frictionless approval

EMVCo's whitepaper groups the risk data into four sets and strongly recommends populating every field available:

• Browser data: accept headers, IP address, user agent, language, time zone offset, screen colour depth, height and width, and JavaScript enabled.
• App data: SDK Encrypted Data, device information such as model, OS version and locale, encrypted by the 3DS SDK with the DS public key.
• Cardholder data: billing and shipping address, Address Match Indicator, email, home, mobile and work phone numbers, and cardholder name.
• Relationship data: Cardholder Account Information (account age and change history), 3DS Requestor Authentication Information (how and when the merchant logged the customer in), and 3DS Requestor Prior Transaction Authentication Information (a reference to an earlier successful authentication).

Challenge indicator

The values 01 to 04 are listed in the W3C 3DS with Payment Request draft; 08 and 09 in EMVCo's whitepaper. Requesting no challenge is how merchants and PSPs signal that they want an exemption, such as transaction risk analysis under PSD2, but the ACS can still challenge.

3RI and decoupled authentication

3DS Requestor Initiated (3RI) authentication runs without the cardholder present. EMVCo supports 3RI payment authentication from v2.2. The 3RI Indicator says why: 01 recurring, 02 instalment, 05 account verification with recurring data, and 10 a Trust List status check. For subsequent payments the merchant sends the DS Transaction ID and/or ACS Transaction ID from the initial authentication so the ACS can link them, and the ACS shows the recurring terms (amount, frequency, expiry) during the initial challenge.

Decoupled authentication lets the cardholder authenticate outside the checkout, for example in a banking app, while the merchant waits. The merchant signals it with the 3DS Requestor Decoupled Request Indicator and sets 3DS Requestor Decoupled Max Time in minutes. EMVCo notes it applies to all device channels and is the only cardholder challenge method for 3RI, which suits telephone orders, split or delayed shipments and subscriptions. It also serves as a fallback: if a challenge fails, the ACS can send D in the RReq, the 3DS Server acknowledges with Result Message Status 04 and starts a 3RI transaction.

Identity and NHI requirements

3DS is a cardholder authentication protocol, but the merchant's own identity signals and machine credentials feed it directly.

• Delegated authentication: under a prior agreement, the issuer delegates cardholder authentication to a third party such as the merchant. The merchant authenticates the customer, for example with a FIDO passkey, and reports the method, data and timestamp in 3DS Requestor Authentication Information. The ACS still assesses risk and may challenge. A strong login is therefore worth recording accurately; see the Passwordless and Passkeys Guide.
• Secure Payment Confirmation (SPC): a W3C API, a Candidate Recommendation Draft as of 13 October 2026, that builds on WebAuthn with a payment extension. The browser shows the payee name and origin, amount and instrument, and the signed assertion covers those details. In 3DS 2.3.1 the merchant-initiated flow returns transStatus S with a WebAuthn Credential List; the merchant calls SPC, then sends a second AReq with Authentication Method 09 and Prior Transaction Authentication Information method 05, and the ACS verifies the assertion. SPC can also run inside an issuer challenge (Authentication Method 14). See the FIDO2 and WebAuthn Internals Guide.
• Trust List: during a challenge the ACS can offer to add the merchant to the cardholder's trusted beneficiaries. EMVCo stresses that merchant name, 3DS Requestor Name and 3DS Requestor ID must stay consistent between enrolment and later transactions, or the trust will not match.
• Machine credentials: 3DS Servers authenticate to Directory Servers with scheme-issued client certificates, and SDKs encrypt device data to the DS public key. These are non-human identities with expiry dates and private keys that need inventory, rotation and HSM protection where the standards require it. See the Cryptographic Key Management Guide.

Implementation steps

1. Baseline: measure current authentication, frictionless, challenge and abandonment rates by scheme, issuer country and channel. Check that your 3DS Server supports v2.2 and 2.3.1 for every scheme you accept.
2. Fill the data: map every available browser, cardholder and relationship field. Remove placeholder values such as fixed phone numbers or copied addresses, which EMVCo warns increase challenges.
3. Run the 3DS Method: implement it with a timeout and the correct completion indicator, and never block checkout on it.
4. Set a challenge policy: decide when to send 02 (exemption sought), 03 (preference) or 04 (mandate), driven by your risk engine and regulatory scope. Coordinate exemption flags with your acquirer.
5. Implement 3RI and stored credentials: authenticate the first payment with the cardholder present, store the DS Transaction ID, and use 3RI with the correct indicator for subsequent ones.
6. Add strong merchant login evidence: report passkey or other strong authentication in 3DS Requestor Authentication Information; explore delegated authentication and SPC with your PSP where schemes offer programmes.
7. Pilot and compare: roll changes out to a share of traffic, compare frictionless rate, approval rate and fraud chargebacks against a control group, then expand.
8. Roll back safely: keep data mapping and policy changes behind configuration flags so a drop in authentication success at one issuer or scheme can be reverted without redeploying.

Evidence and assessment

For merchants, the evidence that matters is per-order: the authentication value, ECI, transStatus and transStatusReason, DS transaction ID and protocol version. These support fraud dispute responses and prove which party authenticated. Card scheme rules generally move fraud-related chargeback liability from merchant to issuer for successfully authenticated transactions, and sometimes for attempted ones, but the conditions vary by scheme, region and programme and do not cover non-fraud disputes, so confirm them with your acquirer.

For 3DS component operators, the PCI SSC's PCI 3DS Core Security Standard applies to entities performing 3DS Server, Directory Server or ACS functions. Part 1 sets baseline security for the environment; Part 2 covers 3DS-specific data, technology and processes, with the PCI 3DS Data Matrix listing sensitive data elements and keys subject to HSM requirements. Only qualified 3DS Assessors can assess it. A validated PCI DSS assessment may cover Part 1, but never Part 2. 3DS SDK developers are covered by the separate PCI 3DS SDK Security Standard. The payment brands decide who must validate.

Metrics to track monthly:

• Frictionless rate: share of authentications returning Y without a challenge.
• Challenge success rate and challenge abandonment rate, by issuer and channel.
• Authentication-to-authorisation approval rate, and soft declines requiring SCA.
• Data completeness: share of AReqs with full browser, email, phone and address fields.
• Fraud chargeback rate split by authenticated, attempted and unauthenticated transactions.

Mapping to other frameworks

Common pitfalls

• Dummy data: fixed placeholder emails, phone numbers or copied billing addresses lower the frictionless rate and can cause declines.
• Skipping or blocking on the 3DS Method: issuers lose device data if it is skipped, and customers abandon if checkout waits on it.
• Mandating challenges everywhere: sending 04 on every transaction raises abandonment without regulatory need.
• Re-authenticating recurring payments as new: not using 3RI or not referencing the original DS Transaction ID makes issuers treat renewals as unknown merchant-initiated payments.
• Inconsistent merchant identity: changing 3DS Requestor ID or name breaks Trust List matching and issuer risk history.
• Not storing evidence: without the authentication value, ECI and DS transaction ID on the order, a fraud dispute cannot be defended.

Practitioner checklist

• Confirm 3DS Server support for v2.2 and 2.3.1 across all schemes you accept.
• Audit AReq data completeness and remove placeholder values.
• Implement the 3DS Method with a timeout and correct completion indicator.
• Document a challenge indicator policy linked to your risk engine and SCA scope.
• Use 3RI with correct indicators and original transaction IDs for recurring and instalment payments.
• Report merchant login strength in 3DS Requestor Authentication Information.
• Store authentication value, ECI, transStatus, reason and DS transaction ID with every order.
• Inventory and rotate 3DS Server client certificates and SDK keys before expiry.
• Track frictionless, challenge success, abandonment and fraud chargeback rates by issuer.
• Confirm liability shift and exemption rules with your acquirer each year.

Standards and references

• EMVCo: EMV 3-D Secure
• EMVCo: EMV 3DS Whitepaper v2, risk analysis and frictionless flow
• EMVCo: EMV 3DS Whitepaper v2, decoupled authentication
• EMVCo: EMV 3DS Whitepaper v2, WebAuthn and SPC
• EMVCo: EMV 3DS Whitepaper v2, recurring and instalment transactions
• W3C: Secure Payment Confirmation
• W3C: 3-D Secure 2 with Payment Request API
• PCI SSC: PCI 3DS Core Security Standard overview

Related NHI Mgmt Group resources: PSD2/PSD3 Strong Customer Authentication Guide · Payment Fraud Guide · Network Tokenisation for Payments Guide · Chargeback Management and Dispute Guide