OTP + Knowledge-based authentication flow

The one-time password (OTP) and knowledge-based authentication (KBA) flow is a security mechanism used to authenticate a user during online transactions. It combines the use of an OTP and KBA to verify the identity of the user and authorize a transaction.

The flow is designed to meet the requirements of the European Payment Services Directive (PSD2) and Strong Customer Authentication (SCA) for certain online transactions to enhance security and protect customers' financial information.

PSD2 SCA regulation mandates the authentication process to involve two out of three factors of authentication:

1. What you have—possession factor
2. What you know—knowledge factor
3. Who you are—inherence factor

The OTP plus KBA fulfills the mandate as follows:

• An OTP delivered to the cardholder's mobile, and email address can be considered a valid possession factor.
• The six-digit knowledge factor, which the cardholder needs to have securely created and stored in their profile, can be considered a valid knowledge factor.

📌

IMPORTANT

The Short Message Service (SMS) OTP plus the KBA option is relevant in the European Economic Area (EEA) and the United Kingdom (UK) due to the PSD2 SCA regulation.

Six-digit knowledge factor

If you're within the EEA and UK region and are interested in card issuance you need to collect and store a six-digit code—knowledge factor—from the account holders. You can collect this six-digit code at an appropriate stage in the customer life cycle. You can indicate to the account holders when they need to use this code, for example, when they're doing an online transaction and they need to remember to use the code.

Six-digit code KBA storage

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 SCA exemption. When that happens, the 3DS authentication can be performed only by using the standard OTP-based authentication to provide a simplified user experience.

OTP plus KBA

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.

Scenario 1: Nium manages the 3DS authentication and KBA validation.

In this use case, Nium doesn't have to consult you on every transaction since Nium manages the 3DS Authentication and the KBA validation.

Nium makes this decision based on the 3DS configuration:

• Consult you on every transaction — Yes/No.
• KBA validated by — Nium/You

💁

TIP

You are not expected to implement any API in this scenario.

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 prompts the cardholder, via the merchant’s checkout experience, to enter a one-time passcode that Nium sends via SMS text and email.
5. Nium verifies the OTP and determines that the cardholder needs to be further challenged for KBA.
6. Nium prompts the cardholder to enter the six-digit passcode.
7. The cardholder enters the six-digit passcode.
8. Nium validates the passcode and sends the results to the network and the merchant.

Scenario 2: You manage the 3DS authentication and Nium handles the KBA validation.

In this use case, Nium consults you on every transaction, however, Nium manages the KBA validation. Refer to the 3DS Overview guide for more information.

Nium makes this decision based on the 3DS configuration:

• Consult you on every transaction — Yes/No.
• KBA validated by — Nium/You

💁

TIP

In this use case you need to implement only the Check Authentication Method V2 API.

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 consults your system via the Check Authentication Method V2 API, which you need to implement, following the API contract mandated by Nium.
5. Nium prompts the cardholder, via the merchant’s checkout experience, to enter a one-time passcode that Nium sends via SMS text and email.
6. Nium verifies the OTP and determines that the cardholder needs to be further challenged for KBA.
7. Nium prompts the cardholder to enter the six-digit passcode.
8. The cardholder enters the six-digit passcode.
9. Nium validates the passcode and sends the results to the network and the merchant.

Scenario 3: Nium manages the 3DS authentication and you manage the KBA validation.

In this use case, Nium doesn't have to consult you on every transaction since Nium manages the 3DS authentication.

Nium makes this decision based on the 3DS configuration:

• Consult you on every transaction — Yes/No.
• KBA validated by — Nium/You

Transaction flow

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 prompts the cardholder, via the merchant’s checkout experience, to enter a one-time passcode that Nium sends via SMS text and email.
5. Nium verifies the OTP and determines that the cardholder needs to be further challenged for KBA.
6. Nium prompts the cardholder to enter the six-digit passcode.
7. The cardholder enters the six-digit passcode.
8. Nium engages your system via the Passcode Validate API V2, which you need to implement, following the API contract mandated by Nium, to verify the six-digit passcode.
9. Your system performs the validation and returns its result.
10. Nium verifies the result and sends it to the network and the merchant.

Scenario 4: You manage both the 3DS authentication and KBA validation.

In this use case, Nium consults you on every transaction. Refer to the 3DS Overview guide for more information.

Nium makes this decision based on the 3DS configuration:

• Consult you on every transaction — Yes/No.
• KBA validated by — Nium/You

Transaction flow

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 consults your system via the Check Authentication Method V2 API, which you need to implement, following the API contract mandated by Nium.
5. Nium prompts the cardholder, via the merchant’s checkout experience, to enter a one-time passcode that Nium sends via SMS text and email.
6. Nium verifies the OTP and determines that the cardholder needs to be further challenged for KBA.
7. Nium prompts the cardholder to enter the six-digit passcode.
8. The cardholder enters the six-digit passcode.
9. Nium engages your system via the Passcode Validate API V2, which you need to implement, following the API contract mandated by Nium, to verify the six-digit passcode.
10. Your system performs the validation and returns its result.
11. Nium verifies the result and sends it to the network and the merchant.