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

## Transaction types

Below is a list of the transaction types used in restaurant scenarios.

- :magic-link[Authorization Only (Type 01)]{id="authorization-only-md"}
- :magic-link[Sale (Type 02)]{id="sale-transaction-md"}
- :magic-link[Prior-Authorized Sale (Type 07)]{id="prior-authorized-sale-md"}  
- :magic-link[Return (Type 09)]{id="return-md"}
- :magic-link[Void Sale (Type 11)]{id="void-sale-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"}


## Best practices

### Handling tips

When a customer receives their check for the purchase amount and opts to pay with a credit or debit card:

1. Authorization is obtained for the check amount by performing an Authorization Only transaction (Type 01).
2. A receipt is presented to the customer to add a tip and signature.  
3. Once the tip is added, the POS runs Incremental Auth (Type 75) to increment the original amount with the tip amount.
4. The transaction is closed with the Prior Auth (Type 07).

There are a few advantages of this workflow:

- The cardholder is present.
- Appending the tip to the original authorization ensures compliance with industry authorization tolerance.
- Meets qualifying requirements for best possible rates.

With EMV, the tip may be added on a PIN pad. In this case, send the transaction as a Sale (Type 02) instead of the Authorization Only (Type 01), since the tip and final amount of the transaction is known prior to sending the transaction for authorization.

:::notice{title="note"}
Many restaurants support electronic receipts. If the CVM is signature (with EMV), the signature needs to be captured.
::: 


:::notice{title="important"}
Elavon does not recommend padding the Reference Number (API field 0007) with leading zeros. If you do, store the value in your system as a string instead of an integer.
Storing as a string eliminates potential presentation discrepancies in two-part transactions, and reduces the chance of downgrades or fees.
:::

### Prior Authorization

Your application should identify open tickets so they are closed prior to settlement processing.

A Prior Authorized Sale (Type 07) should be processed even if the final transaction amount is the same as the amount authorized (cash tip or no tip). Close the ticket and submit the Prior Authorization as soon as possible after the guest signs the check.

Prior authorizations should be generated as part of the end-of-day process or at the end of each shift.

Card Association guidelines state the following:

- The initial transaction performed as an authorization should include the final amount of food, beverage, tax, and the completion transaction (a Prior Authorization).
- The completing transaction would include the additional Tip amount processed with the Incremental Auth (Type 75).

### Adjusting tip amount (After Batch Close transaction)

**End-of-day process:**

Follow the steps below if a tip was entered improperly and the authorization was submitted after a batch is closed.

1. Transmit a Return (Type 09) for the full authorized amount. Returns are sent to the processor at settlement time.
2. Transmit a new Sale (Type 02) for the total amount plus the tip adjustment for re-authorization.
3. Transaction gets a new authorization.

### Full Authorization Reversal, Void Sale and Return

If an Authorization Only (Type 01) is not completed with a Prior Authorization (Type 07), it is a best practice perform a Full Authorization Reversal transaction (Type 61) using the original authorized amount.

This process avoids a misuse of authorization fee from the card associations, and may be required for several reasons:
- The customer requests to pay with another card or method of payment.
- The customer wants to add items to the bill, or divide the check after the initial authorization.
- The customer is owed an adjustment of their total after a coupon or management adjustment.

:::notice{title="note"}
Full Authorization Reversals are not supported by all card brands, types, issuers and TPPs, but should be attempted for all transactions.
A Full Authorization Reversal may take up to 24 hours to process to the cardholder's account.
:::

- Perform a Void Sale transaction (Type 11) if a Prior Authorization (Type 7) has been completed but not settled.
- A Void Sale (Type 11) will automatically attempt a Full Authorization Reversal.
- A Return (Type 09) needs to be issued if a Prior Authorization (Type 07) is settled.

### Bar tabs

Following is the recommended best practice for handling bar tabs:

- Perform an Auth Only (Type 01) for $0.00 to verify the card.  
- Use Incremental Auth (Type 75) for additional charges/rounds, as well as the tip.
- Use Prior Auth 07 to close the tab.  

Other options for handling the bar tab include:

- Charge $50 up front. If the total is less than $50, issue a Full Auth Reversal (Type 61), then issue a new authorization for actual total balance due.
- High dollar transactions are better addressed by authorizing each round, or closing out a charge for large purchases and then continuing with another authorization for the next round.
- The associate swipes the credit card and performs an Authorization Only (Type 01) for a set dollar amount (configurable within the POS application, and should be greater than $1.00).

### Account verification

Account verification transactions ($0 authorizations) allow the POS to confirm that a card has an available balance, and that the AVS and CVV2/CVC2/CID values are correct.

Verifications cannot be used to start a financial transaction lifecycle. If the new transaction for the full authorized amount is not swiped, a transaction fee is charged by the card associations for each $0.00 auth.

#### American Express and Discover

- Account verification transactions must have an amount of $1.00 or more.
- Cards that are manually keyed require billing zip code, street address, and CVV2/CVC2/CID information for approval.

#### Visa and MasterCard

- Cards that are manually keyed require the Billing ZIP Code for non-swiped $0.00 authorizations.
- Visa assesses a Misuse of Authorization fee for all unsettled Authorization Only transactions. Any transaction that is not settled in the defined time frame is subject to this fee.

### Store and Forward

On rare occasions, Fusebox may not be able to complete transactions due to processor outage, network outages, or system maintenance. Store and Forward is the process of encrypting and storing incomplete transactions at the POS for later processing.

When Fusebox becomes available, the POS application forwards the stored transactions for authorization. Transactions are processed as if they were sent in real‐time.

Store and Forward transactions are authorized as swiped or keyed based on the original transaction data. Since the authorization data may contain a card swipe, or if manually entered, card number, AVS and CVV2 / CVC2 / CID, it is extremely important that the data be stored encrypted, following all PCI‐DSS guidelines. PCI‐DSS guidelines state specifically that card swipe data cannot be stored past the authorization. Since the authorization has not been performed it is acceptable to retain this information only in an encrypted environment and as soon as the transaction is submitted for authorization the sensitive data is removed from the POS.

Consult with your Elavon integration analyst for additional information before integrating Store and Forward.

### Quick serve

Quick serve restaurants get food to the customer with limited or no table service.

- Tips are not usually part of the transaction amount.
- POS applications in this environment are advised to support one-part Sale (Type 02) transactions.

### Delivery / Takeout / Catering transactions

Transactions are accepted by the merchant where a card may or may not be present. For example, the merchant accepts takeout orders where either there is no tip, or the gratuity is always added to the purchase amount based on a set percentage. This transaction is entered as a Sale (Type 02).

### Split-tender transactions
A bill is split between multiple forms of payment. In the following workflow, a bill for $25.00 is split into two checks, one for $15.00, and the other for $10.00.

1. The first split check amount of $15 uses an Authorization Only (Type 01) to obtain authorization.
2. Tip is added using Incremental Auth (Type 75).
3. Complete sale of first check including tip with Prior Auth (Type 07).
4. Second split check amount of $10 uses an Authorization Only (Type 01) to obtain authorization.
5. Tip is added using Incremental Auth (Type 75).
6. Complete sale of second check including tip with Prior Auth (Type 07).

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

Lodging API fields

Lodging examples

Credential on file transactions

Best practices

Software conversions

Restaurant

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