Elavon downloads and stores cookies on your device when you visit our website. We use these cookies to better understand and improve your browsing experience by identifying most visited pages, personalising content, and measuring site performance.

Essential cookies enable core functionality such as page navigation and access to secure areas. The website cannot function properly without these cookies; they can only be disabled by changing your browser preferences.

Performance cookies help us to improve our website by collecting and reporting information on its usage (for example, which of our pages are most frequently visited).

Cookie Settings

Elavon Financial Services DAC. Registered in Ireland – Number 418442.
Registered Office: Block F1, Cherrywood Business Park, Dublin 18, D18 W2X7, Ireland.
Elavon Financial Services DAC, trading as Elavon Merchant Services, is regulated by the Central Bank of Ireland.
 
Elavon Financial Services DAC. Registered in Ireland with Companies Registration Office. The liability of the member is limited. United Kingdom branch registered in England and Wales under the number BR022122.
Elavon Financial Services DAC, trading as Elavon Merchant Services, is a credit institution authorised and regulated by the Central Bank of Ireland.  Authorised by the Prudential Regulation Authority.  Subject to regulation by the Financial Conduct Authority and limited regulation by the Prudential Regulation Authority.  Details about the extent of our regulation by the Prudential Regulation Authority are available from us on request.

3D Secure 2 is an extra security layer defined by [EMVCo](https://www.emvco.com/emv-technologies/3d-secure/ "EMVCo Website") and major credit card schemes for CNP (card-not-present) transactions. As an e-commerce authentication protocol, it enables the secure processing of payment, non-payment, and account confirmation of card transactions.

Using 3D Secure 2, the issuer inspects over 100 data parameters to:

- verify the cardholder's authenticity
- assess the risk level of the transaction

It acts as a protocol to authenticate a cardholder or verify an account during an e-commerce transaction:

- When the issuer determines the authentication is successful, the merchant can process the transaction without any cardholder interaction.
- If the issuer classifies the transaction as risky it challenges the customer to confirm their identity using Strong Customer Authentication (SCA) mechanisms.


## High-level integration steps for developers

**Step 1:** Review the 3D Secure solution integration options
- You can use the 3D Secure 2 solution either as a standalone offering or as a feature if you are a Converge user.
- To use as a standalone offering, you can choose one or a combination of these options.
    - :magic-link[Direct integration with the 3DS Server]{id="server-to-server-steps"}
    - :magic-link[Web SDK]{id="websdk-overview"} 
    - Mobile SDK (Android) 
    - Mobile SDK (iOS) 

**Step 2:** Get authentication credentials

- To get authentication credentials that you would need to test the different integration options in the sandbox environment, fill in the information requested in the [3D Secure 2 test credentials request form](https://usbank.az1.qualtrics.com/jfe/form/SV_8dkBSYX47JzhPTw)

- 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.

**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 :magic-link[3DS 2 test cards table]{id="test-information"} for the next steps for the transaction status (`transStatus`) you received in the response.

**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.

   - Example: (`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.

You can also :magic-link[try the Web SDK demo application]{id="websdk-demo-app"} to test the different functionalities of the Web SDK.

**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 2.2 to 2.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 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 learn more about PSD2 and SCA compliance, see [Elavon's guide on PSD2 compliance](https://www.elavon.co.uk/perspectives/PSD2.html).


## 3D Secure 2 Authentication flows

In the 3D Secure 2 authentication process, there are three authentication flows: frictionless, challenge, and 3RI. These authentication flows guide the communication (i.e. the requests and responses) among the different components - the cardholder, merchant's website or app, the 3DS Server, the directory server (DS), and the issuer (ACS).

If the issuer verifies and authenticates a cardholder's account details without any additional input from the cardholder, 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.

Review the following sections for more details on these flows:

### 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 from the issuer. Based on the data received, the issuer determines that it does not need any cardholder interaction to complete the 3D Secure 2 authentication process.

Most 3D Secure 2 transactions are expected to be “frictionless.” The payments experience is improved because the cardholder is unaware that an authentication check has even taken place. Also, you don’t need to re-direct the cardholder to the issuer/Access Control Server (ACS) to enter a two-factor authentication.


::image{id="/content/dam/developer-portal-solutions/en-us/elavon/media/images/products/3dsecure2/FrictionlessFlow.png"  max-width="800" max-height="400"  alt="Example screens that show an illustration of the frictionless flow."}


### Challenge flow

In a challenge flow, the 3DS Server sends an authentication request to the issuer using the cardholder and shopping data the merchant sent but the authentication response sent by the issuer request extra information from the cardholder. For example, the issuer might challenge the cardholder (i.e., request for additional information) if it deems the transaction as high-risk or above a predetermined shopping value threshold.

To process the challenge, the 3DS client (Browser or SDK) sends the challenge request to the issuer. The issuer performs the challenge directly with the cardholder and responds with the challenge response after extra authentication by the cardholder 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 (merchant) may use the authentication values to proceed with transaction authorization.


::image{id="/content/dam/developer-portal-solutions/en-us/elavon/media/images/products/3dsecure2/ChallengeFlow.png"  max-width="1000" max-height="500"  alt="Example screens that show an illustration of 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 from an earlier transaction. Merchant can use this 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 :magic-link[3RI Overview]{id="3ri-overview"}.

Getting Started

Alliance Offers

Data as a Service

Invitation to Apply

Accounts

Bank Holidays

Card Activation

Card Controls

Commercial Credit Cards

Credit Card Account Details

Credit Card Accounts Overview

Credit Card Alerts

Credit Card Application Status

Credit Card APRs

Credit Card Disputes - Coming Soon

Credit Card Payments

Credit Card Qualified Offers

Credit Card Statements

Credit Card Transactions

Data Sharing for Marketing Purposes

Digital Wallets

Make a Payment - Coming Soon

Rewards Accelerator

Rewards Automatic Redemption

Rewards: Balance Summary

Rewards Redemption - Coming Soon

Rewards Redemption Accounts

Rewards Redemptions

Rewards Transactions Earned and Redeemed

Travel Notifications

User Profile

3DSecure2

Avvance

CheckoutJs

Commerce SDK

Converge

Disputes Management

Dynamic Currency Conversion

eBoarding

Elavon Cloud Payments Interface

Elavon Payment Gateway

Fusebox

Hosted Payment Page

In Person Payments on Opayo

Leads

Lightbox payment modal

Online Payments on Opayo

Opayo

Opayo Direct

Opayo Forms

Opayo Reporting API

Opayo Server

Opayo Shared API

Payment Method Gateway

Payments Core 365

Simplify

viaconex

XML API

Access Online Transactions

Account Transfers

Account Validation

ACH Originations

Bank Information

Card as a Service

Card as a Service API

Check Payables

Core Banking API

Corporate Account Information

Corporate Credit Cards

Corporate Onboarding

Corporate Statements

Custody

Data Toolbox

Data Toolbox - Accounts

Data Toolbox - Documents

Data Toolbox - Transactions

Disbursements via Zelle®

U.S. Bank Flexible Capital Platform

Freight Payment Customer Profiles

Freight Payment Transactions

Instant Payments

Investment Accounting

Money Movement API

PaySmart

Payee Choice

Payee Token+

Personal Loans

Positive Pay

Push to Card

Receivables

Reference API

RTP® - Real-Time Payments

Tokenized Payments

Treasury Builder

U.S. Bank FBO Account

Virtual Account Reporting

Virtual Card Payments

Voyager Accounts

Voyager Cards

Voyager Drivers

Voyager Transactions

Voyager Vehicles

Wire Transfers

EMV 3D Secure Overview

Authentication

Integration options

Integration options overivew

Direct integration to 3DS server

Direct integration - Sample Request and Response

Integrate using the Web SDK

Web SDK Overview

Using the All-in-one Workflow of the Web SDK

Using the Toolkit Workflow of the Web SDK

Web SDK Demo Application

Other Features

3D Secure 2 for merchants not processing with Elavon

Merchant-initiated (3RI) transactions 

Merchant-initiated (3RI) transactions overview

3RI - Sample Request and Response

Travel industry message extension

Test your integration

API Reference

Error Codes and suggested resolution

Common Error Scenarios

HTTP response status codes

Release notes

Appendices

Product Security and Best Practices

UI Mockups

3D Secure 2 Concepts

3D Secure 2 Glossary