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.

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 Examples

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

**Use Case - 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.
:::::


## Lodging Flow Considerations

Lodging transactions generally follow the flow below:

1. An initial authorization with the reservation (card not present).
2. An authorization at check-in (card present).
3. An incremental authorization if the cardholder extends their stay (card not present).
4. A prior authorization when the cardholder has checked out (card not present).
5. Settlement.

The Card Account field (0003) should contain either a manually entered PAN or the Fusebox token for card not present transactions.

Implementation Considerations

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

Fusebox Overview

Getting Started

Transaction Flow

API Message Format

Transaction Sequencing

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)

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

Gift and Stored Value Card Examples

Online Debit Transactions

Online Debit API Fields

Online Debit Examples

Private Label Cards

Private Label Transactions

Private Label API Fields

Private Label Examples

Health Savings Account Cards

HSA Support

Fusebox and Simplify HSA Card Support

HSA Card API Fields

Puerto Rico

E4 Support

API Fields

EBT Transactions

IVU Transactions