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

This page has conceptual information on the following 3D Secure 2-specific terminologies:

## 3D Secure 2 Message categories 
Message category (`messageCategory`) helps the merchant and the issuer to identify data elements that should be included in a message based on the type of transaction. You send the `messageCategory` field value to the issuer in the `/authenticate` request. This field value is one of the key factors that decide the flow of the messages and the response returned by the issuer.

| Payment Authentication (PA) | Non-Payment Authentication (NPA) |
| --------------------------- | -------------------------------- |
| Used for transactions that involve a payment. | Used for transactions that involve verification of account based on data provided by a cardholder at the time of account creation or account information changes. |
| Cardholder authentication during an e-commerce transaction. | Identity verification and account confirmation. An example use case could be to add a card to a merchant’s website or modify stored cardholder information. |
| Code used in the requests to specify a PA is `messageCategory = 01` | Code used in the requests to specify an NPA is `messageCategory = 02` |
| If a transaction is deemed authenticated (`Transaction Status = Y or A`), the ACS generates the ECI value (`eci`) and Authentication Value (`authenticationValue`) and includes them in the ARes message. | If a transaction is deemed authenticated (`Transaction Status = Y or A`), the ACS may: <ul><li>Generate the ECI value (`eci`) and Authentication Value (`autheticationValue`) and include them in the ARes message.</li><li>Assign an appropriate Transaction Status Reason code (`transStatusReason`) and include them in the ARes message. This is conditional as defined by the DS.</li></ul> |

## Device channel types 
Device channel (`deviceChannel`) indicates the channel from which the transaction originated. In the `/authenticate` request, you can be set to either:

- App-based (01-APP)
- Browser-based (02-BRW)
- 3DS Requestor Initiated (03-3RI)

The required fields for each device channel might be different. Therefore, to avoid an error, you must send the appropriate `deviceChannel` in the request.

| Browser-based | App-based | 3DS Requestor Initiated (3RI) |
| ------------- | --------- | ----------------------------- |
| `deviceChannel = 02` | `deviceChannel = 01` | `deviceChannel = 03` |
| Use this when you send the `/authenticate` request either directly through your server or through the 3DS Web SDK | Use this when you send the `/authenticate` request through the mobile SDK integrated in your app | Use this when you send the `/authenticate` request for a merchant-initiated transaction (3RI) |
| Includes cardholder account information and transaction details about the payment. | Includes cardholder account information and transaction details about the payment. | Includes cardholder account information. The transaction amount could vary for each recurring transaction. |
| The consumer device used for the transaction must support a browser. | The merchant app must be embedded with the 3DS SDK. | The merchant's server must have the cardholder details already on file. |
| Transaction initiated by the cardholder through the merchant's website. | Transaction initiated by the cardholder through the merchant's app. | A transaction is initiated by the merchant's server for either deviceless payment authentication or verification of account. |
| Supports all `transStatus` | Supports all `transStatus` | Does not support `transStatus = C` i.e., a challenge because the cardholder is not present. Challenge can happen only in the form of decoupled authentication (`transStatus = D`). |
| In case of a challenge (`transStatus = C`), the CReq message is sent by the 3DS Server. There is only one CReq message per challenge. | In case of a challenge (`transStatus = C`), the CReq message is sent by the 3DS SDK. There are two or more CReq messages per challenge as multiple back-and-forth attempts between the ACS and the Cardholder may be required to complete the authentication. | CReq and CRes messages are not part of a 3RI authentication. |
| Uses the 3DS Method to gather browser information/device details and the issuer's ACS provides an HTML to the browser to display the UI to the cardholder in case of a challenge. | Challenge flows are message-based, not HTML. Challenge UI shown to the cardholder by the SDK. | Challenge happens only in the form of decoupled authentication (`transStatus = D`). |
| The CRes indicates the result of the cardholder authentication. | The CRes may indicate the result of the Cardholder authentication or signal that further Cardholder interaction is required to complete the authentication. | CReq and CRes messages are not part of a 3RI authentication. |

## Challenge flow and Decoupled authentication 

Based on the information sent in the `/authenticate` request, the issuer can decide to challenge the cardholder's identity. In this case, the `/authenticate` response will return one of these challenge mechanism the issuer will use.

| Challenge Flow | Decoupled Authentication |
| -------------- | ------------------------ |
| `transStatus = C` | `transStatus = D` |
| Supported only for `deviceChannel` = `01` (App) or `02` (Browser) | Elavon’s 3D Secure solution supports decoupled authentication only for `deviceChannel = 02` (only the direct integration option) or `deviceChannel = 03` (3RI). |
| Supported for both `messageVersion` = `2.1.0` or `2.2.0` | Supported only for `messageVersion = 2.2.0` |
| Cannot be used in Mail Order/Telephone Order (MOTO) transactions, the cardholder is off session, or 3RI transactions. | Supports almost all transaction types unless the issuer does not support decoupled authentication. |
| The challenge happens as part of the payment process while the transaction authentication is in progress. Transaction is authenticated or declined as soon as the merchant website/app receives the final authentication result. | Challenge happens outside the payment/verification process. Merchant (website/app) notifies the cardholder as soon as it gets a notification that the issuer will use a decoupled authentication to challenge the cardholder. It waits for the final authentication result from the issuer via the 3DS Server. |
| Cardholder completes the challenge within a maximum time of 10 minutes. The time to complete a challenge and the number of tries is defined by the issuer. | Cardholder completes the challenge within a maximum time of 7 days depending on the maximum time (`threeDSRequestorDecMaxTime`) specified by the merchant in the authentication request. |
| No special setup required on your environment | Before you indicate the support for decoupled authentication, you must set up an endpoint that will receive all webhook event notifications from the 3DS Server and call Elavon support to add the endpoint to the list of allowed URLs. |
| Merchant can specify the challenge preference through this field in the AReq. This is an optional field. If this field is missing in the AReq, the issuer interprets the value as no preference. <ul><li>3DS Requestor Challenge Indicator (`threeDSRequestorChallengeInd`)</li></ul> | Merchant must send these two fields in the AReq to let the issuer know that the merchant supports decoupled authentication: <ul><li> `threeDSRequestorDecReqInd = Y`</li><li>`threeDSRequestorDecMaxTime` (maximum time within which the cardholder must complete the challenge)</li></ul> `threeDSRequestorDecReqInd` is an optional field. If this field is missing in the AReq, the issuer interprets the value as do not use decoupled authentication. |
| From the data received in the AReq, the issuer checks whether the Consumer Device is supported for a challenge scenario. If the device is not supported, the ACS returns an ARes message with a `Transaction Status = U` and `Transaction Status Reason code = 03`. | The consumer device that initiated the transaction does not need to be supported when the ACS has alternative approaches to authenticating the cardholder. |
| If the issuer decides to challenge the cardholder, it must return the following fields in the ARes: <ul><li>`acsURL`, a fully qualified URL of the ACS to be used for the challenge (only for `deviceChannel = 02`)</li><li>`creq`, a base64 encoded challenge request message (only for `deviceChannel = 02`)</li><li>`acsChallengeMandated = Y`</li><li>`acsRenderingType` (only for `deviceChannel = 01`)</li><li>`acsSignedContent` (only for `deviceChannel = 01`)</li><li>`authenticationType`</li></ul> | If the issuer uses decoupled authentication, it must return the following fields in the ARes: <ul><li>`acsDecConInd = Y`</li><li>`acsChallengeMandated = Y`</li><li>`authenticationType`</li><li>`cardholderInfo`</li></ul> |
| The Challenge flow includes CReq and CRes messages. | Challenge request (CReq) and response (CRes) messages are not used and the issuer notifies the final result to the 3DS Server through the RReq. |

:::::notice{note}

This release does not support the decoupled authentication feature that is supported in the EMVco 3DS 2.2 specification. 
:::::

3D Secure 2 Concepts

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 Glossary