Skip to content

Authentication sequence

The sequence diagram below breaks down the process of a 3DS2 authentication, step by step, explicitly focusing on how the 3DS Requestor functions inside the 3DS2 flow, using GPayments' APIs.


Implementation of the 3DS web adapter at the front end, and the 3DS Requestor at the back end, is required to integrate ActiveServer.

  • Process 1: Initialise Authentication
    • Step 1 to Step 7
  • Process 2: Execute Authentication
    • Frictionless flow - Step 8 to Step 13, and Step 14(F)
    • Challenge flow - Step 8 to Step 13, and Step 14(C) to Step 19(C)
  • Process 3: Get Authentication Result
    • Frictionless flow - Step 15(F) to Step 17(F)
    • Challenge flow - Step 20(C) to Step 22(C)


  1. Send information for initialising authentication
    • Information about the cardholder obtained from the checkout page, such as the card number and the cardholder name, is sent to the 3DS web adapter. This is a simple JavaScript simulating how the front end system of 3DS Requestor works.
  2. Initialise authentication
    • 3DS web adapter makes a POST request to the 3DS Requestor with information collected from the checkout page and requests the 3DS Requestor to initialise authentication.
  3. Initialise authentication (/brw/init/{messageCategory})
    • The 3DS Requestor obtains the information from the front end and makes a POST API call to /brw/init/{messageCategory}to initialise authentication.
    • An important field sent here is the eventCallbackUrl, which will be required to start Step 8 to allow the 3DS Server to callback to this URL to notify the end of the browser information collection.
  4. Return threeDSServerCallbackUrl
  5. Return threeDSServerCallbackUrl
    • The 3DS Requestor returns the threeDSServerCallbackUrl back to the 3DS web adapter.
  6. Setup callback iframe
    • Insert a hidden iframe, with src set to threeDSServerCallbackUrl. This will allow the 3DS Server to connect to the 3DS Requestor. The 3DS Server will callback to this iframe.
  7. Collect browser information
    • The 3DS Server collects the browser information via the iframe and then facilitates the 3DS method data collecting for the ACS. The ACS then collects the 3DS method data via the prepared iframe.
  8. Call callback function
    • During authentication initialisation, the 3DS Requestor sends the eventCallBackUrl so that the ACS can notify the 3DS Requestor when the 3DS method is finished or skipped. This is done through the iframe setup in Step. 7.
    • Once the 3DS Requestor receives a notification, it will pass required parameters including callbackFn and render notify-3ds-events.html to the iframe. When notify_3ds_events.html is rendered it will simply call the callbackFn defined in the 3ds-web-adapter.
  9. Execute authentication
    • callbackFn can be either _on3DSMethodSkipped() or _on3DSMethodFinished(), both of which will end up calling doAuth(). 3DS-web-adaptor will call doAuth(), which will ask the 3DS Requestor to execute the authentication.
    • _on3DSMethodSkipped means that ACS did not perform browser information collection for some reason. Therefore, if you want to perform 3DS authentication when browser information is collected, you can choose to terminate the transaction here.
  10. Execute authentication (/brw)
    • The 3DS Requestor will make a call to /brw, which will initiate the authentication processes.
  11. AReq/ARes
    • An Authentication Request (AReq) is sent from the 3DS Server via the Directory Server to an ACS. An Authentication Response (ARes) containing the authentication results is sent from the ACS to the 3DS Server.
  12. Return result of authentication
    • /brw returns a tranStatus to the 3DS Requestor.
  13. Return result of authentication
    • Return the result of authentication back to the web adaptor.


If the transStatus returned is "Y" go to Step 14(F), if "C" go to Step 14(C).

Frictionless flow specific

14(F). Show Result (if frictionless)

  • If the the authentication result has a transStatus of "Y", authSuccess() is called, which redirects the page to /auth/result?transId.

15(F). Request for authentication result (if separate result page is required)

  • The browser notifies the 3DS Requestor with the transId, and the the transaction result is available for request.

16(F). Request for authentication result (/brw/result)

  • The 3DS Requestor will ask for a result receipt from the 3DS Server by calling /brw/result.

17(F). Show result on screen

  • The result screen is rendered using the authentication result.

Challenge flow specific

14(C). Setup iframe (if challenge)

  • If the authentication result has a transStatus of "C", startChallenge() is called, which will insert an iframe for challenge.

15(C). Exchange HTML

  • The ACS will embed the challenge screen inside the iframe, then the cardholder completes the authentication challenge.

16(C). Determine challenge outcome

  • The ACS determines if the challenge performed is successful or not.

17(C). RReq/RRes

  • The ACS sends a Result Request (RReq) containing the authentication results via the Directory Server to the 3DS Server. The 3DS Server will then acknowledge its receipt with a Result Response (RRes).

18(C). Challenge Response (final CRes)

  • The ACS sends the final Challenge Response (CRes) to the 3DS Requestor.

19(C). Close 3DS Challenge and show the result screen

  • Since the challenge is finished, the 3DS Requestor redirects the page to /auth/result?transId.

20(C). Request for authentication result

  • The browser notifies the 3DS Requestor with the transId, and the the transaction result is available for request.

21(C). Request for authentication result (/brw/result)

  • The 3DS Requestor asks for result receipt from /brw/result, same as Step 16(F).

22(C). Show result on screen

  • The result screen is rendered using the authentication result on the browser.

What's next?

Select Next in the footer below to access the Integration guide and go through the process of integrating a merchant checkout process with ActiveServer.