Overview and Workflows

error_outline
note

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

On this page:

What is 3D Secure 2.1 and why should you use it?

3D Secure 2.1, a new standard defined by EMVCo and major credit card schemes, is an additional security layer for CNP (card-not-present) transactions. It can also be defined as an authentication protocol to authenticate a cardholder or verify the account during an e-commerce transaction.

In 3D Secure 2.1, the issuer uses over 100 data parameters to verify a cardholder's authenticity and assess the risk level of a transaction. If the issuer determines the authentication as successful, the merchant can process the transaction without any cardholder interaction. However, if the issuer classifies the transaction as risky, it will challenge the customer to confirm his identity using SCA (strong customer authentication) mechanisms.

error_outline
note

3D Secure 2.1 does not currently support mail order/telephone order (MOTO) transactions.

Strong Customer Authentication (SCA)

SCA is the new requirement to make online payments by European customers secure by adding extra levels of authentication. In SCA, cardholders can verify their identity by using following authentication mechanisms:

  • Something they know: password, passphrase, PIN, sequence, secret fact

  • Something they own: mobile device, wearable device, smart card, token, badge

  • Something they are: fingerprint, face recognition, voice, iris format, DNA signature

With SCA, Issuers can use two or more means of authentication of their choice, thus increasing the chance of a successful authentication and decreasing the cases of fraud.  

error_outline
note

To know more about PSD2 and SCA compliance, see Elavon's guide on PSD2 compliance.

Audience of this document

The information in this document is for merchants and developers who want to use or try Elavon's 3D Secure 2.1 APIs to authenticate cardholders prior to authorizing the transaction. They can use one or more of the following integration options:

error_outline
note

Elavon also supports fallback to 3DS 1 in addition to 3DS 2.1. For steps to enable 3DS 1 fallback while integrating directly to the 3DS Server, see 3DS 1 Fallback . If you are integrating through the 3DS Web SDK, you can still use the 3DS 1 fallback feature. For Web SDK 3DS 1 fallback details, see 3DS Web SDK Overview .

Supported card schemes for 3D Secure 2.1

  • VISA

  • Mastercard

  • American Express

  • Discover

Main components in the 3D Secure authentication process

A 3D Secure authentication request can be initiated by one of the following agents:

  • Merchant's server: Cardholder authentication request initiated by the merchant's server which can be integrated either directly with Elavon's 3DS Server or through a web browser. For detailed steps, see Direct integration to 3DS Server

  • Browser (Web SDK): Cardholder authentication request initiated during a transaction by Elavon 3DS Web SDK integrated on a website’s payment page. For detailed steps, see Integrate using the Web SDK

  • App (iOS or Android): Cardholder authentication request initiated during a transaction on a consumer device by a merchant app, digital wallet, etc. For example, authentication or verification requests sent during the check-out process within a merchant’s app. (Coming soon)

Main components in the 3D Secure authentication process and their major functions:

3DS Server

  • Accept elements for 3D Secure messages and sends the version check and authentication request to the issuer

  • Act as a communication interface between the merchant and the issuer

  • Ensure that the message content is protected

3DS Method

  • Gather browser information and device details required for the authentication request

  • Display challenge UI to cardholder in a challenge flow

FSG SDK

  • Gather device details required for the authentication request from the consumer device

  • Display challenge UI to cardholders in a challenge flow

  • Facilitate cardholder interaction

Access Control Server (ACS)

  • Verify if the card number and the consumer device are eligible for 3D Secure 2.1 or 3DS 1 (if enabled) authentication

  • Authenticate the cardholder for a specific transaction

  • Confirm account information for a 3DS Requestor-initiated (3RI) transaction

  • Provide the challenge UI and process the challenge

Authentication flows

In 3D Secure 2.1 authentication process, there are three authentication flows: frictionless, challenge, and 3RI. If the issuer verifies and authenticates a cardholder account details, the transaction is a frictionless flow. But if the issuer needs more information from the cardholder to authenticate the transaction, the transaction is converted to a challenge flow. However, scenarios where a merchant already has the cardholder details are classified as a 3DS requestor-initiated flow.

Frictionless flow

In a frictionless flow, the 3DS Server sends an authentication request to the issuer using the cardholder data sent by the merchant and receives a successful authentication response because issuer determines that this flow does not need any cardholder interaction to complete the 3D Secure 2.1 authentication process.

Challenge flow

In a challenge flow, the 3DS Server sends an authentication request to the issuer using the cardholder data submitted by the merchant, but the authentication response sent by the issuer requests for additional data from the cardholder. For example, issuer would challenge the cardholder if the transaction is deemed as high-risk or above a predetermined shopping value threshold. If the 3DS Requestor (merchant) decides to process the challenge, the 3DS client (Browser or SDK) sends the challenge request to the issuer, which performs the challenge, and responds with the challenge response after additional authentication by the customer is complete. Upon successfully responding to a challenge, the issuer will authenticate the transaction and return the authentication values back to the 3DS requestor. At this point, the 3DS requestor may use the authentication values to proceed with transaction authorization.

3DS Requestor-initiated (3RI) flow

In a 3RI flow, the 3DS Requestor requests confirmation of account information even without a transaction. For example, confirmation of account validity in case of recurring transactions such as subscriptions, insurance premium payments, etc. The 3DS Server sends an authentication request to the issuer and receives an authentication response from the issuer. The cardholder is not required to be present for this authentication sequence and therefore no challenge flow can be initiated.

Related topics