Customer Testing Platform

mSIGNIA provides a Customer Testing platform to help customers integrate the uSDKs. It is a fully-featured 3DS v.2 infrastructure that simulates all the participants of the 3DS flow.

The platform is used to execute most of the 2.1 and 2.2 3DS flows.

Architecture

The platform is comprised of multiple participants depicted on the diagram below along with a number attached to each of them:

Open

Participants

The participants of the Customer Testing platform can be split into two logical groups - merchant components and 3DS infrastructure components. Merchant components are grey colored in the diagram above while the 3DS infrastructure components are white.

1. iOS sample application (6.4 docs)

2. Android sample application (6.4 docs)

3. Browser sample application (6.4 docs)

4. Merchant Backend Sample application - (docs)

5. uMPI 3.0 plugin for Merchant Backed - (docs)

6. Transaction Details - a web application where 3DS transaction details can be reviewed (https://transaction-details.ct.msignia.com/transactions)

7. 3DS Server - a certified 3DS server implementation deployed

8. DS Servers - two instances of a DS server

9. ACS Server - an implementation of an ACS server

10. Scenarios repository - a database that holds the scenarios for the components to perform based on acctNumber used in a transaction.

The flow

Preparatory

The customer obtains a uSDK and bundles it into one of the sample applications provided - iOS, Android, or Browser. Afterwards, the customer launches the Merchant Backend Sample app pointing it to the 3DS Server.

Execute a transaction

Once the preparatory is done, the customer launches the sample app and performs a transaction. The request comes from the mobile or browser app to the sample backend, 3DS Server, DS and ACS. The ACS then responds and the data gets back to the sample application.

The data received back by the application is a 3DS message that has a field called threeDSServerTransIDThe threeDSServerTransID is used to look up the transaction details in the next step.

Reviewing transaction details

Once threeDSServerTransID is known, the customer launches a web browser and navigates to the Transaction Details application (callout 5 on the diagram above), pastes the transaction identifier, and reviews the details.

Scenarios

Under the hood, the Customer Testing Platform uses the Scenarios Repository. The repository stores account numbers associated with the corresponding 3DS scenario to perform.

It is actually a table with the first column representing an account number, while the rest of the columns describe the scenario the Customer Testing Platform would execute if a transaction is executed for the account number.

Let’s review an example:

Open

So above, sending a transaction with the 3400200000001000010 account number to the Customer Testing platform will make the ACS return transStatus=Y given it is set so in the Final TransStatus column.

In the example above it is important to take the other properties into account - it has to be a mobile app transaction (given there's APP in the Device Channel column), it has to be a 2.1 transaction version (because of the value in the Spec Version column) and a payment authentication transaction (because of the PA in the Message Category column).

Similarly, the Scenarios repository configures more complex scenarios - challenge flows, decoupled authentication, and others.

The scenarios repository can be visited online - the Scenarios Repository.

3DS components

The 3DS components deployed as the Customer Testing Platform support 2.1 and 2.2 3DS specifications. The following subsections document each of the components.

Transaction Details App

This is a single page web application that allows seeing 3DS transaction details. To get started the user pastes an AReq.threeDSServerTransID value in the search box at the top of the page and presses Enter.

To access the application, open https://transaction-details.ct.msignia.com in the browser.

3DS Server

A fully-featured and certified 3DS Server is deployed to the Customer Testing Platform:

• Reference Number: 3DSSERVREF00000001

• Auth URL: https://3ds-server.ct.msignia.com/api/v2/authenticate

• Supported Versions URL: https://3ds-server.ct.msignia.com/api/v2/supportedVersions

DS Servers

The platform has two DS servers available. The two are actually the same but they have different reference numbers and use different type of public keys to decrypt deviceInfo with - RSA and EC. Having two DS servers in the platforms let’s the customers to exercise dual-branded cards scenarios.

RSA DS Server

This is a mock DS server that complies with 2.1 and 2.2 specifications.

• Reference Number: MSIGNIA_MOCK_DS_RSA

• Preparation URL: https://ds-server-rsa.ct.msignia.com/api/v2/process

• Auth URL: https://ds-server-rsa.ct.msignia.com/api/v2/process

This is the RSA key used by the 3DS SDK to encrypt device information:

The same RSA key but JWK encoded:

EC DS Server

This is a mock DS server that complies with 2.1 and 2.2 specifications.

• Reference Number: MSIGNIA_MOCK_DS_EC

• Preparation URL: https://ds-server-ec.ct.msignia.com/api/v2/process

• Auth URL: https://ds-server-ec.ct.msignia.com/api/v2/process

This is the EC key used by the 3DS SDK to encrypt device information:

DS CA Certificate

The certificate is used by the mock ACS to sign acsVersionContent data:

ACS Server

This is a mock ACS server that complies with 2.1 and 2.2 specifications.

• Reference Number: 00001ACS00001

• Auth URL: https://acs-server.ct.msignia.com/api/v1/auth

• 3DS Method URL: https://acs-server.ct.msignia.com/api/v1/3ds_method

Limitations / Known Issues

Running DECOUPLED flows

In order to trigger DECOUPLED AUTH flow, the merchant backend sample application needs to be updated/recompiled to include AReq.threeDSRequestorDecReqInd to be Y.

The Customer Testing platform does not set this data element.

Running 3RI flows

To run a 3RI transaction, the AReq.deviceChannel should be set to 03 in the sample merchant backend. The sample backend needs to be recompiled and restarted.

The Customer Testing platform sets this data element to be 01(APP) when request comes from the mobile sample app and 02(BRW) when it comes from the browser.

Running NPA flows

To run a Non Payment Authentication flow (NPA) the merchant backend sample application needs to be updated/recompiled to include AReq.messageCategory to be 02.

The Customer Testing platform sets this data element to be 01(PA).