OOB authentication flow

Out-of-Band Authentication Flow

The out-of-band (OOB) authentication flow in 3D Secure (3DS) transactions is a mechanism that authenticates a cardholder using an external channel or device separate from the primary transaction channel.

In this flow, instead of relying solely on the traditional browser-based authentication, an additional verification step is introduced through an OOB communication channel. This can include methods such as a dedicated mobile application.

The purpose of the OOB authentication flow is to enhance the security of online transactions by providing an extra layer of verification, ensuring that the person initiating the transaction is a legitimate cardholder.

šŸ’

TIP

The OOB authentication method is available in all geographic regions.

The OOB authentication fulfills the mandate as follows:

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

OOB authentication factor

Nium expects its clients interested in card issuance to have a secure onboarding process to bind their mobile app to their cardholder's deviceā€”possession factor. Once it's securely bound, the mobile app prompts the cardholder to complete the authentication through biometrics which typically is a fingerprint.

OOB applicability

At Nium, we support the following forms of OOB authentication:

OptionsRegionDescription
OOB with fallback (OTP)APACThe OOB with fallback one-time-password (OTP) authentication mode is used with the provision of OTPs in the event of a response timeout for secure online card transactions.
OOB with fallback (OTP and KBA)EU/UKThe OOB authentication with fallback OTP and KBA mode is used with the provision of OTPs and KBA in the event of a response timeout for secure online card transactions.

šŸ“Œ

IMPORTANT

OOB flows require participation from you, the owner of the program interacting with the cardholders. You need to implement certain APIs and expose them via an accessible URL for Nium.

One-leg out

If the issuer and acquirer are not within the EEA and the UK, then Nium may apply a one-leg out (OLO)-driven Strong Customer Authentication (SCA) exemption. When that happens, the 3DS authentication can be performed only by using the simple OOB authentication flow or the standard OTP-based authentication to provide a simplified user experience.

OOB authentication flow

The following diagrams capture the high-level interaction among key parties when a cardholder uses their card online to do shopping at an e-commerce merchant. Once the authentication is successful, the merchant endā€”acquirer, acquiring processor, payment service provider payment gatewayā€”receives the Cardholder Authentication Verification Value (CAVV) or Universal Cardholder Authentication Field (UCAF) authentication result. It's expected that the merchant end includes the authentication result when submitting the transaction authorization to the network as authentication proof.

OOB authentication flow

This diagram explains how a simple OOB authentication works.

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

  1. The cardholder performs an online transaction such as shopping at an e-commerce site.
  2. The merchant initiates an authentication request by sending the request to the card network such as Visa, Mastercard, etc.
  3. The card network routes the authentication request to Nium.
  4. Nium engages with your system via the Check Authentication Method V2 API, if you opt for it. You need to have implemented the operation following the API contract, mandated by Nium, to check if the cardholder's device supports biometrics authentication.
  5. Your system sends the results of the authentication method supported by the cardholder's device to Nium. These results can be OOB authentication, if the cardholder's device supports biometrics, otherwise the applicable fallback method is returned.

For OOB authentication:

  1. Nium prompts the cardholder, via the merchantā€™s checkout experience, to complete the authentication using your mobile application.
  2. At the same time, Nium engages with your system, via the Initiate OOB Authentication V2 API. You need to have implemented the operation following the API contract, mandated by Nium, to initiate the OOB authentication.
  3. Your system delivers a push notification to the cardholder to complete the authentication for the online transaction using your mobile application.
  4. The cardholder authenticates using biometrics through your mobile application. The results of the authentication are relayed to your system.
  5. Your system informs Nium of the authentication results via the OOB Authentication Callback API. you need to have implemented the operation following the API contract mandated by Nium.
  6. Nium sends the authentication result to the network and the merchant.

OOB authentication flow with fallback to OTP

In this use case, you want to consult on every transaction and the flow supports only OOB authentication with fallback.

While the mobile app offers a seamless experience through biometrics authentication, potential constraints can occur. These include data connectivity issues, the prevalence of biometrics support on devices, or network availability when the cardholder is roaming overseas. These limitations may occasionally present challenges for the cardholder to complete the authentication under these scenarios.

In situations where OOB authentication isn't feasible, the cardholder is offered a backup authentication method option, for example, OTP only. Refer to the OTP-based 3DS authentication flow guide for more information.

Transaction flow

  1. The cardholder performs an online transaction such as shopping at an e-commerce site.
  2. The merchant initiates an authentication request by sending the request to the card network such as Visa, Mastercard, etc.
  3. The card network routes the authentication request to Nium.
  4. Ā Nium engages with your system via theĀ Check Authentication MethodĀ V2 API. You need to have implemented the operation following the API contract, mandated by Nium, to check if the cardholder's device supports biometrics authentication.
  5. Your system sends the results of the authentication method supported by the cardholder's device to Nium. These results can be OOB authentication, if the cardholder's device supports biometrics, otherwise OTP only is returned.

For OOB authentication:

  1. Nium prompts the cardholder, via the merchantā€™s checkout experience, to complete the authentication using your mobile application.
  2. At the same time, Nium engages with your system, via the Initiate OOB Authentication V2 API. You need to have implemented the operation following the API contract, mandated by Nium, to initiate the OOB authentication.
  3. Your system delivers a push notification to the cardholder to complete the authentication for the online transaction using your mobile application.
  4. The cardholder authenticates using biometrics through your mobile application. The results of the authentication are relayed to your system.
  5. In the event of a timeout or other unforeseen circumstances, such as the user is not able to complete the OOB authentication, the system triggers the OTP-based 3DS flow as a fallback.

Refer to the OTP-based 3DS authentication flow guide for more information.

OOB authentication flow with fallback to OTP plus KBA

In this use case, you want to consult on every transaction and the flow supports only OOB authentication with fallback.

While the mobile app offers a seamless experience through biometrics authentication, potential constraints can occur. These include data connectivity issues, the prevalence of biometrics support on devices, or network availability when the cardholder is roaming overseas. These limitations may occasionally present challenges for the cardholder to complete the authentication under these scenarios.

In situations where OOB authentication isn't feasible, the cardholder is offered a backup authentication method option i.e., OTP plus KBA. Refer to the OTP + Knowledge-based authentication flow guide for more information.

Transaction flow

  1. The cardholder performs an online transaction such as shopping at an e-commerce site.
  2. The merchant initiates an authentication request by sending the request to the card network such as Visa, Mastercard, etc.
  3. The card network routes the authentication request to Nium.
  4. Ā Nium engages with your system via theĀ Check Authentication MethodĀ V2 API. You need to have implemented the operation following the API contract, mandated by Nium, to check if the cardholder's device supports biometrics authentication.
  5. Your system sends the results of the authentication method supported by the cardholder's device to Nium. These results can be OOB authentication, if the cardholder's device supports biometrics, otherwise OTP plus KBA is returned.

For OOB authentication:

  1. Nium prompts the cardholder, via the merchantā€™s checkout experience, to complete the authentication using your mobile application.
  2. At the same time, Nium engages with your system, via the Initiate OOB Authentication V2 API. You need to have implemented the operation following the API contract, mandated by Nium, to initiate the OOB authentication.
  3. Your system delivers a push notification to the cardholder to complete the authentication for the online transaction using your mobile application.
  4. The cardholder authenticates using biometrics through your mobile application. The results of the authentication are relayed to your system.
  5. In the event of a timeout or other unforeseen circumstances, for example, the user is not able to complete the OOB authentication, the system triggers the OTP plus the KBA flow as a fallback.

Refer to the OTP + Knowledge-based authentication flow guide for more information.

Authentication APIs

The following authentication APIs aren't exposed in the Swagger documentation. You, as the client, use these APIs for development. Nium directly calls these APIs.

API nameActionReference link
Check Authentication Method V2If you opt to be consulted on every transaction, you need to implement this API. Respond with the authentication method applicable to the e-commerce transaction.Check Authentication Method V2
Initiate OOB Authentication V2You need to implement the Initiate OOB Authentication V2 API as part of the OOB authentication process. Nium invokes the endpoint to perform the operation and start the OOB authentication step for an e-commerce transaction.Initiate OOB Authentication V2
OOB Authentication CallbackUse this callback to notify Nium after successfully processing your OOB authentication as part of the SCA flow.OOB Authentication Callback
Passcode Validation V2If you opt to validate the passcode, you need to implement the Passcode Validation V2 API as part of the KBA flow for an e-commerce transaction.Passcode Validation V2
Add Or Update PasscodeIf you opt for Nium to manage the passcode, use this API to set or update it for a specific card.Add Or Update Passcode
3DS Passcode Enrollment StatusIf you opt for Nium to manage the passcode, use this API to retrieve the status of the passcode enrollment for all cards associated with the wallet. Results can be filtered by the cardHashId.3DS Passcode Enrollment Status