UI mockups of a 3D Secure 2 check experience by the cardholders

error_outline

note

EMV 3D Secure 2.1 is a new offering by Elavon. If you have identified any errors or gaps in the content, please contact: email #SEDevPortalSupport@elavon.com

When you integrate the 3D Secure 2 check capability on your eCommerce website or your mobile app, the common user experience of cardholders using your website or the mobile app is frictionless i.e. as soon as the cardholder places the order, the 3D Secure 2 check happens in the background and the order is confirmed. The exception to this frictionless experience is a challenge flow, i.e. when the issuer (authenticating bank) decides to add an extra protective step to authenticate the cardholder. The screens on this page intend to give you (merchants and developers) a high-level overview of the various screens the cardholder would see on their mobile app or browser when shopping on a merchant’s app or website respectively.

error_outline

note

These screens are only samples and a rough representation of the screens that a cardholder would see when making an eCommerce transaction. Most of these screens belong to the merchant application and not to Elavon's 3DS library. The screens that belong to the 3DS library, i.e. the progress indicator screen and the challenge screens, follow EMVco's UI guidelines.

To recap, a 3D Secure 2 authentication can be either of the following:

Frictionless flow - the issuer does not need any interaction with the cardholder to authenticate the transaction.

Challenge flow - the issuer needs additional information from the cardholder to authenticate the transaction. The additional information is sought through a challenge where the issuer uses one or a combination of strong customer authentication (SCA) methods:

  • Knowledge (Something the cardholder knows). For example, PIN, passphrase, secret questions, security pattern
  • Ownership (Something the cardholder has). For example, mobile phone, tokens, wearable devices
  • Inherence (Something the cardholder is). For example, fingerprint, facial, or voice recognition

Initial screens common to both frictionless or challenge flows

The initial screens represent those screens when the cardholder starts interacting with your mobile app or website, selects and adds products to the cart, enters payment details (unless already stored on-file), and clicks checkout.

Cardholder interaction 1: cardholder selects a product on the merchant’s app or website (either on mobile or desktop), adds the selected item to the cart, and proceeds to checkout.

Mobile app

Browser

Cardholder interaction 2: In this scenario, we assume that the card details are saved on the merchant's website/app. On the checkout screen, the cardholder reviews the card details, the billing address, the delivery address, and places the order. Once, the cardholder clicks the place order button, the data is sent to the issuer via the 3DS Server / SDK. At this point, it also starts the 3D Secure flow.

Mobile app

Browser

Cardholder interaction 3: While the app/browser displays the ‘processing’ or ‘order-in-progress’ screen, the 3DS Server sends the cardholder and transaction details to the issuer, in the form of an authentication request (aReq), who evaluates the transaction risk based on the information shared by the 3DS requestor (merchant website/app).

Mobile app

Browser

After the data is sent to the issuer, the following scenarios are possible when the issuer sends back the authentication response (aRes):

  • Frictionless flow - The issuer authenticates the transaction without challenging the cardholder.

  • Challenge flow - The issuer needs additional information from the cardholder. It will use one or more authentication methods for the challenge. To present the challenge, it will use the following ‘challenge screen presentation' options:

    • Single-select option - cardholder can select only one option.
    • Multi-select option - cardholder can select one or more correct options.
    • Text-based - cardholder has to enter a one-time passcode sent via SMS or email or answer a knowledge-based question.
    • OOB (Out of band authentication) - authentication is done using any other app on the same or a different device. For example, the bank app.
error_outline

note

The challenge method used for authentication is at the discretion of the issuer. The screen layout of the challenge screen is defined by EMVco and the challenge text is populated by the issuer. Merchants can only change the look and feel of some of the challenge screen elements.

If you are integrating directly with the 3DS Server or if you are using the Web SDK, you can only control the window size of the challenge screen. For more details, see Step 6 of the Direct integration with the 3DS Server topic or see the authenticate request sample if you are using the Web SDK.

Scenario 1: Frictionless flow

Cardholder interaction: Frictionless flow is the most common scenario where the issuer determines that it doesn’t need further authentication to authenticate the transaction. The app/browser displays the order confirmation page to the cardholder. If the issuer receives all required and optional fields in the authentication request that is sent in the background by the 3DS Server, then there is a high probability that the 3D Secure authentication check will be a success. The result is a frictionless experience for the cardholder and a liability shift for you.

Mobile app

Screen that shows the purchase was confirmed in the mobile app

Browser

Screen that shows the purchase was confirmed in the merchant website

Scenario 2: Challenge validation using an OTP

(Screen presentation: Single-select option (1) and text-based (2))

Cardholder interaction: In this example, the challenge screen notification requests the cardholder to select a registered email ID or a mobile number to receive a one-time code/passphrase (OTP). After the cardholder selects an option, the cardholder will receive the code on the selected option. The cardholder will enter the code when prompted. If the cardholder enters the correct code, the purchase order is confirmed. However, if the cardholder enters an incorrect code, the issuer may decide to challenge the cardholder using any other authentication method or deny the transaction.

Mobile app

Screen that shows the user selected an option to receive the verification code in the mobile app Screen that shows the user received the verification code in the mobile app

Browser

Screen that shows the user selected an option to receive the verification code in the merchant website Screen that shows the user received the verification code in the merchant website

Scenario 3: Challenge validation using a knowledge-based question

(Screen presentation: Multi-select options)

Cardholder interaction: The issuer decides to challenge the cardholder and presents a challenge screen where the cardholder can select one or more correct options. In this example, the challenge screen notification requests the cardholder to select the cities where the cardholder has lived in the past. After the cardholder selects the options, the issuer validates this data with the data stored in the cardholder's records. If the validation is confirmed, the issuer authenticates the transaction and the purchase order is confirmed. However, if the validation is not positive, the issuer may decide to challenge the cardholder using any other authentication method or deny the transaction.

Mobile app

Screen that shows the user selected the correct options in response to the knowledge based question in the mobile app

Browser

Screen that shows the user selected the correct options in response to the knowledge based question in the merchant website

Scenario 4: Challenge validation using an OOB authentication using single or multiple devices

Cardholder interaction: Issuer decides to challenge the cardholder using an OOB method that pushes the challenge screen to the device. In this example, the challenge screen asks the cardholder to open the bank app to authorize the payment (1). The bank app may or may not be on the same device that the cardholder is using to make a purchase. The cardholder gets an alert on the bank app to authorize the payment (2). The cardholder reviews the transaction details required to authorize the payment and confirms the payment (3). Once the purchase gets confirmed, the merchant's website /app (which was still open in the background) is displayed to the cardholder (4).

Mobile app

Screen that shows the user received an alert in the mobile app to open the bank app

Screen that shows the user received a notification from the bank app to confirm the purchase

Screen that shows the user has opened the bank app and it shows the purchase details and asks user to confirm

Screen that shows the user received the purchase confirmed screen in the mobile app