Understand the EMVCo 3DS2 server-side message flow: AReq, ARes, CReq, and CRes message exchange between 3DS Server, DS, and ACS

Steps

1. The 3DS Server (merchant-side component) sends an Authentication Request (AReq) message to the Directory Server (DS), which forwards it to the issuer's Access Control Server (ACS)
2. The ACS evaluates risk and returns an Authentication Response (ARes) to the DS, which relays it to the 3DS Server; if the ARes transStatus is 'Y' or 'A', frictionless authentication is complete
3. If the ARes transStatus is 'C' (challenge required), the 3DS Server must initiate a challenge by presenting the acsURL and the CReq (Challenge Request) payload to the cardholder's browser or app
4. The cardholder interacts with the ACS challenge UI; upon completion the ACS posts a CRes (Challenge Response) back to the 3DS Server's notification URL
5. Parse the CRes to extract the transStatus; 'Y' means the cardholder authenticated successfully and the CAVV/AAV and ECI values are now available for the authorization message
6. Forward the CAVV/ECI from the final ARes or CRes into the card authorization request to the acquirer to claim liability shift