Mobile SDK Challenge Screens
Overview of features
The NDM Simulator is able to provide different challenge flow scenarios. Currently, the BRW (browser) channel only supports the OTP screen, while the APP (mobile) channel supports the following types of ACS UI Template screens: OTP, OOB, Single select and Multi select (see below for more details).
Furthermore, there is a possibility to choose between two ACS Interface Types, Native and HTML.
The simulated scenarios can be tied to credit card numbers belonging to different schemes. For the most common schemes like Visa, American Express and Mastercard, a designated scheme logo is shown in the upper right corner. Given a scheme different from the three above mentioned ones, the Mastercard logo is shown by default.
Finally, the NDM Simulator supports challenge flows for both 2.1 and 2.2 protocol versions. In line with the EMVCo specifications, the whitelisting feature is available only for protocol version 2.2 and is described in more detail in section Merchant Whitelisting.
ACS Interface Types
There are two possible interface types - Native and HTML.
The Native type renders the challenge screen based on the mobile device preferences and can look different depending on different operating systems and UI Settings done by the mobile application integrating the 3DS SDK. Below is an example of the OTP Native challenge screen for the American Express scheme, as shown on the iOS device.
For more example screens, please check the challenge template screens section.
The HTML interface type uses a prepared HTML template with defined style and is therefore shown in an (approximately) identical fashion across different mobile devices. Below is an example of the OTP HTML challenge screen for the Visa scheme, as shown on the iOS device.
For more example screens, please check the challenge template screens section.
ACS UI Template Screens
The following challenge screen examples are shown only using the Mastercard scheme. The templates for the other schemes are same, the only difference is the scheme logo in the upper right corner.
Based on challenge responses for each of the four templates, different simulated replies can be configured in the property files. For more information please check Challenge Response Configuration.
OTP (One-Time-Password) Challenge Screen
The OTP screen requests the user to enter a valid code in order to complete the challenge. If a correct code is entered, the challenge is completed successfully, otherwise the challenge is unsuccessful, with the transactionStatus and other fields as configured in the simulated-challenge-responses.properties file.
The user has the possibility to click the "Resend code" button, which simulates receiving the new code in the background. In this case, the NDM Simulator will present the same challenge screen for entering the code once again.
The example OTP screens for both Native and HTML interface are shown below.
OOB (Out-Of-Band) Challenge Screen
The OOB screen simulates a real-life scenario in which the users are instructed to approve the transaction using their own bank app, i.e. an external (out-of-band) application is used to complete the challenge flow. Given the restrictions of integrating external components, the NDM Simulator here offers only the "Continue" function, acknowledging that the approval has happened in the background external app. Hence, the transactions are by default resulting in a successfully performed challenge.
The example OOB screens for both Native and HTML interface are shown below.
Single Select Challenge Screen
The Single Select screen presents the user with a personal question which should be answered in order to complete the challenge. The question has only one possible correct answer which leads to a successful challenge. In case a wrong answer is chosen, the transaction will fail with the preconfigured transactionStatus and other fields, as specified in the simulated-challenge-responses.properties file.
The example Single Select screens for both Native and HTML interface are shown below.
Multi Select Challenge Screen
The Multi Select screen presents the user with a personal question which should be answered in order to complete the challenge. Since it's a multiple choice question, the correct answer could potentially consist of several options from the list. Choosing the right answer leads to a successful challenge. In case a wrong answer is chosen, the transaction will fail with the preconfigured transactionStatus and other fields, as specified in the simulated-challenge-responses.properties file.
The example Multi Select screens for both Native and HTML interface are shown below.
Challenge Response Configuration
In order to configure the Authentication Response and Results Request fields for specific card numbers, the cardholder-numbers-simulated-message-types.properties file in the $NDM_SIMULATOR_HOME/conf should be used.
Given the APP device channel, the following Authentication Response values define the four different challenge screens:
- APPLICATION_CHALLENGE (by default using the OTP screen)
- APPLICATION_CHALLENGE_OOB
- APPLICATION_CHALLENGE_SINGLE
- APPLICATION_CHALLENGE_MULTI
For more details, please check ARes and RReq Configuration, Card Range Data Configuration and Challenge Flow Configuration.
An example configuration is listed below:
Simulating the challenge responses can be configured taking into account the challenge screen type.
An example configuration file exists in the $NDM_SIMULATOR_HOME/conf under the name simulated-challenge-responses.properties and it is also listed below:
As can be seen from the above configuration, the OTP code "1234" will lead to a successful challenge, whereas e.g. "2222" will result in transaction status "Rejected".
For the Single Select configuration, the right answer to the challenge would be "Paris", while choosing "Lyon" would cause the transaction status to be "Unavailable".
Finally, in the Multi Select scenario, the right combination that warrants a successful challenge is choosing both "Paris" and "Lyon".
For all of these three scenarios, if a provided answer is not existing as a configured option in the properties (e.g. "7777" for OTP or "Nice" for Multi select), the default response returned is a failed transaction with transactionStatus=N, transStatusReason=01, eci=01, and no authenticationValue provided.
Merchant Whitelisting
Whitelisting of merchants is a feature available only for protocol version 2.2. For all challenge screen (OTP, OOB, Single and Multi select) and Interface Types (Native, HTML), a checkbox will be shown asking whether a particular merchant should be added to the whitelist. This checkbox is present only in case a transaction was initiated using 2.2 protocol version. The whitelisting is done by coupling the card number and merchant name into a unique key.
Once a merchant is whitelisted for a particular card, the subsequent transaction for the same card and merchant combination will result in a frictionless transaction. The challenge screen will no longer be presented, since the merchant has been whitelisted. However, if a different card is used for the same whitelisted merchant the transaction will enter the challenge flow.
In order to clear the whitelisting cache, the frontend of the NDM Simulator should be opened, and the desired cache cleaned in the "Merchant Whitelist" section. The cache can be cleaned for individual merchants, as well as for all at the same time.
