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

If enabled, On-Device SAF processing will occur when a supported transaction cannot process online due to a supported communications error (see :magic-link[On-Device SAF]{id="on-device-saf"} for supported transactions and errors). These transactions will be referred to as SAF-eligible transactions.

For SAF-eligible transactions, Simplify performs Stand-in, generates a SAF token, writes the transaction to the SAF database, and sends a transaction response to the POS. In more detail, Simplify:  

-   Performs Stand-in – Locally approves the transaction if no SAF limit is exceeded; else locally declines.

-   Sends the result to the POS, including a SAF token. (No sensitive data; includes EMV tags needed for receipt.)

-   Writes SAF token and data needed for resubmission to a SAF database, with an initial status of “Pending”. 

Simplify attempts to process each transaction in the SAF database through Fusebox until the transaction is resolved. A transaction is resolved when it receives a forwarded (host) response from Fusebox (used to update the database) or expires. The status is then changed to “Complete” (final status).

Note on terminology: Transactions processed through Stand-in and written to the SAF database (implying that a SAF Token was generated) will be referred to as SAF transactions.

The following subsections provide additional details concerning the SAF transaction lifecycle.

## Stand-in Process

Simplify will locally approve SAF-eligible transactions that meet the following conditions:

- The transaction amount does not exceed a configured limit.

- The total amount of all pending (unresolved) locally approved transactions does not exceed a configured limit. (Refund amounts are treated as positive numbers for this calculation.) 

- The number of records contained in the database does not exceed its defined limit.

All local approvals and local declines are written to the SAF database. These are the only transactions initially written to the database.

**Note:** If On-Device SAF is enabled, an offline transaction that is not SAF-eligible will be declined with a "\*SLR COMMUNICATIONS ERROR" response. (For example, Simplify will not stand in on a Debit transaction.) Standard :magic-link[Inquiry Message]{id="inquiry-message"} processing should check for whether a transaction needs to be reversed.

### Cannot Write Record to Database

If Simplify cannot write a local approval or decline to the SAF Database, the transaction will instead be declined with one of the following decline codes:

- *SLR SAF DB FULL – The database has already reached the maximum number of allowed transactions (configurable).

- *SLR SAF DB REC ERR – Any other failure to write to the database.

Standard Inquiry processing should be performed, since the transaction will not be in the database.  Since no SAF Token was returned, Simplify will treat the Inquiry from the POS as a pass-through message to FuseBox (BAU).

### SAF Token

A SAF transaction database record includes a Simplify-generated SAF token. This token is used as the record key and is also sent to the POS in the original transaction response. The SAF token is used throughout SAF-related messaging as a unique transaction identifier (API field 5073). 

## Obtaining and Handling a Host Response

Simplify attempts to obtain a forwarded (host) response for all transactions in the SAF database. The method used depends on the Stand-in result as follows: 

- Local approvals – Periodically forwarded (resubmitted) to Fusebox until resolved. 

- Local declines – Inquiries periodically sent to Fusebox until resolved.

A SAF transaction is resolved when it receives a host response (forwarded approval or forwarded decline), or is too old to process (declined by Simplify, based on configuration). Transaction status in the database record will then be changed to “Complete”.

Handling Host Responses to SAF Transactions:

- If the Inquiry for a local decline results in a no record found response from Fusebox, then nothing further is done.

- If an Inquiry response indicates that a locally declined transaction was host approved, Simplify will automatically send a Void for the transaction (POS not involved).

- The voiding of SAF transactions can also be managed by the POS as described in the next subsection.

## POS-Requested Voiding of a SAF Transaction

Simplify provides flexibility in POS management of SAF transactions by allowing the use of either the Fusebox token (“true token”) or the SAF token to request the voiding of a transaction that has been locally declined and host approved:

- The POS can periodically send an Inquiry with the SAF token (API 5073). If the transaction is resolved by a host response, Simplify will return the Fusebox token to the POS.  The POS can then use this token to void the transaction through Simplify or directly to Fusebox.

- In order to complete POS processing of a locally declined transaction without waiting for host resolution, a void can be requested using the SAF token.  Simplify will handle all further processing, as follows: 

    - Simplify notes when a Void request is received for a pending SAF transaction.  Simplify continues to despool the SAF transaction, and if an Inquiry response indicates it has been host approved, sends a Void to Fusebox.  
    - Integrators who choose this approach will be reliant on Fusebox reporting to determine out of balance causes (i.e. SAF transactions that were declined or still pending on device).  

## Transaction Expiration and Purging

### Transaction Expiration

Expiration is controlled by the SAFDayLimit parameter. Consult your Elavon representative for details.

Expired transactions are not sent to Fusebox. When the transaction is first processed from the SAF queue after it has expired, it will be declined by Simplify and transaction status changed to not pending.

### Purging SAF Database Records

Purging is controlled by the SAFPurgeDayLimit parameter. Consult your Elavon representative for details. 

Only resolved transactions are subject to purging. A transaction is resolved when it receives a host (forwarded) response or expires.

SAF records of host-approved transactions will be automatically purged a configured number of days after host approval.  This is controlled by a separate parameter, SAFProcRecPurgeDay (minimum/default=2 days).



On-Device SAF Transaction Lifecycle

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

Simplify Overview

Ingenico Developer Guide 2.03.02x.121 Ver. 25-31

Simplify Introduction

Supported Hardware

General Guidelines

Message and Communications Protocols

Versioning

Financial Messages

Overview and Guidelines

Sale Message (Tran Type 02)

Auth Only Message (Tran Type 01)

Prior Auth Sale Message (Tran Type 07)

Incremental Authorization Message (Tran Type 75)

Full Authorization Reversal Message (Tran Type 61)

Partial Authorization Reversal Message (Tran Type 76)

Return Message (Tran Type 09)

Void Return Message (Tran Type 17)

Void Sale Message (Tran Type 11)

EBT Messages (Tran Types 02, 09, 11, 17, 24)

Gift Card Messages (Tran Types 01, 02, 07, 09, 11, 17, 24)

Inquiry Message (Tran Type 22)

 DCC Inquiry Message (Tran Type 46)

Token Request Message (Tran Type 37)

Cancel Message (Tran Type 80)

Health Message (Tran Type 73)

Batch Close Message (Tran Type 13)

Batch Inquiry Message (Tran Type 14)

Non-Financial Messages

Non-Financial Messages (Tran Type 36)

Signature Message (Tran Types 36-01, 36-02)

Version Number Inquiry Message (Tran Type 36-06) 

Initiate HEM/IngEstate Message (Tran Type 36-07)

Scrolling Receipt Request Message (Tran Type 36-10)

Scrolling Receipt Stop Message (Tran Type 36-11)

Exit Reversal Mode Message (Tran Type 36-12)

Informational Prompting Message (Tran Type 36-14)

System Command Message (Tran Type 36-15)

Allow Pre-Tendering Message (Tran Type 36-40)

Print Request Message (Tran Type 36-45)

Status Message (Tran Type 36-51)

POS SAF Processing

Offline Transaction Processing

Stand-In Response

Store and Forward Transactions 

EMV Considerations

EMV Tags and other EMV-related Response Fields

EMV Offline Situations

ICC (Chip) Declines and Simplify Reversal Mode

Pay-At-Table

Transaction Flow

Pay-At-Table API Fields

Messaging

Pay-At-Table Message Overview

Login Message (Tran Type 39-01)

Get Check Info Message (Tran Type 39-02)

Controlling screen flow after check selection

Check Detail Message (Tran Type 39-07)

Make Payment Message (Tran Type 39-05)

Print Receipt Message (Tran Type 39-06)

Simplify Payment Process

Print Receipt Request and Response (Tran Type 39-06)

Logout/Disconnect Message (Tran Type 39-04)

Recovery

Informational Prompting

General information for all tags

Generic messaging

Tag 010 - Text with Optional Buttons

Tag 011 - Static and Scrolling Text with Optional Buttons

Tag 012 - Text and Graphics with Optional Buttons

Tag 013 - Fast Graphics Download

Tag 014 - Text and Camera Image

Tag 020 - Scrolling Text 

Tag 030 - Virtual Keyboard

Tag 031 - Tactile Keypad

Tag 040 - Radio Buttons 

Tag 050 - Check Boxes