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

Lodging integrations use the following transaction types:
  

 ## Transaction type 

:magic-link[Auth Only (Type 01)]{id="authorization-only-md"}  
:magic-link[Prior-Authorized Sale (Type 07)]{id="prior-authorized-sale-md"}  
:magic-link[Return (Type 09)]{id="return-md"}  
:magic-link[Void Return (Type 17)]{id="void-return-md"}  
:magic-link[Transaction Inquiry (Type 22)]{id="transaction-inquiry-md"}  
:magic-link[Full Authorization Reversal (Type 61)]{id="full-auth-reversal-md"}  
:magic-link[Incremental Authorization (Type 75)]{id="incremental-authorization-md"}  
:magic-link[Partial Authorization Reversal (Type 76)]{id="partial-authorization-reversal-md"}  


## Industry requirements

The following regulations apply to the lodging industry.


### Amount tolerance

  

The acceptable tolerance (difference) between the total amount authorized and the final amount is between 10 and 15 percent depending on the card product and region. If the total amount authorized and the final amount is different (out of tolerance), the transaction is not in compliance with industry requirements. Elavon offers options to lodging customers to ensure that transactions are submitted for settlement within acceptable tolerance parameters.

  

### Authorization best practices

The Card Associations require that the total amount authorized not be less than or exceed 10 to 15 percent of the estimated final transaction amount. This requirement is intended to aid in the management of a cardholder's open to buy.

When a guest checks in, the authorization amount is normally based on the anticipated length of stay, room rate, applicable taxes, service charge rates, and an estimate of any ancillary charges.

As part of the end-of-day (EOD) or night audit process, when a guest extends the length of stay, or has spent more during the stay than was anticipated, the PMS application is used to obtain any additional authorization required to cover the difference between the total amount previously authorized and the anticipated final amount on the folio. The difference in authorization amount must be reasonable while the guest is in resident. Hotels that *over-authorize* a guest’s card may limit the cardholder’s ability to use the card for other purchases.

  

 ### Incremental Authorization (75)


In the event that the amount authorized is not enough to be within tolerance during the guest stay or at checkout, the PMS can initiate an Incremental Authorization (Tran Type 75) to increase the authorized amount from the original authorization.

  

:::notice{title="note"}
Not all TPPs support an Incremental Authorization transaction. Internally, Fusebox may change the transaction to an Authorization Only (often called Additional Authorization), which is common in regions outside of the United States.
:::
  
### Partial Authorization Reversal (76)

In the event that the total amount authorized exceeds the final transaction amount (plus 10 to 15 percent), a Partial Authorization Reversal (Tran Type 76) is required to comply with the proper qualification requirements. This transaction can be performed by the PMS prior to submitting the final transaction as a Prior Authorized Sale (Tran Type 07) or it can be performed by Fusebox at the time of settlement.

  
The timing of a Partial Authorization Reversal is important to restore the open-to-buy to the cardholders account. In most cases, a Partial Authorization Reversal is processed in real-time to the TPP when presented by the PMS prior to the Prior Authorized Sale. If the Prior Authorized Sale is presented by the PMS with an amount outside of the tolerance, the Partial Authorization Reversal will not be performed by Fusebox until the settlement is processed to the TPP.

  
Not all card products, regions and issuers support a Partial Authorization Reversal at this time, but all should be attempted. The result of the Partial Authorization Reversal will be communicated to the POS.

  
Before a Full Authorization Reversal (Tran Type 61) became available, it was common practice to use the Partial Authorization Reversal (76) to remove all but $1.00 of the open-to-buy. You must migrate this functionality to the Full Authorization Reversal (61) to avoid potential Misuse of Authorization fees.

  
### Full Authorization Reversal (61)

  
In the event that a cardholder no longer wants to pay with a card the PMS has already authorized, the entire open-to-buy must be restored. A Full Authorization Reversal (61) can be performed on an open authorization to reverse it and return the open-to-buy to the cardholder. This transaction should be performed on all card types at the point where the authorization is not going to be settled. 

Common reasons to do this are:
- Wrong card was presented for authorization.
- Customer wants to pay with another card at checkout.
- Customer put a card on file for incidentals and there are no charges.
  

:::notice{title="note"}
Not all card products, regions, and issuers support a Full Authorization Reversal at this time, but all should be attempted. The result of the Full Authorization Reversal will be communicated to the POS.
:::

  

### Magnetic stripe data
  
Full, unaltered magnetic stripe data (Track I or II) should be used when available for the authorization request. Card presence is a major factor in chargeback rights of the merchant. Transactions that are not card present are most commonly Advance Reservations / Deposits, Reservation No Shows, and late charges.
  
If magnetic stripe data is not presented in the authorization request, chargebacks and disputes can occur. It is important to ensure the correct transaction data is presented to defend against chargebacks.

  
:::notice{title="note"}
For the lodging industry, some card association brands may offer the same interchange rates for card present and card not present, whether the card information is manually entered or swiped, as long as the correct data elements are presented.
:::

  

### Timeliness presentation

The number of days between the final transaction date and the settlement date cannot be more than two processing days. A transaction is not in compliance with industry requirements if it cannot be settled within this timeframe.

 
### Authorizations for extended stays
Each card issuer has a maximum number of days the amount authorized can be held. **Note:** Elavon recommends using 14 days as the maximum time for all credit cards.
 

### Transaction date

The final transaction date must be the same as the Checkout Date (Field 0304) except for the following scenarios:
- No Show
- Advance Deposit
- Delayed Charge

 

Lodging 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

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

Implementation considerations

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