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

## Request and response messages

The following guidelines will ensure that your POS application sends properly formatted request messages.

- Each line of the file should contain a separate field entry.
- Each line must contain at least a field number, a comma, field data, and a line terminator (in that order).
- Request must not have any additional blank lines or line terminator characters at the end of the request.
- Minimum required fields specific to the transaction type must be included in the request, to reduce gateway error messaging. Required fields are defined under scenarios and API fields pages under each industry type or use cases.
- Sent fields must conform to attributes including: length, type, and acceptable values as outlined in this guide.
- Response data from the processor must be "re-presented" in a subsequent transaction exactly as they were received in the respective API field. Do not justify, zero-fill, or pad with spaces when re-presenting data.

### Basic components
Request and response messages are formatted using the following components:

- **FieldNo** - The 4-digit numeric code (0001, for example).

- **FieldData** - The data being sent or received by the application. The data cannot contain tab characters and must meet the validation requirements such as data type and maximum field length.

- **LineTerminator** - Hexadecimal character is required to terminate the line. 
 - Line feed (xOA) and a carriage return (0x0D) for Windows 
 - Line feed (0x0A) for UNIX.




### XML best practices
To ensure XML documents are valid and well-formed, refer to these important best practices:

- Each XML document begins with the XML version tag and encoding.
- All documents consumed by Fusebox are forced to UTF-8 (Unicode Translation Format) encoding of the unicode character set.
- An XML file might contain one or more (1 to n) transactions. All transaction data is within the \<Transaction\>\</Transaction\> start and end tags.
- A limit of 50 transactions are allowed inside a single XML DOC with each transaction enclosed in a \<Transaction\>\</Transaction\> tag.


In the example below identifies the type of XML document we are dealing with:
- Document follows W3C XML schema rules.
- URL of the online schema-instance is defined.
- No namespaces

API Field 0001 indicates that this transaction is an authorization (field value = 1). **Note:** The usage of :magic-link[Prior-Auth Sale (07)]{id="prior-authorized-sale-md"} does not require that this line be changed.


**XML document coding example:**
```xml
<?xml version="1.0" encoding="UTF-8"?>

<ProtoBase_Transaction\_Batch
xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
xsi:noNamespaceSchemaLocation="<http://www.protobase.com/XML/PBAPI1.xsd>">
<Settlement_Batch>false</Settlement_Batch>
<Transaction>
<API_Field>
<Field_Number>0001</Field_Number> 
<Field_Value>1</Field_Value>
</API_Field>
<API_Field>
<Field_Number>0002</Field_Number>
<Field_Value>30.00</Field_Value>
</API_Field>
<API_Field>
<Field_Number>0003</Field_Number>
<Field_Value>4012XXXXXXXX0001</Field_Value>
</API_Field>
<API_Field>
<Field_Number>0004</Field_Number>
<Field_Value>1020</Field_Value>
</API_Field>
<API_Field>
<Field_Number>0007</Field_Number>
<Field_Value>323456</Field_Value>
</API_Field>
</Transaction>
</ProtoBase_Transaction_Batch>
```

:::notice{note}
The HTTPS POST should have a ContentType of "xml/text". DO NOT "URL encode" the XML DOC. 
You may need to ASCII encode your API when converting it to a ByteArray, (to make it UTF-8 compatible) depending on your choice of programming languages.
:::



### Sending request messages

When the request is ready to send to the Fusebox:

- Transmit the request information via TCP/IP over TLS 1.2 or XML via an HTTPS POST.
 - Fusebox utilizes redundant IP endpoints with DNS. 
- All applications must be coded to Fusebox with a URL when using the public Internet.
 - If not coded, in the event of a switch failure, failover is not available.
 - Discuss the available private network options with a solutions engineer or gateway integration analyst.

## Gateway connectivity options
Fusebox supports the following connectivity options with the Elavon Gateway message:

1. **Elavon Gateway message over the Internet**
 - XML with SSL or an HTTPS: POST
 - In compliance with industry standards, and to protect our clients, all applications are required to support TLS 1.2 protocol and SHA-2 certificates in all transmissions to our host. 
 - POS terminals operating on lower level TLS protocols or SSL are required to update their communication routines as part of the development effort to communicate with the Fusebox gateway.

:::notice{note}
The transfer coding protocol for the transaction response is the text\\xml. **URL encoding is not supported**.
:::

2. **Elavon Gateway message over a trusted network**
 - TCP/IP with TLS or SSL
 - TCP/IP over a trusted network
 - XML with SSL
 - XML over a trusted network

3. **TCP/IP communication using Elavon Gateway message method**
 - Fusebox only responds using UNIX version LF (0x0A) EOL characters no matter which type was originally sent to Fusebox.
 - All standard API messages are transmitted with the addition of an EOT (End of Transmission, ASCII hex 0x04), to the end of the last record.
 - Connection remains established until the server sends the response and terminates it with EOT.
 - Server closes the TCP/IP connection after response is sent. 
 - Client initiates closing the server connection so that can handle new incoming requests more quickly.
 - Client can close its connection any time after receiving the response message.

 - Multiple APIs can be sent in a single message, with a RS (record separator ASCII hex 0x1E) between each API and an EOT at the end of the last record.
 - **Important**: Your code must match the responses to the requests because the records may not be returned in the same order.

 - Fusebox also responds to a persistent TCP connection.
 - The process is the same as described above, other than the client does not need to close its connection after receiving the response message. 
 - The next request can be sent over the existing TCP socket, using the same EOT/RS logic. 
 - Idle socket timeout is 600 seconds. If the timing between transactions on an open persistent socket will exceed that window, we recommend sending a :magic-link[Heartbeat (73)]{id="heartbeat-md"} to maintain connectivity to the gateway.

## Cipher groups

Fusebox supports the following cipher groups:

- TLS1-AES-256-CBC-SHA
- TLS1-AES-128-CBC-SHA
- TLS1-DHE-DSS-RC4-SHA
- TLS1-DHE-DSS-AES-256-CBC-SHA
- TLS1-DHE-DSS-AES-128-CBC-SHA
- TLS1-DHE-RSA-AES-256-CBC-SHA
- TLS1-DHE-RSA-AES-128-CBC-SHA

API message format

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

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

Gift and stored value card API fields