EMV 3‑D Secure (3DS) - Payment Authentication Protocol

In the frictionless flow the ACS authenticates the cardholder using the risk and device data in the AReq without an interactive challenge, returning a successful authentication in the ARes, minimising checkout friction for low-risk transactions.

• Frictionless approval rates and risk-data inputs
• Configuration of risk-based decisioning

• Forcing challenges on low-risk transactions
• Insufficient data for a frictionless decision

In the challenge flow the ACS requires an interactive step-up authentication of the cardholder (via CReq/CRes) before returning a result, used where risk, data quality or regulatory requirements (e.g. SCA) demand stronger assurance.

• Challenge invocation criteria
• Step-up authentication evidence

• No challenge capability where SCA is required

Decoupled authentication allows the ACS to authenticate the cardholder out-of-band, separately from the purchase session (e.g. via the issuer's banking app), with the result returned when complete.

• Decoupled-authentication configuration and timeout handling

• No fallback when decoupled authentication times out

Challenges may use out-of-band, one-time-password, knowledge or biometric methods provided by the issuer/ACS; the method should provide adequate assurance commensurate with the transaction risk and applicable regulation.

• Supported challenge methods and their assurance
• Cardholder enrolment for challenge methods

• Weak or single-factor challenge methods

The Authentication Request (AReq) carries cardholder, transaction, device and merchant data from the 3DS Server through the DS to the ACS; the Authentication Response (ARes) returns the authentication result or indicates a challenge is required.

• AReq/ARes message specifications and field population
• Logs of authentication request/response exchanges

• Incomplete AReq data degrading risk assessment

Where a challenge is required, the Challenge Request (CReq) and Challenge Response (CRes) carry the challenge interaction between the 3DS Client/SDK and the ACS until the cardholder is authenticated or the challenge fails.

• CReq/CRes handling in the client/SDK
• Challenge interaction logs

• Challenge UI/flow not correctly handling CReq/CRes

The Results Request (RReq) and Results Response (RRes) convey the final authentication result from the ACS through the DS to the 3DS Server after a challenge, completing the authentication and providing the authentication value for authorisation.

• RReq/RRes handling and result reconciliation
• Authentication value passed into authorisation

• Authorisation proceeding without reconciling the final result

3DS messages are exchanged in a defined, versioned format (EMV 3DS 2.x), with message integrity and authenticity protected; the Preparation (PReq/PRes) exchange and error messages support version negotiation and fault handling.

• Protocol version support and negotiation
• Message integrity/error-handling configuration

• Running unsupported/legacy protocol versions
• No error-message handling

For browser transactions, 3DS uses the 3DS Method (a hidden browser interaction that collects browser/device data before the AReq) and renders any challenge in the browser, exchanging data via the 3DS Server.

• 3DS Method integration on the merchant site
• Browser data-collection configuration

• 3DS Method not invoked, reducing data for risk assessment

For app transactions the 3DS SDK collects a defined set of common and platform-specific device information during the AReq to support risk assessment, and renders native challenge screens; device data collection should be limited to that defined by the specification.

• SDK device-information collection configuration
• Data-minimisation review of collected device elements

• Collecting device data beyond the specified set

3DS supports 3DS Requestor-Initiated (3RI) authentications (e.g. for recurring or merchant-initiated transactions) and non-payment authentication (NPA, e.g. card add/verification), reusing the protocol outside an interactive payment.

• 3RI/NPA use-case configuration
• Records distinguishing payment vs non-payment authentications

• Misusing NPA where a payment authentication is required

The DS and ACS use the rich transaction, device and contextual data carried by 3DS to assess the risk of a transaction and decide frictionless vs challenge, supporting issuer fraud strategies while limiting friction.

• Risk-based decisioning rules and data inputs
• Fraud/approval performance monitoring

• Risk decisions made on insufficient or poor-quality data

EMV 3DS conveys the data needed to apply Strong Customer Authentication (SCA) under PSD2 and to claim SCA exemptions (e.g. transaction risk analysis, low-value, trusted beneficiary, recurring), carrying exemption indicators and the dynamic-linking data binding amount and payee.

• SCA and exemption indicator configuration
• Dynamic-linking (amount/payee) data handling
• Exemption eligibility evidence

• Claiming exemptions without the supporting data
• Dynamic linking not conveyed for SCA transactions

3DS messages and challenge data are protected using cryptographic signing/encryption and managed keys/certificates between the protocol components, preserving confidentiality and integrity of authentication data in transit.

• Key/certificate management for 3DS components
• Transport and message encryption configuration

• Expired or poorly managed keys/certificates
• Unencrypted authentication data

3DS implementations should protect cardholder and authentication data and minimise the personal/device data exchanged to that required by the protocol and risk assessment, consistent with applicable data protection law.

• Data-protection assessment of 3DS data flows
• Data-minimisation and retention controls for authentication data

• Retaining authentication/device data beyond need
• Sharing data beyond protocol requirements

3DS Server, Directory Server, Access Control Server and 3DS SDK products are tested and approved by EMVCo for conformance to the EMV 3DS specifications; implementers should use approved products and maintain conformance across versions.

• EMVCo Letters of Approval for the 3DS components in use
• Version/conformance maintenance records

• Deploying unapproved or out-of-date 3DS components

3DS structures the ecosystem into three domains: the Acquirer Domain (the merchant and its 3DS Server), the Issuer Domain (the card issuer and its Access Control Server) and the Interoperability Domain (the Directory Server and scheme infrastructure connecting the two), enabling exchange of authentication data between merchant and issuer.

• Architecture documentation mapping the implementation to the three domains
• Role assignments per domain

• Unclear domain boundaries between acquirer/issuer/interoperability components

The 3DS Requestor (e.g. the merchant or its 3DS Requestor Environment) initiates authentication on behalf of the cardholder; the 3DS Client (browser or app) interacts with the cardholder. The Requestor passes transaction and contextual data into the protocol.

• 3DS Requestor integration documentation
• Configuration of the 3DS Requestor Environment

• Requestor not passing required transaction/contextual data

The 3DS Server, in the Acquirer Domain, formats and sends Authentication Requests to the Directory Server, receives responses, and manages the 3DS message exchange on behalf of the 3DS Requestor. EMVCo approves 3DS Server products for protocol conformance.

• 3DS Server deployment and EMVCo approval evidence
• Message-handling configuration

• Using a non-approved 3DS Server
• Improper message construction

The Directory Server (DS), operated by the payment scheme in the Interoperability Domain, routes messages between 3DS Servers and Access Control Servers, identifies the appropriate ACS, and enforces scheme rules. EMVCo approves DS products.

• DS routing and scheme-rule configuration
• EMVCo DS approval

• Misrouting between acquirer and issuer domains

The Access Control Server (ACS), in the Issuer Domain, performs cardholder authentication on behalf of the issuer, decides frictionless vs challenge, conducts the challenge where required, and generates the authentication value/result. EMVCo approves ACS products.

• ACS deployment and EMVCo approval
• Authentication-decision configuration

• ACS authentication decisioning not aligned to issuer risk policy

The 3DS SDK is the component embedded in a merchant mobile app that interacts with the 3DS Server and ACS, collects device information, and renders the challenge UI for app-based transactions. EMVCo approves 3DS SDK products.

• 3DS SDK integration and EMVCo approval
• Device-data collection configuration

• Using an unapproved or outdated SDK