The process consists of several parties and messages between these parties, but this chapter will simplify and cover the basics. The BIN range is required to be enrolled in the card scheme’s 3DS services. This is done during the implementation project.

    1. The process starts with the merchant initiating the 3DS process.
    2. The merchant can request bypassing the authentication of the customer, if the risk level of the transaction is deemed low. Enfuce will analyse the risk and applicable regulation to determine if authentication is required.
    3. If authentication is required, the merchant will receive a URL that the customer should be redirected to for the authentication (“landing page”).
    4. As the customer reaches the landing page, it will
      • prompt an API call to the issuer responsible for authenticating the customer, or
      • initiate the one-time password flow
    5. The customer is authenticated.
    6. Based on the result of the authentication, Enfuce forwards that response to the merchant.
    7. The merchant will take the next step:
      • a. If the authentication was successful, the merchant will add information to the authorisation that a successful 3DS authentication was done. Enfuce will consider this during the authorisation processing.
      • b. If the authentication was unsuccessful, the merchant needs to discontinue the purchase or ask for an alternative payment method.

​
Enfuce 3DS service

Enfuce operates as a processor and facilitator in the 3DS flow. We are integrated to card schemes and receive 3DS authentication requests and send responses. Our standard service is to enroll all cards to the 3DS service during the card creation process. An e-commerce block can be set on cards via the API if all online purchases should be declined.

Processing the 3DS request includes verifying that the card number is valid and enrolled to 3DS and determining the need for authentication (see Risk based authentication). After the initial processing, we will initiate the authentication protocol. As described earlier in the process flow, this means that the merchant will re-direct the cardholder to your bespoke landing page.

The landing page layout includes:

  • Your logo
  • MC/Visa required logo
  • Merchant name
  • Amount of purchase
  • Further instructions on how to authenticate

We have two authentication options:

  1. Authentication performed by the issuer
    • We will trigger an API call to your endpoint requesting you to authenticate the cardholder. The request includes identification of the card that it refers to and information about the purchase (merchant, amount). You can authenticate the cardholder e.g. by biometric authentication in your app or using national authentication methods.
  2. Authentication with a one-time password See the detailed description below

After authentication is performed, we will generate a response message to the merchant, a digital signature and control value. The response message is sent to the merchant’s server (MPI) and to the payment system’s AHS – authentication history server (IPS Servers).

The merchant reflects the outcome of the 3DS process in the authorisation request which includes information about if authentication has been done and how.

​
Risk based authentication

Unlike the process in physical locations, the 3DS 2.x protocol enables the possibility for the issuer to allow purchase without authentication, i.e. Risk Based Authentication (RBA). This process is designed to create a frictionless payment experience for the customer. As the first step of the 3DS process, Enfuce will determine if authentication is needed, based on the PSD2 regulation and card scheme rules.

  • If authentication is not required, Enfuce will confirm the decision to the merchant and the merchant can proceed to the authorisation process without requiring the customer to authenticate.
  • If authentication is required, Enfuce will communicate this to the merchant and the merchant is then expected to direct the customer to the 3DS landing page that in turn will trigger Enfuce ID API to request the issuer to perform the customer authentication.

​
Authentication through one-time-password

Enfuce offers SMS OTP (one-time password sent with SMS text) as a way to authenticate 3DS online payments. This method authenticates the purchase by using a static password and One-Time password (OTP) sent to the customers’ mobile device.

The main benefit of choosing this method is that you don’t need to have an external authentication provider or implement anything additionally – we do it for you!

If you chose SMS OTP as the authentication method, once your cards are enrolled into 3DS, all 3DS authentication requests will use SMS OTP.

​
Setting a password for 3DS authentication

Before attempting a 3DS purchase, the customer will need to have a password associated with their card. The password can be set by updating the ‘SET_3DS_STATIC_PWD’ property of the card using the Update Card call in the Card API. We do not restrict how often a cardholder can change their password, or the number of times they can change it.

If the password is not set, an error will appear on the landing page and the cardholder will be redirected back to the merchant’s website.

​
Authenticating a 3DS purchase with SMS OTP

When a customer makes a purchase online, if you’re using SMS OTP for authentication, the customer will see a landing page asking them to input their password associated with a card and an OTP sent to their mobile device. At the same time, Enfuce will send a code to the customer. The code is a one-time password for the purchase.


When the customer submits a code that matches the one sent to their mobile device, the authentication process is completed.

​
Phone number

The SMS is sent to the phone number associated with the customer’s account. Enfuce will send the SMS to the number provided in the mobileNumber field in the Create Customer API call.

If a customer changes their phone number, make sure to replace the old number using the Update a Customer call. The new number will automatically be used in the next authentication request.

If there is no mobileNumber associated with the Customer, they will receive an error page informing them they need to set the phone number.

​
SMS message

You can choose the text for the SMS you want your customers to see, as well as what will be displayed as the sender. The one time password (OTP) included in the SMS will be a 6-digit numeric value.

If the OTP doesn’t arrive, the cardholder can request a new one by clicking a link on the landing page.

If the OTP doesn´t match, the customer is prompted to try again. They can try to enter the correct password 3 times. If they don’t succeed, they will need to initiate the payment again.

The authentication process can last up to 10 minutes to ensure that the customer has time to fetch their device. If the customer doesn’t complete the authentication, they will be redirected back to the merchant’s website where they can initiate the payment again.

When the customer enters the correct OTP, Enfuce responds to the merchant that the customer has been successfully authenticated.

​
Compliance

Authentication using SMS OTP combined with a static password satisfies the requirements for Strong Customer Authentication (SCA) in the scope of PSD2 requirements for all markets where it is mandated. The static password satisfies the knowledge element of Strong Customer Authentication, while the OTP satisfies the possession element, as it requires the cardholder to have a mobile device.

​
SMS OTP authentication with one-factor

Only using OTP (without a card-associated password) is a permitted authentication method in some markets. We also support a simplified, one-factor authentication version of the SMS OTP authentication where there is no card-associated password, rather the customer is authenticated only by the OTP sent with SMS.

Transaction-specific strong customer authentication (SCA) dataAddress verification service