On-Device SAF Transaction Lifecycle

On this page:

Summary

If enabled, On-Device SAF processing will occur when a supported transaction cannot process online due to a supported communications error (see 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.

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).