On-Device SAF Transaction Lifecycle
If On-Device SAF is enabled, Simplify performs Stand-in on SAF-eligible transactions, generates a SAF token, writes the transaction to the SAF database (initial status = “Pending”), and sends a transaction response to the POS (no sensitive data), including EMV tags needed for a receipt.
The transaction is then referred to as a SAF transaction and processed by exchanging messages with Fusebox based on the database record until the transaction is resolved (receives a host response or expires). The status is then changed to “Complete” (final status).
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 Inquiry processing should check for whether a transaction needs to be reversed.
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.
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).
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 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”.
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).
If the Inquiry for a local decline results in a no record found response from Fusebox, then nothing further is done.
Voiding of a SAF Transactions
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).
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.