← 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.

3DS Architecture

EMV 3DS defines three server-side components — the 3DS Server, Directory Server, and Access Control Server — that together form the authentication infrastructure across merchant, scheme, and issuer domains.

Merchant / 3DSS
Acquirer Domain
→
Directory Server
Scheme Domain
→
ACS
Issuer Domain
1

3DS Server (3DSS)

Merchant-side component. Responsible for:

  • Collecting browser/device fingerprinting data (user agent, screen size, color depth, timezone, Java enabled)
  • Compiling the Authentication Request (AReq) with 100+ data fields
  • Sending AReq to the Directory Server and receiving ARes
  • Managing the challenge window if ARes indicates challenge required
  • Receiving the final RReq (Results Request) with authentication outcome
2

Directory Server (DS)

Scheme-operated routing hub. Responsible for:

  • Validating card ranges — determines which ACS handles this card number
  • Routing the AReq to the correct ACS based on BIN
  • Managing 3DS protocol version negotiation
  • Validating digital signatures on AReq/ARes to prevent tampering
  • Does NOT store authentication data — pure routing function

Operators: Visa Verified / VPT, Mastercard Identity Check, Amex SafeKey, Discover ProtectBuy

3

Access Control Server (ACS)

Issuer-operated authentication engine. Responsible for:

  • Receiving AReq and applying the issuer's risk-scoring model
  • Deciding frictionless (Y/A) or challenge (C/D) outcome
  • Rendering the challenge UI (OTP, biometric, knowledge-based)
  • Generating the CAVV / authentication value on successful authentication
  • Sending the final RReq (Results Request) to the 3DSS after challenge

🧩 Check yourself

Can you authenticate and authorize an online payment in the right order?

Expert · shortest route 12 hops · hints included
Put it into practice

Next steps

Tool3DS2 Message Builder & DecoderSketch EMV 3DS (3DS2) AReqs and decode AReq, ARes, CReq/CRes (incl. base64url creq/cres), RReq and Erro messages — transStatus, ECI, reason and error codes explained field by field.Open the tool ToolCAVV CalculatorInspect 3-D Secure CAVV / AAV values: base64 ↔ hex, type by length and leading byte (Visa 20-byte CAVV, Mastercard 21-byte SPA2 AAV) and the ECI values that go with them. Field layouts and scheme algorithms are not public, so no fields are decoded and no CAVV/AAV is generated (the MAC tab is an illustrative TDES CBC-MAC).Open the tool ToolResponse Code ReferenceSearchable ISO 8583 DE 39 response codes with Visa and Mastercard meanings — Visa decline categories and reattempt limits, plus Mastercard Merchant Advice Codes.Open the tool Flow3-D Secure frictionless and challenge flowsSee the animated message flow, step by step, between every party involved.Watch the flow
Keep reading

Related articles

Card RailsPayment TokenizationFPAN→DPAN lifecycle, VTS vs MDES, TAVV cryptogramsRead article Open BankingOpen Banking & PSD2AISP/PISP roles, consent & SCA flows, FAPI security, UK / Berlin Group / STET, PSD3 & PSRRead article IdentityEUDI Wallet & PaymentseIDAS 2.0 deadlines, the SD-JWT VC / mdoc / OID4VP stack, wallet-based PSD2 SCARead article Card RailsISO 8583 ProtocolMessage structure, bitmap mechanics, 128 data elements, network variationsRead article