Skip to content

Sample code features

In this section, we show all the features of the 3DS Requestor Demo project. You can access the 3DS Requestor demo by:

Shown below is the index page of the 3DS Requestor site. There are two parts, Online shop and Test pages. The online shop can be accessed by selecting the Launch button (1.a) or selecting the Online shop button (1.b) at the top left. Each test page can be accessed by selecting the associated buttons (2.a) or selecting the Test pages dropdown (2.b) at the top left. Additionally, at the top right there is a API Document link (3) which will direct you to the ActiveServer Authentication API Reference document.

index site

Online Shop

The online shop is a demo merchant checkout page that gives a merchant side view of how to integrate 3DS2 into an eCommerce site. For the implementation of the integration, follow the Integration Guide. To make a test transaction:

Add items to the cart in the shop page and select the Continue to Checkout button to move to the checkout page:

purchase page

Default payment and billing information is pre-filled, including a card number, which can be used to complete a frictionless transaction. Select the Checkout button to trigger the 3DS2 authentication process:


You can select the API version to perform the 3DS2 authentication process by clicking the arrow at the right of the Checkout button.

checkout page

There is a spinner on the processing page while the 3DS2 authentication is in progress:

processing page

After the 3DS2 authentication is finished the result will be shown:

result page

Selecting the Show results in separate pages will open a new page to show the results.

Challenge flow

The above demonstrates a frictionless authentication. If the authentication requires a cardholder challenge, this will be shown after the first spinner processing page.

Test Pages

The test pages allow you to test the Browser-based Authentication (BRW), 3DS Requestor Initiated (3RI), App, and Enrol channels with all the parameters defined in the API document.

BRW Test Page

The BRW test page has four tabs, Basic Info, Cardholder, Additional Risk and Test Options.

Basic Info

brw cards

The Basic Info tab has three sections, Channel, Required Field, and Additional Field.

In Channel, you can check the 3DS Server URL and the Requestor URL that have been loaded into the application. You can also select which Directory Server is used for the test and choose the EMV Message Version.

In Required Field, you need to fill in the Account Number, Merchant ID, Authentication Indicator, and Message Category. The Merchant ID must match the one from the merchant profile you are using, which also corresponds to the client certificate being used.

Using GPayments TestLabs scenarios

For the Account Number, you can fill in an account number manually, or you can choose from our predefined scenarios. For example, you can choose Visa with Frictionless authentication and the the account number 4100000000000100 will automatically be filled in the Account Number field.

The demo 3DS Requestor allows you to trigger various 3DS2 authentication scenarios by specifying a card number before the authentication. To check the card list for different authentication scenarios, refer to the TestLabs guide for details.

In Additional Field, you can fill in additional information such as the Purchase amount, Purchase currency, Expiry date, etc.


On the Cardholder tab, you can fill in cardholder information, including the Card holder name, Email, phone numbers and address details.

brw cardholder

Additional Risk

On the Additional Risk tab, you can fill in other additional risk information, such as the account information, the requestor authentication information, and the merchant risk indicator.

Merchant risk information

This information is optional to provide. However, it is very beneficial for the merchant to provide this information if it is available, as it will assist the issuers ACS with risk-based authentication, and potentially lead to higher rates of frictionless authentications.

brw add risk

Test Options

On the Test Options tab, firstly, you can choose which API version to use to perform the 3DS authentication process.

Secondly, you can choose to cancel a challenge if the ACS requests one for the transaction by selecting the Cancel Challenge checkbox. When cancelling the challenge, the 3ds-web-adapter will not execute the CReq callback page in the iframe. Optionally the Cancel Reason can then be specified using the challengeStatus endpoint to let ActiveServer know why the challenge is being cancelled:

  • CReq Not Sent: indicates that the challenge request was not initiated due to the 3DS Requestor choosing to opt out of the challenge. Will send a status of CReqNotSent to the challengeStatus endpoint.
  • Auth Result Not Delivered: indicates that the challenge request was not able to be delivered to the 3DS Requestor due to a technical error, such as ActiveServer not responding when the 3DS Requestor executes an authentication request. Will send a status of AuthResultNotDelivered to the challengeStatus endpoint.
  • No Reason Sent: simulates a scenario where the 3DS Requestor does not initiate the challenge, but also does not call the challengeStatus endpoint, meaning no reason will be sent to ActiveServer.

Lastly, you can decide the challenge window size by selecting the Challenge Window Size options. This will be included in the authentication request to the ACS, requesting them to display the challenge page to the cardholder in a specific size which is conducive to the merchants checkout website.

brw add risk

3RI Test Page

The 3RI test page initiates an authentication using the 3RI channel. Similar to the BRW test page, the 3RI test page has three tabs, Basic Info, Cardholder, and Additional Risk. One difference is that there is a 3RI Indicator parameter in the Required Field section and there are also less parameters in the Additional Field due to the nature of 3RI.

3ri basic

App Test Page

The App test page initiates an authentication using the App channel. The App test page uses a hardcoded mock AReq for App channel authentication. This data is only for test or demo purposes. For a production authentication, App authentication requests must be initiated by an integrated 3DS SDK.

app auth

Enrol Test Page

The enrol test page initiates an /enrol check with ActiveServer, which is used to see if a card is in a card range that supports 3DS2. Only an Account Number and a Merchant ID are required for the enrol test.

enrol basic

Test Results

After selecting the Test button on one of the test pages, you will be directed to process.html. All the 3DS2 processes will be handled by a process.html page and there will be a spinner while the 3DS2 process is running. When the 3DS2 process is done, the results will be displayed on the same page.

For example, if you select BRW test page then select Test BRW button with pre-filled information, it will get a successful response.

result success

Or, you can fill in an invalid parameter in BRW test page (e.g. 000 for Merchant ID), and it will return an error information.

result error

No-script Test

The demo requestor has demo code for a no-script environment. To test, disable Javascript in your browser then go to the index page.

noscript index

The no-script test page can be accessed by selecting the No-Script test button. Follow the instructions on this page to do a demo transaction with Javascript disabled.

noscript page

Check the front-end implementations for a no-script environment in the following pages:

  • no_script.html
  • no_script_process.html
  • no_script_poll_result.html
  • no_script_results.html

To support a no-script environment, the following endpoints are implemented in the back-end:

  • /noscript and /3ds-notify/noscript endpoints in MainController
  • /v2/auth/init/noscript, /v2/auth/noscript, /v2/auth/result/noscript/poll, and /v2/auth/brw/result/noscript endpoints in AuthControllerV2