EMV 3-D Secure (3DS) - Payment Authentication Protocol
Authentication flow requirements (chapter 3: app-based, out-of-band, browser-based) – EMV 3-D Secure (3DS) - Payment Authentication Protocol

EMV 3-D Secure (3DS) - Payment Authentication Protocol 3.1.S7: 3.1.S7 App: ACS decides the transaction status and prepares any challenge (Step 7)

The ACS validates the AReq, checks device support (IReq 10 if not), generates the ACS Transaction ID, determines whether authentication is available for the account, should take the 3DS Requestor Challenge Indicator into account in deciding, and evaluates the AReq to set the status: authenticated (Y), challenge required (C), not authenticated (N), attempted with proof (A), unable (U) or rejected (R); for Y or A in a payment authentication it generates the ECI and Authentication Value as the DS defines, and for C it selects a challenge method the SDK supports from the device channel and rendering options, sets the ACS rendering type, sets up the ACS-to-SDK secure channel and stores the SDK, 3DS Server and DS transaction IDs; it then formats and sends the ARes to the DS. The decisioning process itself is outside the specification.

Maintained by Gerard BlokdykControl text last updated

Other controls in Authentication flow requirements (chapter 3: app-based, out-of-band, browser-based) – EMV 3-D Secure (3DS) - Payment Authentication Protocol

Query this from an agent

The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.