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

## Check payment
 
This section addresses topics unique to accepting checks as a payment method. A code switch is required in your POS application to handle minor changes between the integration of a check customer with Fusebox. The implementation of the Elavon Gateway applications into your POS application must address the following business environment criteria that is specific to accepting checks, where electronic check conversion, verification, or guarantee may apply:

- An authorized check writer of an account may or may not be present.
- A merchant processing agreement with a certified check service provider must be in place.
- All industries that accept checks as payment must be addressed.

 ## Transaction types  

 The following transaction types and transaction qualifier are required when using the Check Conversion, Check Verification (with or without ACH), or Check Guarantee (with or without ACH) services. 

- **Sale (02)**
  - Transaction Qualifier - Field 0115 = 020
 
- **Void (11)**
  - Transaction Qualifier - Field 0115 = 020

:::notice{title="important"}
 - A void to Elavon Acquiring check host can only be processed within 10 minutes of the original transaction. 
 - Check transactions are non-industry specific therefore no industry fields are to be included in the API request.
::: 


 ## Check acceptance considerations

Individual states within the United States govern the acceptance guidelines for checks tendered within their jurisdiction. The ability to prosecute may be limited if the state guidelines are not followed. Collection costs could be higher for customers who do not adhere to the state guidelines (i.e., customer contracts for services from a third party, such as a check service provider).

 Key implementation considerations that apply to accepting checks include:

- Check service provider and services
- Check payments
- Services offered by transaction processors and check service providers
- Magnetic ink character recognition and card readers
- Check types
- Identification options


 ### Services offered by TPPs and check service providers 

Your POS system is responsible for securing the MICR information from the presented check. The services offered by transaction processors and check service providers include:

- Electronic check conversion (with or without ACH)
- Check verification (with or without ACH)
- Check guarantee (with or without ACH)
- Electronic check conversion can be combined with verification or guarantee services as well, but this guide is focused on the primary check service in all cases. 
- The section below describes how each check service works.
- Each merchant can only be setup with one of the check services. 


- **Check Conversion**
When approved, a financial transaction results in funds moving from the check writer’s account to the merchant’s account. An authorization that is obtained and submitted on a merchant’s Demand Deposit Account (DDA)is a record for funding at the end of the day, along with the credit card transactions. A physical check does not need to be deposited at the merchant’s bank. The funds are moved through an Automated Clearing House (ACH). Some check conversion products can be combined with check verification or check guarantee, to reduce the risk of performing a check conversion where physical goods are exchanged.



- **Check Verification**
A non-financial transaction which requires a normal deposit of the physical check to fund the merchant account. Check verification validates that the bank account associated with the check does not have a bad check status and therefore, is not a high risk. Processors may verify that the check writer’s account is not on a negative file. The negative file contains the accounts that have insufficient funds (NSF) checks written against them. This also has the option to perform ACH in near real time.


- **Check Guarantee**
A non-financial transaction that requires normal deposit of the physical check to fund the merchant account. Check guarantee services may include:
  - Verification that the check amount exists in the checking account at the time of purchase. This essentially guarantees that the merchant will receive funding for the purchase.
  - Scoring of customers by beacon score or credit worthiness. Based on the score, these services may guarantee a person’s check, but may not actually check the balance in the account.
  - NSF recovery and full payment to the merchant for any check that is not recovered, as long as the required identification and process was followed during the acceptance and guarantee.

The check services currently offered to merchants have different requirements for the data gathered during the authorization process. Elavon has documented the most common check authorization requirements in this guide. For check authorization requirements specific to particular transaction processors, refer to the appropriate processor section of the TPP Interface module guide.


:::notice{title="note"}
This also has the option to perform ACH in near real time.
:::


## Automated Clearing House (ACH) check transactions

ACH check transactions are the check not present equivalent of ECS transactions, using only the bank routing number and account number from the bottom of the check for processing. ACH uses the same processes and infrastructure as ECS to perform check not present transactions accepted via the internet, telephone, back-office (single or recurring) and pre-approved payments on accounts.

To support ACH transactions, API fields 0920 and 0921 are required.
  

ACH Format Code – API Field 0920 (3 Numeric) – One value available:
- 001 – Indicates Format Code B ACH Check Transactions 

ACH Product Codes – API Field 0921 (3 Alpha/Numeric):
- WEB - Internet-initiated based on input of account information by customer at a payment application website.
- TEL - Origination of debit entry following an oral authorization obtained via the telephone or IVR.
- PPD - Origination of debit entry following a standing (recurring) or single entry with written authorization signed or similarly authenticated by the customer.
- CCD - Origination of debit entry by an organization to transfer funds to another organization with written agreement. 


**Magnetic Ink Character Recognition (MICR) and card readers**
Your POS system is responsible for securing the MICR information from the check presented through a MICR card reader. Unlike credit cards, there are no standard formats for the MICR line located on the bottom of a check. The check reader manufacturers support the most common formats. The formatting and presentation of collected MICR data to the Elavon Gateway applications varies by check service provider and transaction processor. 
  

**Check Types**
Specific identification is required for each type of check presented. All POS systems should be able to identify the type of check and prompt for the appropriate type of identification.

Check types include:
- Personal
- Business
- Corporate
- Payroll
- Government


**Identification Options**
The most common types of identification are listed below. These types can vary depending on the check service provider and the end user’s merchant preferred business practices:
- Check number
- Date of birth 
- Full MICR 
- Partial MICR
- Alternate IDs such as social security numbers, courtesy cards or military IDs
- Driver’s license number and state code (swiped or manually entered, depending on the issuing state)

  
:::notice{title="note"}
The check service provider may require more than one type of identification.
::: 

  

## Business practices and impact

Business practices must be in compliance with the state code table and check authorizations rules described below.

**State Code Table**
Your POS system is required to support and maintain a cross reference table that is based on information provided by the check service provider. This table must contain the alpha or numeric number (see: [ISO standard number for each state](https://www.iso.org/obp/ui/#iso:code:3166:US)), and state codes required by the check service provider and transaction processor to identify the state where the check or driver’s license was issued.

**Optional POS Functions**
The two optional POS functions available in Fusebox are check franking and a manager override. 

**Check Franking** 
The merchant is also responsible for documenting or franking (validating) the physical check with pertinent information. Check franking is the endorsement of the check. Some POS systems have the ability to automate the check endorsement at the register as part of the check approval process.

**Manager Override**
Another feature you may want your POS application to support is the ability to accept a check that is declined by the check service provider based on a manager’s override.
  

:::notice{title="note"}

If the customer is sending the scanned in check image directly to their check processor, they should include the following data elements tagged as metadata together with the scanned image: MICR, Date Time, and Elavon MID. This metadata is needed by the check processor in order to match the scanned image to the ECS transaction sent through Fusebox.

:::

 

Check 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 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