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 section provides recommendations and examples of how transactions are handled within the lodging industry and how they impact qualifying for the most favorable merchant interchange rates and fees. 


## Reservations

Most hotels accept guest reservations online or by phone. To verify that the cardholder and credit card are valid, use the following transactions:

- Account Verification (Auth Only 01) - We recommend processing an Authorization Only for $0.00. An Account Verification for $1 can be processed (if a $1.00 Authorization is performed), as long as a Full Authorization Reversal (61) is submitted immediately afterwards. **Note:** Using $1.00 value for verification is not a best practice, and is subject to misuse of authorization fees.

- Reference Number (Field 0007) must be unique.

- If a Card Verification or Authorization Only transaction is performed during the reservation, the Program Code (Field 0305) in the input request must have a value of 1. This transaction can be used to obtain a token or unique ID, but cannot be used as the first authorization in a transaction lifecycle or settled at any point.

:::::notice{note}
Tokens can be reused for financial transactions when using token vault in Fusebox.
:::::


For example, if the card is verified using Auth Only (01) for $0.00 (zero-dollar authorization), the cardholder's account information is verified, it does not negatively impact a cardholder's open to buy, the AVS and CCV2/CVC2/CID are validated, and a token or unique ID can be requested during this transaction. 

American Express and Discover may require the Billing ZIP/Postal Code and CCV2/CVC2/CID as there is potential for a transaction fee assessment.

## Advance deposits or Prepayments

During the reservation process, some hotels require or allow guests to prepay an amount toward their final bill. Support for advance deposits or prepayments involve using one of the following transactions:

- Authorization Only (01) or a Prior Authorized Sale (07)

### Additional requirements

- An Advance Deposit / Prepayment transaction should not exceed the cost of a 14-night stay.

- Arrival Date (API 0303) must have the (future) reservation arrival date.

- Program Code (API 0305) must have a value of 3 (Advance Deposit).

For example, if an Advance Deposit in the amount of $100 is made using Auth Only (01) followed by Prior Auth (07), the cardholder's account information is verified, it does not negatively impact a cardholder's open to buy, the AVS and CCV2/CVC2/CID are validated, and a token or unique ID can be requested during this transaction. American Express and Discover may require the Billing ZIP/Postal Code and CCV2/CVC2/CID. There is also a potential for a transaction fee assessment.

## Check-in

Your PMS application initiates an Authorization Only (01) when a guest arrives at the hotel. Even if the account number, token, or unique ID is available from a reservation, the credit card’s magnetic stripe should be read as part of the guest check-in process. This transaction is acceptable for a credit card. However, a PIN Debit or EMV transaction may require a one-part Sale (02) transaction with PIN entry. 
For information regarding PIN Debit or EMV, refer to :magic-link[EMV Transactions]{id="emv-transactions"}

Ensure that the Reference Number (API 0007) created at check-in is unique. Do not use the same reference number that was generated for the reservation transaction.

:::::notice{note}
Fusebox does not support PIN debit in Lodging.
:::::


### Additional requirements

- The amount authorized should not exceed the estimated cost of a 14-night stay.
- Program Code (API 0305) must have a value of 1 (default).
- Any additional authorization amount should not exceed 15% more than the total of the room charges. Some hotels do this routinely to cover any incidentals a guest may incur. 

:::::notice{note}
Use of a customer’s co-branded MasterCard or VISA debit card for a hotel stay may result in funds being locked in their checking or savings account. We suggest that the guest agent validate if the card is a credit card or a debit card, and inform the customer of this possibility.
:::::


For example, if a Folio is opened in the amount of $100 is made using Auth Only (01), the cardholder's account information is verified, it is the ideal interchange qualification, and a token or unique ID can be requested during this transaction. There is potential for a transaction fee assessment.

## Authorization maintenance

Fusebox supports the following transaction types when making any adjustments between the total amount authorized and the anticipated final amount:

- Full Authorization Reversal (61)

- Incremental Authorization (75)

- Partial Authorization Reversal (76)

When the estimated charge increases because the guest extends their stay or adds charges to the room such as a dinner, an Incremental Authorization should be submitted to ensure that the total authorized amount is close to the final payment amount. If an Incremental Authorization is not supported due to the region or card type of the transaction, Fusebox will automatically attempt an Additional Authorization (01).

If the guest checks out earlier than expected or charges were over-estimated, a Partial Authorization Reversal should be submitted to reduce the total amount authorized and bring it within tolerance of the final amount.

Incremental and Reversal transactions are not supported on all card types in all regions. However, these transactions should always be attempted, and the results will be indicated in the **final four** output response fields (two of the final four API fields contain TPP responses (1004 and 1009), the other two contain responses from Fusebox (1003 and 1010)).

For example, if an Incremental Authorization (75) is performed for the $100 (for a total authorization of $200), the cardholder's account information is verified and a token or unique ID can be requested during this transaction. 

:::::notice{note}
There is potential for a transaction fee assessment, and this may be considered an Additional Authorization for some card products and regions.
:::::


## Checkout

A guest account is closed when the guest checks out. At checkout, the final payment amount is entered into the PMS application, which generates the Prior Authorized Sale (07) to end the transaction life cycle. This transaction culminates all previous authorizations performed on the guest’s credit card.

:::::notice{important}
Elavon does not recommend padding Reference Number field (API 0007) with leading zeros. Should you choose to do so, be sure to store the value in your system as a String instead of an Integer. This will eliminate any potential discrepancies in how this field is presented in two-part transactions, and the chance of downgrades or fees is greatly reduced.
:::::


Fusebox is automatically configured for Auto-Authorize Difference for lodging merchants. Your PMS application should periodically compare the total amount authorized on the folio against the anticipated final amount and obtain any incremental authorizations. If incremental authorizations are not obtained until the guest checks out, the merchant is placed at risk because there may not be sufficient open-to-buy available for the additional charges.

If the application needs to reverse or cancel an outstanding authorization, the PMS needs to submit a Full Authorization Reversal (61) for the total amount.

:::::notice{note}
The Departure Date (API 0304) must be the date that the customer is checking out of the hotel. It should always be the current/present date.
:::::


### Check-out scenarios

1. If the final amount is greater than 10% to 15% of the total authorized amount, the folio is adjusted or corrected using a Partial Authorization Reversal (76) transaction. The amount (API 0002) shows the final amount, and the approval code is the same as an Authorization Only transaction. The open-to-buy is returned to the cardholder as soon as possible, if supported. 

2. If the authorization estimate exceeds the final amount, the folio is closed using Prior Authorization (07).  The amount (API 0002) shows the final amount, and the approval code is the same as an Authorization Only transaction. If the Authorization Tolerance setting is enabled, a Partial Authorization Reversal (76) is automatically performed to bring the final transaction within allowed authorization tolerance at the time of Settlement. This is an ideal interchange qualification, an ideal authorization-related chargeback protection, and results in economical transaction fees. 

## No Shows 

Some hotels charge one night’s lodging for guests who fail to check in on a guaranteed reservation. The guest may successfully dispute this charge, referred to as a No Show charge.

When the reservation is made, the hotel must obtain the account number, expiration date, and name on the guest’s credit card. The hotel must inform the guest of the hotel’s exact address, the cancellation policy for guaranteed reservations, and the charge that will occur if they do not cancel or check in. A reservation confirmation must be mailed or emailed to the guest.

If a Card Verification (Authorization Only) transaction is performed during the reservation, the Program Code (API 0305) in the input request must have a value of 1.

If the guest fails to cancel or check in (as a no show), a payment for one night’s lodging, plus the applicable taxes must be posted and settled within two days. When the Sale or Authorization Only followed by Prior Authorized Sale is created for this payment, the Program Code (API 0305) in the input request must have a value of 2 (Assured Reservation No Show). If the proper value is not entered in the Program Code field, the transaction will be charged back to the hotel if the guest disputes it.

A credit card receipt must be provided to the cardholder. The receipt must meet the requirements outlined for any credit card receipt, and the words "No Show" should be printed on the signature line.

:::::notice{important}
It is recommended to create a minimum of a 2 (two) second delay between the processing of the Authorization Only (01) and the Prior Authorized Sale (07).
:::::


For example, if a folio is opened and then closed using Authorization Only (01), the cardholder account information is verified, and it is an ideal interchange qualification. However, there is the potential for a transaction fee to be assessed.

If the folio is closed using Prior Authorization Sale (07), the cardholder account information is verified, and it is an ideal interchange qualification. There is no potential for a transaction fee being assessed.

## Delayed charges

Delayed charges include any charges added to a guest’s account after checkout and after the receipt has been signed. Delayed charges can be assessed for items charged to the room (or for which the guest was responsible) that were not included in the Folio at the time the guest checked out.

This transaction should be submitted as an Authorization Only (01) followed by Prior Authorized Sale (07). In the input request, the Program Code (API 0305) should have a value of 4 (delayed charge). The Extra Charges Amount (API 0311) and Extra Charges Reason Code (API 0312) must also be supplied to describe the charge.

For example, if a folio is opened and then closed using Authorization Only (01), the cardholder account information is verified. However, there is the potential for a transaction fee to be assessed.

If the folio is closed using Prior Authorization Sale (07), the cardholder account information is verified, and there is no potential for a transaction fee being assessed.

## Express services

Some hotels offer their guests express services, such as express check-in and express checkout. To handle these services, you may need to incorporate additional functionality into the PMS application and the hotel’s procedures.

Express check-in services usually involve a speedy method for getting guests into their rooms. Even if the guest’s credit card account number was obtained during reservations, the hotel should obtain the magnetic stripe information from the guest’s credit card prior to issuing the room key.

Express or priority checkout services usually involve allowing a guest to check out without stopping at the front desk. When a hotel supports this service, at some point during the guest’s stay the guest’s signature and mailing address must be obtained from a registration card or an express checkout agreement that is kept on file at the hotel.

When the payment is posted and settled, a Prior Authorized Sale is created. The Program Code (API 0305) in the input request should have a value of one 1 (default).

:::::notice{note}
The Departure Date (API 0304) must be the current date. 
:::::


## Extended stay
Most hotels have a policy for how frequently a guest must make a payment on their account. Some hotels request a payment every seven days. An Authorization Only (01) and a Prior Authorized Sale (07) must be processed for the number of days according to the hotel’s policy on extended stay.

According to payment service industry guidelines, the recommended maximum number of days that an account can be authorized is 14 days. Elavon recommends that the PMS application be designed with 14 days as the maximum.

Best practices

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

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