OOB Authentication Flow

Out-of-Band 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 OOB authentication fulfills the mandate as follows:

  • The mobile app is bound to the device through a secure onboarding process, can be considered a possession factor
  • The biometrics which is typically be a fingerprint, can be considered an inherence factor.

Nium expects the BaaS clients (who is interested in cards issuing) to have a secure onboarding process to bind their mobile app to their cardholder's device (possession factor). Once it is securely bound, the mobile app prompts the cardholder to complete the authentication through biometric which will typically be a fingerprint.

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.

OOB with fallback to OTP (SMS) + Knowledge Factor authentication

While mobile app offers a seamless experience through biometrics authentication, potential constraints such as data connectivity issues, prevalence of biometrics support on devices, or network availability when cardholder is roaming overseas, may occasionally present challenges for cardholder to complete authentication under these scenarios. With this in mind, in situations where OOB authentication is not feasible, the cardholder will be offered a backup authentication method option, i.e. OTP (SMS) + Knowledge Factor. By clicking on the alternative link option on the challenge screen, the OTP (SMS) + Knowledge Factor authentication flow will be triggered, please refer to the following for further details: OTP + Knowledge Factor authentication flow

One Leg Out (OLO)

If the issuer and acquirer are not within EEA / UK, then we may apply OLO driven SCA exemption. When that happens, the cardholder will be prompted to complete the authentication through OOB (biometrics), however the backup authentication method option will be the Standard OTP based authentication (without additional Knowledge factor requirement) to provide simplified user experience.

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.

5732

When a cardholder attempts to make an online payment to a merchant supporting 3DS2 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 engages the Nium's Client system (via Check Authentication Method an API that Nium's Client must have implemented following the API contract mandated by Nium) to check if the cardholder's device support biometrics authentication.
  5. The Nium's Client system sends the results of the authentication method supported by the cardholder's device to the Nium platform. This results can be OOB authentication (if the cardholder's device supports biometrics), otherwise OTP (SMS) + Knowledge Factor is returned.

For OOB Authentication:

  1. For OOB authentication, the Nium platform prompts the cardholder, via an embedded iframe within the merchantโ€™s checkout experience, to complete the authentication using his/her issuer's app.
  2. At the same time, the Nium platform engages the Nium's Client system (via Initiate OOB Authentication an API that Nium's Client must have implemented following the API contract mandated by Nium) to initiate the OOB authentication.
  3. The Nium's Client system delivers a push notification to the cardholder to complete the authentication for the online transaction using the issuer's mobile app.
  4. The cardholder authenticates using biometrics through the issuer's mobile app. The results of the authentication is relayed to the Nium's Client system.
  5. The Nium's Client system informs the Nium platform the authentication results (via OOB Authentication Callback a callback API that Nium's Client must have implemented following the API contract mandated by Nium).
  6. If there is no valid response received from the Nium's Client system within stipulated timeframe, a fallback link to OTP (SMS) + Knowledge Factor authentication flow will be displayed to cardholder to complete the authentication. The fallback flow is supported for transactions initiated from browsers only.
  7. The Nium platform sends the authentication result to both the network and the merchant.

For OTP (SMS) + Knowledge Factor, please refer to OTP + Knowledge Factor authentication flow.

Please refer Check Authentication Method API for technical details.

Nium Client will need to implement the Check Authentication Method 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 like the following:

{
    "clientHashId": "e4wc6a3b-52a0-2301-a670-08db16e8447a",
    "customerHashId": "df3dfdf-d75a-4d7e-b575-f8ed34egfh94",
    "cardHashId": "5fh34flg-8e7a-4bb5-a010-3a07cf714534",
    "email": "[email protected]",
    "phoneNumber": "9834201949"
}

Client could encounter two possible scenarios:

  1. Cardholder's device supports biometrics authentication on issuer's mobile app. In this case, client sends the response code "01" to trigger the OOB with fallback to OTP(SMS) + Knowledge factor authentication flow.
  2. Cardholder's device does not support biometrics. In this case, client sends the response code "02" to trigger the OTP(SMS) + Knowledge factor authentication flow.

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

{
  "respCode" : "01", 
  "message"  : "OOB with fallback to OTP+Passcode"
}
{
  "respCode" : "02", 
  "message"  : "OTP+Passcode Only"
}

Please refer to Initiate OOB Authentication API for technical details.

Nium Client will need to implement the Initiate OOB Authentication 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 like the following:

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

Please refer to OOB Authentication Callback API for technical details.

Nium Client will need to implement the OOB Authentication Callback API - the URL endpoint of this is provided by Nium in the API Reference. The API can expect a payload like the following:

{ 
    "authTransactionId": "2096355c-57c3-43c6-9c4a-fb155a026e06",
    "referenceNumber": "1b6865e4-5839-424a-8e73-965ef15c5d89",
    "status": "Success",
    "statusCode": "SSS000"
}

In the case of fallback to OTP (SMS) + Knowledge Factor, please refer to OTP + Knowledge Factor authentication flow.

Please refer Passcode Validation API for technical details.

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 like 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.