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.

These are cookies that support site functionality that is visible or advantageous to you or your experience of the site, they enable websites to remember choices and provide a more personalized experience.   Functional cookies help to provide services that you request, such as language preference or layout.

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

These cookies and similar technologies gather information about your browsing habits. They remember that you've visited a website and share this information with other organisations, such as advertisers and platforms on which we advertise. They do this in order to provide you with ads that are more relevant to you and your interests. Although these cookies and similar technologies can track your visits to other websites, they don't usually know who you are. Without these cookies, online advertisements you encounter will be less relevant to you and your interests.

Cookie Settings

U.S. Bank Europe DAC. Registered in Ireland – Number 418442..  Registered Office: Block F1, Cherrywood Business Park, Dublin 18, D18 W2X7, Ireland.
U.S. Bank Europe DAC, trading as Elavon Merchant Services, is regulated by the Central Bank of Ireland.
 
U.S. Bank Europe 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.
U.S. Bank Europe 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.

Most popular solutions

Additional solutions

Fusebox integration & options

Optional platform features

Documentation

North America

Europe

Regions

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 either deviceless payment authentication or verification of account. 


## Sample use cases 

Recurrent transactions such as TV subscriptions, utility bill payments, etc. In this case, the merchant wants to either perform a payment transaction (`messageCategory= 01`) to receive authentication data for each bill or a non-payment transaction (`messageCategory= 02`) to verify that a subscription user still has a valid form of payment.


:::::notice{note}

3D Secure 2.1 supports only scenarios related to a non-payment transaction i.e. the `messageCategory` must always be `02` but 3D Secure 2.2 supports both `messageCategory` = `01` and `02`.
:::::



## 3D Requestor-Initiated Workflows

The 3RI workflow diagrams show that the merchant's server sends the optional `/lookup` request to check the supported 3D Secure version. After receiving the `/lookup` response, they send the `/authenticate` request to the 3DS Server. The 3DS Server uses this data to create an authenticate request and sends it to the issuer (ACS). The authentication response can result in the following scenario: 

- In case of account confirmation (diagram1), the issuer validates the data sent in the request and sends the authentication response to the 3DS Server, which passes the response to the merchant's server.


::image{id="/content/dam/developer-portal-solutions/en-us/elavon/media/images/products/3dsecure2/3RIworkflow.png" alt="A diagram explaining the request and responses flow among the client and the servers involved in 3DS authentication of a transaction when the authentication request is initiated by a 3D Requestor and the cardholder is not challenged"}


## Prerequisites 

You must have the cardholder data stored in your server. The first transaction that the merchant used to store a cardholder's information for future use could be sent using one of the following integration option: 

- :magic-link[Direct API]{id="server-to-server-steps"}
- :magic-link[Web SDK]{id="websdk-overview"}
- Mobile SDKs (releasing soon)

But a subsequent merchant-initiated (3RI) transaction can be initiated by only using the direct API method i.e., :magic-link[sending the authenticate request directly]{id="sample-req-res"} to the 3DS Server. You cannot use the Web SDK or the Mobile SDKs to send a 3RI authentication request (i.e. `deviceChannel = 03`).


## 3D Secure 2 Authentication steps for each transaction 


### (Optional) Step 1: Send cardholder’s account number to verify support for 3D Secure 2 (`/3ds2/lookup`) 

Send the card holder’s card/account number to Elavon’s 3DS Server to:

- verify if the card used by the cardholder for the transaction supports 3D Secure 2

- retrieve key characteristics of the card used in the transaction such as the card BIN, scheme, brand, country, and currency where the card has been issued, if the card is a debit or a credit card, etc. The BIN is the first four, six, or more digits of the card number. The `/3ds2/lookup` request uses the BIN information to scan an internal repository of data to retrieve more details about the card being used. 

The BIN lookup parameters along with the fact the card supports 3DS 2 authentication can help you understand which version of the 3D Secure 2 the card supports. 

If you do not send the `/lookup` request and send the `/authenticate` (Step 3) request directly, the `/authenticate` response will return an error message if the issuer does not support the requested 3D Secure version. 

Use the following links for a sample `/lookup` request, response, and parameters description:

- :magic-link[/3ds2/lookup sample request and response]{id="sample-req-res"} 
- :magic-link[Description of /3ds2/lookup request and response parameters]{id="api-reference"}
- :magic-link[Test scenarios - Sample /3ds2/lookup scenarios]{id="test-information"}


### (Optional) Step 2: Verify the `/3ds2/lookup` response 

The 3DS Server uses the `ACS Start Protocol Version`, `ACS End Protocol Version`, `DS Start Protocol Version`, and `DS End Protocol Version` returned in the `/lookup` response to verify that the ACS and the DS support the 3DS protocol version used by the 3DS Server. It uses the `ACS Information Indicator` to identify the features that the account supports.

Verify the `/3ds2/lookup` response and use the scenarios in table 1 to help you decide the next step.


#### Table 1: /lookup response scenarios

| Scenario | Next Step |
| -------- | --------- |
| **Scenario 1:** If the `/3ds2/lookup` response does not have the version fields (`dsStartProtocolVersion`, `dsEndProtocolVersion`, `acsStartProtocolVersion`, `acsEndProtocolVersion`) or the values of these fields are `1.0.2`, it means that the card number (PAN) does not support 3DS 2 authentication. | You cannot proceed with 3DS 2 authentication for this transaction. A merchant-initiated transaction is not a supported scenario if an `acctNumber` does not 3D Secure 2. |
| **Scenario 2:** If the `/3ds2/lookup` response contains the version fields (`dsStartProtocolVersion`, `dsEndProtocolVersion`, `acsStartProtocolVersion`, `acsEndProtocolVersion`) and their values are `2.1.0` | It means that the `acctNumber` and the issuer supports 3D Secure 2.1.0. Send an `/authenticate` request to the 3DS Server. See Step 3 for more details. |
| **Scenario 3:** If the `/3ds2/lookup` response contains the version fields (`dsStartProtocolVersion`, `dsEndProtocolVersion`, `acsStartProtocolVersion`, `acsEndProtocolVersion`) and their values are `2.2.0` | It means that the `acctNumber` and the issuer supports 3D Secure 2.2.0. Send an `/authenticate` request to the 3DS Server. See Step 3 for more details. |


### Step 3: Submit cardholder data to the 3DS Server to initiate the 3DS authentication process (`/3ds2/authenticate`) 

If the card used in the transaction supports 3D Secure 2, submit the required authentication information to Elavon’s 3DS Server. The 3DS Server in turn creates an authentication request and sends it to the ACS. 

Review table 2 to understand how these three fields in the `/authenticate` request help the 3DS Server to decide whether to follow 3DS 2.2 or 3DS 2.1 authentication flow for `deviceChannel = 03`: `messageVersion`, `clientStartProtocolVersion`, and `clientEndProtocolVersion`.


#### Table 2: 3DS Server Fallback Strategy

| messageVersion | clientStartProtocolVersion | clientEndProtocolVersion | 3DS Server Fallback Strategy |
|--------------- | -------------------------- | ------------------------ | ---------------------------- |
| 1.0.2 | 1.0.2 | 1.0.2 | Error. Not a supported scenario. |
| 1.0.2 | 1.0.2 | 2.1.0 or 2.2.0 | Error. Not a supported scenario. |
| 2.1.0 or 2.2.0 | 1.0.2 | 1.0.2 | Error. Not a supported scenario. |
| 2.1.0 | 1.0.2 | 2.1.0 or 2.2.0 | Check support for 3DS 2.1. If not supported, return an error. |
| 2.1.0 | 2.1.0 | 2.1.0 | Check support for 3DS 2.1. If not supported, return an error. |
| 2.1.0 | 2.1.0 | 2.2.0 | Check support for 3DS 2.1. If not supported, return an error. |
| 2.2.0 | 1.0.2 | 2.2.0 | Check support for 3DS 2.2 first. If not supported, check support for 3DS 2.1. If 3DS 2.1 is not supported, return an error. |
| 2.2.0 | 2.1.0 | 2.1.0 | Error response |
| 2.2.0 | 2.2.0 | 2.2.0 | Check support for 3DS 2.2. If not supported, return an error. |
| 2.2.0 | 2.1.0 | 2.2.0 | Check support for 3DS 2.2 first. If 3DS 2.2 is not supported, fall back to 3DS 2.1. If 3DS 2.1 is not supported, return an error. |

:::::notice{note}

- `messageVersion` is an optional field and if you do not manually specify a value in the authenticate request, the 3DS Server sets its default value to `2.1.0`.

- If the 3DS Server falls back the request to `2.1.0`, the issuer ignores all fields that are specific only to the 3D Secure `2.2.0`.

- The request will not fallback from `2.2.0` to `2.1.0` under following conditions: 

 - if you send a value specific to the `2.2.0` spec only in an existing field (a field that was present in the `2.1.0` spec as well). For example, if you set the field value of the `threeDSRequestorAuthenticationInd` field (present in both the `2.1.0` and the `2.2.0` spec) to `07`(billing agreement). Here the field value `07` is specific to `2.2.0` only. 

 - if you send a combination of fields values that are not applicable to the `2.1.0` spec. For example, if you set `deviceChannel=03` (3RI) and `messageCategory=01` (PA). 
:::::


Use the following links to refer to the `/authenticate`sample request, response, and parameters description.

- :magic-link[Sample request and response]{id="sample-req-res"}
- :magic-link[Description of request and response parameters]{id="api-reference"}
- :magic-link[Test scenarios - Sample /3ds2/authenticate scenarios]{id="test-information"}

To increase the chances of successful authentication, include information for all required and optional fields in the authentication request you send to the 3DS Server. However, do not send dummy data if you do not have data for an optional field.

### Step 4: Verify the 3DS authentication response from the 3DS Server 

Verify the value of the `transStatus` field in the `/3ds2/authenticate` response sent by the 3DS Server because it determines your next step. Review the information in table 3 to understand the next steps for each `transStatus` value. 


#### Table 3: Description of the transStatus field value in /authenticate response

| transStatus | Description | Liability shift | Next step | Example scenario |
| ----------- | ----------- | --------------- | --------- | ---------------- |
| `Y` | Issuer has authenticated the customer's data. You can use the `transStatus`, `authenticationValue`, and `eci` field values to authorize the transaction. The flow is considered frictionless and the 3DS processing will end at this step. | Card issuer | Merchant can use the `eci` and `authenticationValue` in the authentication response to proceed to card authorization. | You get this value in case of a successful authentication or a frictionless flow. |
| `A` | Issuer has not authenticated the transaction, but a proof of authentication attempt (`authenticationValue`) was generated. You can use the `transStatus`, `authenticationValue`, and `eci` field values to authorize the transaction. The 3DS processing will end at this step. | Card issuer | Merchant can use the `eci` and `authenticationValue` in the authentication response to proceed to card authorization. | You get this value in case of an attempted authentication. |
| `I` | Issuer acknowledges that the request was sent for informational purposes only and did not need a challenge. | Not applicable | Merchant should store the `authenticationValue` and `eci` field values, if included in the response. | You get this value when you send the request only for information and do not request for authentication. To indicate this in the authentication request, you sent a value of `05, 06, or 07` in the `threeDSRequestorChallengeInd` field. |
| `N` | Issuer has not authenticated the transaction, or could not verify the account, or denied the transaction. | No liability shift | If you get this value, verify the value in the `transStatusReason` field. Based on the value received, you can do either of the following: <ul><li>Try to send the authentication request again</li><li>Request the customer for another form of payment</li><li>Decline the transaction</li><li>Move forward with authorization at your own risk</li></ul> | You get this value in case of authentication processing errors such as when the cardholder fails all challenges to prove cardholder identity. |
| `U` | Issuer has not authenticated the transaction or verified the account due to a technical or another problem. | No liability shift | If you get this value, verify the value in the `transStatusReason` field. Based on the value received, you can do either of the following: <ul><li>Try to send the authentication request again</li><li>Request the customer for another form of payment</li><li>Decline the transaction</li><li>Move forward with authorization at your own risk</li></ul> | You get this value in case of technical errors such as when the ACS is not reachable. |
| `R` | Issuer is rejecting the authentication or account verification and requesting that authorization not be attempted. | No liability shift | If you get this value, verify the value in the `transStatusReason` field. Based on the value received, you can do either of the following: <ul><li>Try to send the authentication request again</li><li>Request the customer for another form of payment</li><li>Decline the transaction</li><li>Move forward with authorization at your own risk</li></ul> | You get this value in case the issuer rejects authentication and requests that authorization should not be attempted. |

:::::notice{note}

The liability shift is only for disputed transactions or chargebacks. Use the following information related to liability shift and next steps for merchants as a reference. These can differ for each card scheme and each issuer might have different criteria for liability shift.
:::::

Merchant-initiated (3RI) transactions

Alliance Offers

Data as a Service

Invitation to Apply

Accounts

Bank Holidays

Card Activation

Card Controls

Challenge-Widget

Commercial Credit Cards

Commercial Statements

Credit Card Account Details

Credit Card Accounts Overview

Credit Card Alerts

Credit Card Application Status

Credit Card APRs

Credit Card Balance Transfers

Credit Card Disputes

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: Dashboard

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

Card as a Service API

Core Banking API

Money Movement API

Reference API

Access Online Transactions

Account Transfers

Account Validation

ACH Originations

Bank Information

Card as a Service

Check Payables

Corporate Account Information

Corporate Account Information 3LO

Corporate Credit Cards

Corporate Onboarding

Corporate Statements

Custody

Data Toolbox

Data Toolbox - Accounts

Data Toolbox - Documents

Data Toolbox - Transactions

Debit Card Phone Number Lookup

Disbursements via Zelle®

U.S. Bank Flexible Capital Platform

Freight Payment Customer Profiles

Freight Payment Transactions

Incoming Webhooks

Instant Payments

Investment Accounting

PaySmart

Payee Choice

Payee Token+

Personal Loans

Positive Pay

Push to Card

Receivables

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

Fraud scoring

Integration guide

API reference

Getting Started

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