OTP + Knowledge Factor Authentication Flow

📘

Applicability

This feature is applicable only if your program is based in EEA and UK, and needs to comply with PSD2 Strong Customer Authentication mandates.

PSD2 Strong Customer Authentication mandates the authentication to involve 2 out of 3 factors of authentication:

1. What you have (Possession factor)
2. What you know (Knowledge factor)
3. Who you are (Inherence factor)

The OTP (SMS) + Knowledge Factor based 3DS authentication fulfills the mandate as follows:

• OTP (SMS) delivered to the cardholder's mobile can be considered a valid possession factor
• The 6-digit knowledge factor, which the cardholder must have securely created and stored in his/her profile, can be considered a valid knowledge factor.

About the 6-digit knowledge factor

Nium expects the BaaS clients (that is interested in cards issuing) to collect and store a 6-digit code (knowledge factor) from the account holders. Clients can collect this 6-digit code at an appropriate stage in the customer lifecycle. Clients can clearly indicate to the account holders about when this code will be required to be used, and hence when the time comes (i.e., when cardholders are doing online transaction) the cardholders would remember to use the code.

Please take note that this additional factor of authentication, besides OTP, is required when PSD2 SCA applies. Typically this is relevant when the cards issuing is taking place in EEA/UK. When PSD2 SCA is not applicable, then with regards to 3DS authentication, Nium will use the standard OTP based 3DS authentication. So if you are not issuing out of UK/EEA, you will not need to support this model. Please consult your program representative for additional details.

One Leg Out (OLO)

If the issuer and acquirer are not within EEA / UK, then we may apply OLO driven SCA exemption and when that happens the 3DS authentication can be performed only by using the Standard OTP based authentication to provide simplified user experience.

OTP (SMS) + Knowledge Factor authentication

Following diagram captures the high level interaction that takes place among key parties when a cardholder uses his/her card online - say for example to do shopping at an e-commerce merchant. Once the authentication is successful, the merchant end (acquirer, acquiring processor, PSP - payment gateway) will receive the authentication result (CAVV/UCAF). It is expected that the merchant end will include the authentication result when submitting the transaction authorization to the network as an authentication proof.

📘

Important note

This flow requires participation from the Nium's Client (the one that is the owner of the program interacting with the cardholders). The Client will have to implement a certain API and expose it via a certain accessible URL for Nium.

When a cardholder attempts to make an online payment to a merchant supporting 3DS authentication, the following process occurs:

1. Cardholder performs an online transaction (shopping at ecommerce site, for instance).
2. The merchant initiates an authentication request by sending the request to the card network (Visa, MasterCard, etc.,).
3. The card network routes the authentication request to the Nium platform.
4. The Nium platform prompts the cardholder, via an embedded iframe within the merchant’s checkout experience, to enter a one-time passcode that Nium sends via SMS.
5. The Nium platform verifies the OTP and determines that the cardholder needs to be further challenged for knowledge factor based authentication.
6. The Nium platform prompts the cardholder to enter the 6-digit knowledge factor (code).
7. The cardholder enters the 6-digit knowledge factor code.
8. The Nium platform engages the Nium's Client system (via an API that Nium's Client must have implemented following the API contract mandated by Nium) to verify the 6-digit code.
9. The Nium's Client system performs the verification and returns the verification result.
10. The Nium platform verifies the result and sends the authentication result to both the network and the merchant.

The Verify Passcode API that the Nium Client needs to implement

Nium Client will need to implement the Passcode Validation API - the URL endpoint of this needs to be configured during program setup time. So, please work with your program contact for this step. The API can expect a payload similar to the following:

{
    "passcode":"123456",
    "maskedCardNumber":"4611-35xx-xxxx-1234",
    "clientHashId":"e2710bdf-25b1-4535-9ccf-09b70bcff684",
    "customerHashId":"e2708eef-25b1-4535-9ccf-09b70bcff684",
    "walletHashId":"e2708bdf-25b1-4535-9ccf-09b70bcdd684",
    "cardHashId":"e3008bdf-25b1-4535-9ccf-09b70bcff684",
    "transactionAmount":"1.10",
    "transactionCurrency":"EUR",
    "merchantName":"Test Merchant"
}

By using one or many of the payload data, Nium Client can check for and verify the given passcode (this is the 6-digit knowledge factor code the user enters during the second step of 3DS authentication.

Client could encounter three possible scenarios:

1. A passcode is found registered in the cardholder's record and found matching with the one in the request payload. In this case, client needs to send the response code "SSS000".
2. A passcode is found registered in the cardholder's record and found not matching with the one in the request payload. In this case, client needs to send the response code "VCU602".
3. A passcode is not found registered in the cardholder's record. In this case, client needs to send the response code "VCU601".

The JSON response the client is expected to return will look like the following:

{
    "message": "Request processed successfully",
    "referenceNumber": "481b18ad-1146-439b-a227-f42fda6ae306",
    "responseCode": "SSS000"
}

{
    "message": "Passcode not setup by user",
    "referenceNumber": "5faee1b2-97b0-4355-b2ad-774f1bfcb6c5",
    "responseCode": "VCU602"
}

{
    "message": "Passcode Mismatch",
    "referenceNumber": "9cac7923-42bf-4c9e-97d3-23ef41ba86b1",
    "responseCode": "VCU601"
}

Reference number is something unique for every authentication for audit purposes. Nium Client is expected to generate this unique reference number and pass to Nium in the response. Client is advised to store this code against the authentication request for audit purposes.