← Payment Reference GuidesAuthentication Reference

3D Secure / EMV 3DS

The cardholder authentication protocol for card-not-present transactions. 3DS2 adds frictionless, decoupled, and challenge flows while enabling SCA compliance under PSD2 and reducing CNP fraud liability.

Authentication Flows

EMV 3DS defines three authentication flows. The issuer's ACS selects the appropriate flow based on risk analysis of the data in the AReq.

Animated flow — frictionless vs. challenge

EMV 3DS2 risk-based authentication where the issuer ACS approves on data alone — no cardholder interaction. The common path for low-risk transactions.

1 / 5
🧑CardholderBrowser / app
🛒3DS ServerMerchant / 3DS SDK
🔗DirectoryScheme DS
🏛️ACSIssuer ACS
1
Checkout
2
AReq
3
Routed to ACS
4
ARes (Approved)
5
CAVV Returned
Initiation

Checkout

Cardholder confirms payment on the merchant.

The merchant 3DS SDK / 3DS Server gathers device and browser data (3DS Method) to enrich the authentication request.

Initiation
3-D Secure
Response
Completion
Frictionless

Frictionless Flow

Zero cardholder interaction required

  1. 3DSS collects browser/device data and sends AReq to DS
  2. DS routes AReq to the correct ACS based on card BIN
  3. ACS performs device fingerprinting and risk analysis on the 100+ data elements
  4. ACS determines low risk — sends ARes with transStatus=Y (or A for attempt)
  5. ARes contains the CAVV (authentication value) and ECI
  6. Merchant proceeds to authorization, including CAVV and ECI in the auth request
Typical conversion: no cardholder friction. Typical risk data: device fingerprint, transaction history, shipping/billing match, behavioral signals.
Challenge

Challenge Flow

Cardholder interaction required (OTP, biometric)

  1. AReq sent to DS, routed to ACS
  2. ACS determines challenge required — sends ARes with transStatus=C and acsChallengeMandated=Y
  3. ARes includes ACS URL for the challenge window
  4. 3DSS opens an iframe (browser) or triggers SDK challenge (app) at the ACS URL
  5. Cardholder completes challenge: enters OTP from SMS, uses biometric, or answers knowledge question
  6. ACS sends CReq (Challenge Request) and receives CRes (Challenge Response) from cardholder
  7. ACS sends RReq (Results Request) to 3DSS with final transStatus (Y or N)
  8. 3DSS sends RRes acknowledgment, then proceeds to authorization
Decoupled

Decoupled Authentication Flow

Asynchronous out-of-band authentication

  1. AReq sent with deviceChannel=03 (decoupled) and decoupledReqIndicator=Y
  2. ACS determines decoupled flow — ARes with transStatus=D
  3. ACS sends a push notification to the cardholder's banking app on their registered device
  4. Cardholder opens their banking app and authenticates (PIN, biometric, pattern)
  5. Authentication is entirely out-of-band — occurs separately from the browser session
  6. ACS sends RReq asynchronously (up to 1 hour maximum) with final outcome
  7. Merchant may poll for result or use webhook — timeout results in U (unable to authenticate)
Use case: high-value transactions, suspicious device, or when the cardholder's phone number is not available for OTP. Provides strong authentication without interrupting the merchant checkout flow.