Getting Started

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 extra security layer for CNP (card-not-present) transactions. It is 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. But, if the issuer classifies the transaction as risky, it will challenge the customer to confirm his identity using SCA (strong customer authentication) mechanisms.

note

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

High-level integration steps for developers

Use these high-level steps to guide you through the integration process.

Step 1: Review the 3D Secure solution integration options

Review the conceptual information on this page for a high-level overview of 3D Secure 2 and the different transaction authentication flows in 3DS 2 (frictionless, challenge, and 3RI). Once you are familiar with 3D Secure 2, review the integration options that the Elavon’s 3D Secure solution supports.

Step 2: Get authentication credentials

To receive authentication credentials that you would need to test the different integration options in the sandbox environment, fill in the information requested in this form.

3D Secure 2 test credentials request form

We will send you the credentials by the next business day. We will also send contact details to whom you can reach out for any assistance required during the integration and testing process.

Additional resources

Step 3a: Sandbox testing if integrating directly with the 3DS Server

Follow these high-level steps to test your server’s integration with the 3DS Server.

  • Action 1: Collect the required cardholder and transaction details.
  • Action 2: (Optional) To verify if the cardholder’s account number supports 3DS 2, send a /lookup request.
  • Action 3: To initiate a 3DS 2 authentication check, send all required and optional (if available) cardholder and transaction details in an /authenticate request.
  • Action 4: Verify the authentication response and use the information in the 3DS 2 test cards table for the next steps for the transaction status (transStatus) you received in the response.

Additional resources

Step 3b: Sandbox testing if using the Web SDK

Follow these high-level steps to test your integration through the Web SDK.

  • Action 1: Embed the Web SDK JavaScript file to your payment page.

  • Action 2: Access the Web SDK functionality from the window object

    window.Elavon3DSWebSDK

  • Action 3: Make a call to your server to get an authentication token that you will need to use with the Web SDK. Note that the Web SDK only supports JWT tokens for authentication.

  • Action 4: Create a new instance of the object and assign it to your preferred variable.

    const sdk = new window.Elavon3DSWebSDK({
    baseUrl: 'https://baseUrl',
    token: 'authentication token from Action 3'
});

  • Action 5: Call the web3dsFlow method

    sdk.web3dsFlow(data);

    This method will run the 3DS flow and display and handle any cardholder challenges if required by the issuer.

  • Action 6: Use authentication values received from the issuer in Action 5 to confirm the order.

Additional resources

Step 4: Begin the onboarding process

After you have tested the different integration options, work with the Elavon representative to begin the onboarding process.

Before you go live, check for the following:

  • You have the production endpoint and credentials.
  • You have run different test scenarios such as frictionless, challenge, 3DS 1 fallback, and 3RI in the UAT (sandbox) environment. This step will give you the confidence to handle different scenarios in a production environment.
  • You are boarded for all right card schemes. If you don’t have the required details, check with your Elavon contact.
  • If you are using 3D Secure through Converge, then work with your Elavon contact to check that all required elements are enabled for your Converge environment.

Step 5: Go Live!

  • Action 1: Activate your production account.
  • Action 2: Connect your production environment to Elavon’s production server.
  • Action 3: Go Live!

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 the 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 successful authentication and decreasing the cases of fraud.

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

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.

3D Secure 2 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. If the issuer needs more information from the cardholder to authenticate the transaction, the transaction needs a challenge flow. But, scenarios where a merchant already has the cardholder details and initiates the transaction needs a 3DS requestor-initiated (3RI) 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. Based on the data, the issuer determines that it does not need any cardholder interaction to complete the 3D Secure 2.1 authentication process.

Example screens that show an illustration of the frictionless flow illustration where the cardholder places an order. The issuer performs a 3D Secure 2 check and concludes that no additional authentication required and the order is successful

Figure caption: Sample screens a cardholder might see for a frictionless flow

Challenge flow

In a challenge flow, the 3DS Server sends an authentication request to the issuer using the data the merchant sent but the authentication response sent by the issuer request extra information from the cardholder. For example, the issuer would challenge the cardholder if it deems the transaction 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 extra authentication by the customer is complete.

If the challenge response is successful, the issuer authenticates the transaction and returns the authentication values to the 3DS requestor. At this point, the 3DS requestor may use the authentication values to proceed with transaction authorization.

Example screens that show an illustration of challenge flow where the cardholder places an order. The issuer performs a 3D Secure 2 check and concludes that additional authentication is required. The issuer challenges the cardholder who authenticates and based on the authentication, the order is successful

Figure caption: Sample screens a cardholder might see for a challenge flow

3DS Requestor-initiated (3RI) flow

In a 3D requestor-initiated (3RI) or a merchant-initiated transaction, the cardholder is not present during the transaction. The merchant’s server has the cardholder’s information stored. Merchant can use the already stored cardholder information for confirmation of account information or cardholder authentication. For example, confirmation of account validity in case of recurring transactions such as subscriptions, insurance premium payments, etc. For more details, see an overview and steps in a 3DS requestor initiated transaction

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

Related topics