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.
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:
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.
There is a spinner on the processing page while the 3DS2 authentication is in progress:
After the 3DS2 authentication is finished the result will be shown:
Show results in separate pages will open a new page to show the results.
The above demonstrates a frictionless authentication. If the authentication requires a cardholder challenge, this will be shown after the first spinner processing page.
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,
Additional Risk and
Basic Info tab has three sections,
Required Field, and
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.
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
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.
Additional Field, you can fill in additional information such as the Purchase amount, Purchase currency, Expiry date, etc.
Cardholder tab, you can fill in cardholder information, including the Card holder name, Email, phone numbers and address details.
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.
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
- 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
- No Reason Sent: simulates a scenario where the 3DS Requestor does not initiate the challenge, but also does not call the
challengeStatusendpoint, 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.
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,
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.
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.
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.
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.
Or, you can fill in an invalid parameter in
BRW test page (e.g.
Merchant ID), and it will return an error information.
The no-script test page can be accessed by selecting the
Check the front-end implementations for a no-script environment in the following pages:
To support a no-script environment, the following endpoints are implemented in the back-end: