OOB 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:

📌

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:

6. Nium prompts the cardholder, via the merchant’s checkout experience, to complete the authentication using your mobile application.
7. 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.
8. Your system delivers a push notification to the cardholder to complete the authentication for the online transaction using your mobile application.
9. The cardholder authenticates using biometrics through your mobile application. The results of the authentication are relayed to your system.
10. 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.
11. 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:

6. Nium prompts the cardholder, via the merchant’s checkout experience, to complete the authentication using your mobile application.
7. 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.
8. Your system delivers a push notification to the cardholder to complete the authentication for the online transaction using your mobile application.
9. The cardholder authenticates using biometrics through your mobile application. The results of the authentication are relayed to your system.
10. 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:

6. Nium prompts the cardholder, via the merchant’s checkout experience, to complete the authentication using your mobile application.
7. 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.
8. Your system delivers a push notification to the cardholder to complete the authentication for the online transaction using your mobile application.
9. The cardholder authenticates using biometrics through your mobile application. The results of the authentication are relayed to your system.
10. 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.