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 page walks through the integration processes of how to set up a test account and credentials, send your first request with important fields to test, and perform final certification to move to production.

## Step 1: Engage solutions engineer

Work with your solutions engineer to identify the scope of your integration requirements, payment processing and set up test credentials to begin development and testing. You may also receive a site ID, user name, and password. You can access your account through the [Fusebox web application](https://gatewaydemo.elavon.net/ui/login).

View :magic-link[Test cards]{id="test-cards"} for approved card numbers in our test environment and the Elavon test host pre-programmed responses document to generate a variety of responses and CVV response codes.

For a transaction to be accepted by Fusebox, the following minimum fields must be included. These values will be set up by your solutions engineer:
- Terminal ID (API Field 0109) – ID for a specific payment terminal. This is configured to define processor communication settings. 
- Location ID (API Field 8002) – Information tied to the geographic location of business, a store number, for example.
- Chain Code (API Field 8006) – ID used for key management in gateway environments. This code is assigned during the boarding/conversion process.




## Step 2: Development
If you are connecting to Fusebox with a VPN, MPLS, Frame connection, then a SLB IP address and port will be published to the specific implementation. 

There are two ways to connect to Fusebox: TCP/IP or XML HTTPS POST:

- **For TCP/IP with TLS 1.2 use:** `https://gatewaydemomoc.elavon.net:7000`
- **For XML HTTPS POST use:** `https://gatewaydemomoc.elavon.net:7500`


:::::notice{important}
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 byte array (to make it UTF-8 compatible) depending on your choice of programming languages.
:::::

### Server authentication
All POS integrations are required to perform a server authentication when integrating to Fusebox. This must be done against a trusted certificate authority and a 2048-bit SHA-2 certificate. Production and ETE URLs and certificates are unique.

## Step 3: Transaction testing
Begin testing all of the transaction types supported by your integration. See Transaction types for a full list of transaction types with examples.

### Transaction flow
Below are transaction flow and API message formatting requirements to successfully perform integration testing steps: 

:magic-link[API message format]{id="api-msg-format"} - Overview of formatting Fusebox messages and best practices.
:magic-link[Transaction sequencing]{id="transaction-seq"} - Most commonly used transactions and basic sequence to complete a transaction.

### Terminal considerations
If you plan on implementing Elavon's Simplify payment application on your payment terminal, refer to the :magic-link[Simplify documentation]{id="/products/simplify/v1/overview"}. You will also work with your integration analyst to configure and test based on your requirements.


### Test modes
To test other functionality in your POS integration, you can setup a Site ID in different ways:
- **Demo mode**: A Site ID can be placed in demo mode to allow for testing of scenarios that are hard to create in the live test host. This offers more predictable way to test specific error conditions using test card numbers.
- **Blocking mode**: Use this mode to test payment terminal integrations for Store and Forward (SAF) functionality, if using Simplify for example. This is an attended or actively-monitored testing where you work together with the integration analyst to perform testing and certification steps. This also offers more predictable timeout scenarios. 

Contact <gateway.integration@elavon.com> to change from one mode to another.

## Step 4: Certification
Work with your solutions engineer and certification analyst to complete the certification process, to ensure that your POS application and integration environment as a whole is functioning to Elavon gateway standards of transaction processing. 

### Full review requirements
A full integration review and certification is required if any of the following situations apply:
- You are a new customer integrating to the Elavon gateway application. 
- You are an existing customer and your application has any of the following: 
 - An exception from a previous certification. 
 - Added gift card, PIN debit, check, private label, international processor, or EMV functionality. 
 - Your application is certified to a terminal capture processor and it is now supporting a host capture processor (or vice-versa). 
 - A previous certification that is older than 3 years. 
 - Had major changes incorporated that may affect payment processing. 
 - Elavon has received reports of a significant issue with your POS application. 
 - You want to add support for SAFE-T Suite, Token Vault, Unique ID, or Point-to-Point Encryption (P2PE).

### Partial review requirements
If you are an existing customer, you may only require a partial integration review in the following situations: 
- You are adding a new industry type to an existing integration. 
- You have previously certified on one operating system platform and are migrating to a new operating system platform. 
- You have been certified to use the Elavon gateway application and would now like to enable additional features such as API-based settlement, automated settlement, partial authorization approval, full authorization reversal, or account verification transaction. 


### Certification process
Certification should not be considered a guarantee that a customer transaction at a third-party processor will meet all compliance criteria. Compliance can only be validated by a TPP that reviews live transactions end to end, allowing time for the transactions to be processed through the entire processing cycle.

1. **Discovery call**
 - Call between customer team, integration analyst, solutions engineer and client executive.
 - Review of the Solution Statement/Statement of work/Exhibit A.
 - Confirmation of Work/Exhibit A and confirmation of project scope and goals. 
 - Discuss application logic and transaction flow.
2. **Preliminary testing**
 - Customer provides logs of basic transaction styles relative to their industry. For example, a retail integration would provide an example of a Sale (02) transaction.
 - Customer must perform successful transactions relative to their verticals or industries before progressing to certification test scenarios. 
3. **Certification testing** 
 - Customer and development staff test the payment application(s) using Elavon testing scripts (usage scenarios), which are segmented by industry, i.e., retail, MOTO/eCommerce, restaurant, lodging.
 - Customer captures log files of their request messages to Fusebox/device. The responses they get back are archived and sent to the Elavon integration analyst for review. Each set of request/response files is referred to as a "wave".
 - Customer and analyst continue going through these waves until all requirements are met, withstanding any exceptions/observation items. 
 - When status of request messages is considered ready to be certified, the integration analyst will coordinate with another member of the integrations team to do a peer review.
4. **Peer review**
 - An Elavon internal peer review is performed by another certifications team member who double checks the work that has been done before a certification letter can be issued.
 - A comprehensive set of test scenarios is included in this review and adds additional layers of verification. 
5. **Certification letter issuance** 
 - The certification letter documents the scope of the integration certification and exceptions. In addition to the standard items the letter may also include comments regarding any inaccuracies the customer application may have before going to market.
 - Customer signs the PCI/PADSS verification form. Signing of this form confirms that the customer has either performed a self-assessment or utilized a 3rd party to audit their payment application.
 - Both the certification letter and the PCI/PADSS verification form must be countersigned and submitted to the integrations team before any application can be certified with Fusebox. 
 - Subsequent boarding processes can not be initiated without these two documents being completed.

Getting started

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

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

Gift and stored value card API fields