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.

If any of the steps are part of the 3DS Requestor environment process, they will be marked as ←3DS Requestor process for your reference, as these steps are provided as demo code and may require customisation to fit your requirements.

Note

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)

3ds2diagram

  1. Send information for initialising authentication ←3DS Requestor process
    • 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 Requestor process
    • 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}) ←3DS Requestor process
    • 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 ActiveServer to callback to this URL to notify the end of the browser information collection.
  4. Return threeDSServerCallbackUrl
  5. Return threeDSServerCallbackUrl ←3DS Requestor process
    • The 3DS Requestor returns the threeDSServerCallbackUrl back to the 3DS web adapter.
  6. Setup callback iframe ←3DS Requestor process
    • Insert a hidden iframe, with src set to threeDSServerCallbackUrl. This will allow ActiveServer to connect to the 3DS Requestor. ActiveServer will callback to this iframe.
  7. Collect browser information
    • ActiveServer 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 ←3DS Requestor process
    • 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 ←3DS Requestor process
    • callbackFn can be either _on3DSMethodSkipped() or _on3DSMethodFinished(), both of which will end up calling doAuth(). 3DS-web-adapter 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) ←3DS Requestor process
    • 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 ActiveServer via the Directory Server to an ACS. An Authentication Response (ARes) containing the authentication results is sent from the ACS to ActiveServer.
  12. Return result of authentication
    • /brw returns a tranStatus to the 3DS Requestor.
  13. Return result of authentication ←3DS Requestor process
    • Return the result of authentication back to the web adaptor.

Info

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) ←3DS Requestor process

  • 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) ←3DS Requestor process

  • 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) ←3DS Requestor process

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

17(F). Show result on screen ←3DS Requestor process

  • The result screen is rendered using the authentication result.

Challenge flow specific

14(C). Setup iframe (if challenge) ←3DS Requestor process

  • 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 ActiveServer. ActiveServer 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 ←3DS Requestor process

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

20(C). Request for authentication result ←3DS Requestor process

  • 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) ←3DS Requestor process

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

22(C). Show result on screen ←3DS Requestor process

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