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 addresses topics unique to the integration of the Fusebox platform with Direct Marketing or eCommerce applications. Your implementation should address the following business criteria that are specific to the Direct Marketing industry:

- Cardholder not present - Card number is manually entered.

- Only one electronic authorization request - Authorization reversal is allowed to make the total authorization amount equal to the amount settled.

- eCommerce - Card not present and cardholder information received over a secure website.

## Transaction types

Below are the transactions most used in MOTO/eCommerce POS 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"}
- :magic-link[Partial Authorization Reversal (Type 76)]{id="partial-authorization-reversal-md"}

## Direct marketing industry requirements

Transactions can be subject to higher processing costs if the following payment industry requirements are not supported.

**Amount tolerance:** The acceptable tolerance (difference) between the amount authorized (initial and subsequent reversals) and the final amount must be zero percent (0%).

The transaction is not compliant with industry requirements if the authorization and final amounts are out of tolerance, or if your application submits more than one authorization request for the same card number and reference number.

**Authorization practices:** The card associations recommend that the original authorization request not exceed 15% over the estimated final transaction amount. This guideline is intended to aid in the management of the cardholder's open-to-buy.

In the event that the original authorization amount exceeds the final transaction amount, an authorization reversal is required to comply with the proper qualification requirements. A periodic review of the percentage calculation is recommended, so that adjustments can be made when warranted.

If the total amount authorized exceeds the amount to be settled by an amount larger than the tolerance percentage configured in Fusebox, a Partial Authorization Reversal (Type 76) is automatically generated prior to settlement.

:::notice{title="note"}
In order to return open-to-buy to a cardholder, a real-time partial Authorization Reversal is necessary as a best practice. If you allow Fusebox to perform the reversal at the time of settlement, it may be over 24 hours before the reversal is processed to the cardholder’s open-to-buy.
::: 

**Account verification:** 
-   Account verification (zero-dollar authorization) can be used when starting a transaction, but requires entering the billing ZIP Code, street address, and CVV2/CVC2/CID to obtain an approval from American Express and Discover. 
-   MasterCard and Visa only require the billing zip code. 
    -   This allows the POS system to confirm that the card is valid, approve (not for a specific amount), and confirm the AVS and CVV2/CVC2/CID values. Start with a new reference number when authorizing the transaction since an account verification transaction cannot be used to settle a transaction. 
    -   Additional fees will be charged for the account verification transactions.

Any authorization for more than $0.00 that is left unsettled is subject to a misuse of auth fee. Settlement must occur within 10 days of authorization or within 20 days for travel and entertainment (T&E). Validate an account number using a $0.00 amount to avoid incurring this fee.

If the cardholder account is not in good standing, the transaction processor responds with a decline message. Use the Authorization Only transaction to verify a credit card when the cardholder is not present to minimize the risk of fraud. Authorization-only transactions identify the card as a valid before the purchase is completed without impacting the customer’s open-to-buy for the entire purchase price, or before processing an order.

**Transaction date:** The transaction is compliant when the current transaction date and the date shipped (API field 0711) are the same, and not more than 7 days from the original authorization request. Follow the rules for a long-term purchase if the dates are different.

**Timeliness presentation:** A transaction is not in compliance with industry requirements if it can't be settled within 7 days.

**Address Verification Service (AVS):** AVS is a required service in the direct marketing industry. The cardholder’s billing zip code must be supplied to meet minimum industry requirements.

An address verification request must be performed on the cardholder’s billing zip code to obtain improved qualification status and lower processing costs. It is the responsibility of the POS to interpret the AVS Response (Field 1020) to ensure that the merchant is not exposed to risk in processing the transaction.

**CVV2 / CVC2 / CID validation:** CVV2, CVC2, and CID are values that can be included in the authorization request when a card is not present. Passing this data with direct marketing transactions helps protect the merchant against chargebacks.

It is the responsibility of the POS to interpret the CVV2/CVC2/CID response (Field 0040) to ensure that the merchant is not exposed to risk in processing the transaction.

**eCommerce reference:** Card associations require merchants to provide an Electronic Commerce Indicator (ECI) to identify an eCommerce transaction and the method of authentication used to secure the transaction. Merchants may incur penalties if an eCommerce transaction does not have a valid indicator.

:::notice{title="note"}
Transactions require eCommerce indicators if they were the direct result of the cardholder entering their account number online. Indicators for the first eCommerce transaction include storing a card number on file or recurring billing. Entering the card data online can be considered direct marketing after the first instance.
::: 



MOTO and eCommerce 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 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