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:
- Downloading and running the 3DS Requestor demo code here, or
- Using our online TestLabs Requestor
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.
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:
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:
Note
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:
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) 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¶
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 Message Category is used for the test, either pa
or npa
.
In Required Field
, you need to fill in the Account Number, Merchant ID and Authentication Indicator. 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.
Cardholder¶
On the Cardholder
tab, you can fill in cardholder information, including the Card holder name, Email, phone numbers and address details.
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.
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 thechallengeStatus
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 thechallengeStatus
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.
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. Lastly, you are not able to choose a Message Category
in 3RI tests because in version 2.1.0 of 3DS2 the 3RI channel can only used for Non-payment authentication.
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.
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.
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.