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

Your implementation must address the following business criteria specific to the acceptance of EMV cards:
- An EMV-certified PIN pad terminal capable of accepting EMV chip-enabled cards.
- A payment application that integrates with the PIN pad EMV certified kernel and Fusebox. These will be Level 3 EMV certified. Neither the payment application nor Fusebox can be EMV certified to a TPP alone.
- Ability to update EMV keys and EMV parameters once the PIN pad terminal is on site.
- Ability to update the PIN pad terminal’s applications once on site. Ex.: new EMV kernel, new terminal libraries or OS updates, new payment application.

## EMV use cases

While [EMVCo](https://www.emvco.com) has defined standards for processing EMV transactions, there are slight differences between the card brands, contact vs contactless EMV, and industry considerations. These differences must be supported in the payment application and are tested in the brand Level 3 EMV certification process.

Additionally, "contactless" can refer to either an RFID-enabled EMV ICC chip card or a mobile wallet application. These use cases address some of these differences.

### TIP in the EMV flow

One of the basic changes to the EMV vs the magnetic stripe flow is that the total amount of the transaction must be known early in the process.

Discussion with the TPP regarding where TIP may occur in the transaction life cycle is recommended before completion of the payment application design. It is important to note that only supporting a “No PIN” CVM may move the Lost / Stolen liability to the merchant based on brand requirements.

### Cashback in the EMV transaction flow

With EMV, cashback is no longer solely a debit or gift card option since an issuer may add that feature to a credit card.

### No debit / credit prompting and application choice prompting

An EMV ICC chip may support more than one payment application. If the ‘Application Selection’ process returns multiple supported applications, the payment application can either display the list of applications for cardholder selection or perform candidate list manipulation to allow merchant-driven choice.

### United States EMV debit network options

Check with your TPP for information about which debit networks they support for EMV at the time of your integration project.

There is agreement on a Common U.S. Debit Application Identifier (AID) and both Visa and MasterCard have AIDs to support those networks. A chip can be set up to support more than one AID.

The Visa and MasterCard debit AIDs are as follows:

- Visa (e.g., Visa Credit or Visa Debit):
A000000003 1010
- Visa Electron: A000000003 2010
- Visa Interlink: A000000003 3010
- PLUS: A000000003 8010
- Visa and MasterCard US Common Debit: A000000098 0840
- Maestro (for MasterCard PIN Debit): A000000004 2203

### United States Debit EMV cardholder verification methods

Check with your TPP prior to designing your payment application to ensure which of the following elements are supported for U.S. debit.

- **Offline PIN** - Not supported for debit in the U.S. The cardholder-entered PIN is sent either in plain text or encrypted to be verified by the ICC chip (Offline Issuer).
- **Online PIN** - The primary customer verification method (CVM) used in single message debit transactions. The cardholder-entered PIN is encrypted and sent online to be verified by the issuer.
- **Signature** - Some brands/schemes may support signature as the CVM for transactions under $50. Check with your TPP to ensure they support this method during your design phase.
- **No CVM Required** - An option for low-value transactions. Check with your TPP to ensure they support this method during your design phase.
- **Fail CVM Processing** - A catch-all option to ensure CVM processing is deemed to have failed.

### EMV parameter selectable kernel configuration alternatives

Every EMV ICC chip contains a list of approved CVM methods the issuer wants to support. The EMV certified PIN pad terminal also has a list of CVM methods the TPP wishes to support. In most implementations, the EMV certified PIN pad terminals support all CVMs, so they can support all EMV cards.

## Use case example

### No PIN CVM list option example

For restaurants that want the server to present the check to the cardholder, the cardholder may enter the tip amount and provide their card. This is possible if the PIN is not an allowable CVM. Once the server picks up the check with the tip and card, they can run the transaction at the POS in another location and bring the receipt back to obtain the cardholder signature. This is the recommended approach for this particular environment.

The payment application designers should discuss their EMV kernel configuration options and the EMV certification impacts with their TPP prior to choosing to support this option.

### No CVM option example

This option should only be considered for those merchants with low value transactions such as a quick serve restaurant. The payment application should discuss this configuration option and the EMV certification impacts with their TPP prior to designing a solution to support it.

## End of transaction flow considerations

There are two options available for a payment application after it has received either the TC cryptogram from the 2nd Generate command or the response from Fusebox on the reversal for an AAC cryptogram.

- Option 1:

 1. Send the completed response transaction to the POS.
 2. Send the command(s) to the PIN pad to display the transaction status message and prompt the cardholder to retrieve their card from the chip reader.

- Option 2:

 1. Send the command(s) to the PIN pad to display the transaction status message and prompt the cardholder to retrieve their card from the chip reader.
 2. Send the completed response transaction to the POS for receipt printing.

 This option can be even more secure by not sending the response to the POS for receipt printing until the PIN pad detects the card has been removed.

## ICC chip decline of an online-approved transaction

We strongly recommend the payment application perform a reversal prior to returning the response message to the POS and printing the receipts. If using Simplify, it will perform this function. If the payment application sends the decline back to the POS and relies on the POS to perform the reversal, the POS is now in scope to be included as a component of the Level 3 EMV certification. Therefore, any changes to the POS system could require a recertification effort.

## Card removed early

The contact EMV protocol requires the card remain in the card reader slot until the transaction is completed. If the card is removed before the payment application prompt, the payment application must reverse the transaction and start again.

## Communication failure / Time-out processing

All debit transactions are required to go online or be declined. There are two methods to continue a transaction if a communication failure with the issuing host occurs: EMV Offline Authorization and Merchant Stand-In.

## EMV offline authorization

The following details how to support EMV offline authorizations for those TPPs and card brands that support it.

**EMV parameter settings:**

- For each card brand, the EMV floor limit must be set to a value above zero and less than or equal to the card brand's EMV floor limit.

- EMV Random Selection values must be set to randomly go online. These are the recommended values, but check with your TPP EMV parameters as they may differ:
- Target Percentage to be used for Random Selection - 99%.
- Maximum Target Percentage to be used for Biased Random Selection – 99%.
- Threshold Value for Biased Random Selection = 0.

### EMV offline transaction steps

1. Attempt to send the transaction online.
2. If a timeout or communication failure to the issuer response is returned, perform the 2nd Generate AC and request a TC cryptogram.
3. Set the Authorization Response Code, Tag 8A, to ‘Y1’, if the chip approves it. The card’s final decision is reflected in the Cryptogram Information Data and not in the Authorization Response Code.
4. The POS sends the transaction to Fusebox prior to settlement as it would a Voice Authorized transaction.

The payment application should check if the TPP supports any form of EMV offline authorization.

**Merchant stand-in** 
If Merchant stand-in is supported by the TPP and the merchant is requesting it, check the rules of the merchant’s TPP.

**Fallback** When the payment application receives an error code from the EMV kernel, the payment application may “fallback” to normal magstripe processing rules. A fallback allows the transaction to continue in a less secure manner, bypassing the security features of EMV, but not shifting liability to the merchant as long as it is done properly.

:::::notice{important}
The payment application should know what error codes an EMV kernel can return and determine when to allow fallback. If the error code indicates the application is blocked or the card is blocked, the payment application must terminate the transaction and not allow fallback.
:::::

Implementation considerations

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

Fusebox overview

Getting started

Transaction flow

Transaction sequencing

API message format

Reconciliation

Settlements

Transaction types

Authorization Only (01)

Sale Transaction (02)

Prior-Authorized Sale (07)

Return (09)

Void Sale (11)

Batch Close (13)

Batch Create and Inquiry (14)

Void Return (17)

Transaction Inquiry (22)

Token Request (37)

Full Authorization Reversal (61)

Heartbeat (73)

Incremental Authorization (75)

Partial Authorization Reversal (76)

Concepts

Tokenization

Tokenization introduction

Tokenization API fields

Tokenization scenarios

Example transactions

Error scenarios

Retail

Retail scenarios

Retail API fields

Retail examples

Lodging

Lodging transactions

Lodging API fields

Lodging examples

Credential on file transactions

Best practices

Software conversions

Restaurant

Restaurant transactions

Restaurant API fields

Restaurant examples

Restaurant credential on file transactions

Restaurant receipts

MOTO and eCommerce

eCommerce transactions

MOTO and eCommerce API fields

Ecommerce examples

Direct marketing examples

eCommerce credential on file transactions

EMV transactions

Certification

EMV API fields

EMV Public Cap Keys, parameters, and reports

Sample files

EMV receipts

EMV integration samples

API-based settlement

Settlement transactions

API-based settlement fields

API-based settlement examples

Check payment

Check transactions

Check API fields

Check payment examples

DCC transactions

DCC transaction flows

DCC API fields

DCC examples

DCC receipt requirements

DCC certification process

Gift and stored value cards

Gift and stored value card transactions

Gift and stored value card API fields