Skip to content

Authentication processes

3DS Requestor performs three processes during an authentication:

  1. Initialise Authentication - the 3DS Requestor sends a request to ActiveServer to initialise the authentication, preparing ActiveServer for the the authentication.

  2. Execute Authentication - ActiveServer executes the authentication. There are two main authentication flows in 3DS2, frictionless flow and challenge flow, which are described in the Process Flows section.

  3. Get Authentication Result - the authentication result is returned to the 3DS Requestor.

Process 1: Initialise Authentication

In this step the 3DS web adapter collects the information that the cardholder has entered, at the front end, and passes it to the 3DS Requestor, at the back end. The 3DS Requestor then passes all the information required by 3DS2 to ActiveServer to start the authentication.

Using our example in the integration overview, when the customer selects Continue to checkout, the 3DS web adapter sends an initialise authentication message to the 3DS Requestor. The initialise authentication message contains a unique transaction ID (transId) plus the cardholder's information. The 3DS Requestor receives the initialise authentication message, formats it according to the 3DS Server API, and sends it to the 3DS Server by calling:/api/v1/auth/brw/init/.

Note

  • /auth indicates the request is an authentication request.
  • /brw indicates the request is from a browser. The 3DS Server also accepts requests from mobile applications via /app.
  • /init indicates the request is to initialise the authentication.

When ActiveServer receives the /api/v1/auth/brw/init/ message, it will collect the browser information and be ready for the authentication process.

Note

The 3DS Server and the ACS automatically collect the browser information, and this process is NOT part of the 3DS Requestor.

Process 2: Execute Authentication

Once the browser information collection is complete, authentication can be executed by the merchant by calling /api/v1/auth/brw. This will cause ActiveServer to initiate the 3DS2 messaging process. There are two main authentication flows in 3DS2, frictionless flow and challenge flow.

  • Frictionless flow - initiates a 3D Secure authentication flow, which consists of the AReq/ARes authentication messages. If the ACS determines the transaction is low risk, based on the information provided, authentication is approved immediately.
  • Challenge flow - if the ACS determines that the transaction is high risk, above certain thresholds, or subject to regulatory mandates, which requires further Cardholder interaction, frictionless flow, transitions into the challenge flow. In addition to the AReq and ARes messages that comprise frictionless flow, the challenge flow consists of the CReq/CRes challenge messages and the RReq/RRes result messages.

This diagram shows the challenge flow: challenge flow

The dotted lines indicate messaging outside the scope of the 3DS2 protocol, including communication between the Client/3DS Requestor and Authorisation

Process 3: Get Authentication Result

Once the 3DS2 process is complete, the merchant calls /api/v1/auth/brw/result to get the authentication result. The authentication result (from the ARes or RRes depending on challenge status) contains information such as as the ECI, Authentication Value (e.g. CAVV) and final Transaction Status.

What's next?

Select Next in the footer below to learn more about the Authentication sequence.