# SCA SAF Reference Guide ## Introduction This is a quick reference guide describing one of the most important features of SCA called **Store and Forward** (SAF). Through this document, we will understand various situations that can cause the application to trigger this functionality and also the various configurations that play a role in this feature. The guide also provides an introduction to the various commands used for handling this feature. This guide is intended for Developers, Integrators, Customers and Partners to understand the impact of having the feature enabled. ## Overview on SAF Primarily, **Store and Forward** (SAF) is a feature for Semi-integrated and rarely for Standalone configurations of SCA. This feature allows the payment application to conditionally approve payment transactions when the host, also commonly known as gateway/acquirer/processor is unavailable to process the transaction, thereby allowing the merchant to continue to accept payment although at increased risk of transaction getting declined (fraud, insufficient funds, etc.). The stored, conditionally approved transactions are later forwarded to the host once it is available again to complete the process. ### Purpose of SAF SAF helps ensure that the merchant does not lose out a transaction due to bad network or gateway/acquirer system errors. In a fast-paced retail or restaurant setup, it is imperative to have SAF functionality enabled. This allows transactions to be locally stored and forwarded to the gateway at the appropriate time once network becomes available instead of losing the sale due to network inconsistencies. ### Conditions for SAF Transaction * **Processor/Gateway Unavailable** - There are cases where the processor or payment gateway may not be available due to server failures or downtime due to upgrades/patches being applied on Server. In this case, the connection to the Server cannot be established. * **Store Network Issues** - It is possible that the Network at the merchant store is unavailable due to power failures on switch or issues connecting to the DNS/Gateway IP addresses. * **Device Configuration Error** - If the device is configured to the wrong interface settings which cannot be initialized due to network unavailability or incorrect settings of the communication interface, then transaction can still be SAF’d. For example - Incorrect SSID configured for WIFI. * **Host Initiated SAF Processing** - This is the ability to treat certain host responses as communication error and then store the transaction offline. i.e., SAF the transaction. ## SAF Process As mentioned in the section of [Conditions for SAF Transaction](#Conditions-for-SAF-Transaction), all events provided in that section would set the terminal in an offline mode. In this mode, the SCA application would start sending a message to the Payment gateway/Processor to check if connectivity was restored. This is also known as a **SAF Ping**. If the processors do not support a separate message for a Ping, then the application tries to initiate a TCP level connection. These Pings are attempted at specific periodicity called the SAF ping interval. Once the application identifies the host is available, it posts the transaction online by picking up the transactions from the SAF database. All the transactions are sent out from the application at a pre-fixed periodic interval called the SAF Post interval. Each transaction would be posted one transaction at a time. SCA Application maintains a database to store and track the status of the SAF Transactions. Once transactions are posted online, the SAF database is updated with the authorization code and other details from the response. The SAF Query command can be performed to check the details of the SAF Transaction while it is stored offline and even after being posted online. ### SAF Forwarding * Based on config value (SAFPINGINTERVAL), the application will ping the host for connectivity. * If successful, then it will implement a device unique delay based on serial number and config value, which is set using SAFTHROTTLINGINTERVAL (wait this long) and then attempt to connect to the host. * This is done so that in the event of a widespread outage (host down), 10s of thousands or more units will not connect and try to upload at the same time, possibly overloading the host. * Once the host response is received, the SAF batch record is updated. * If approved or partially approved, that amount is registered in the Authorized batch along with approved online transactions. * The engine will wait a configurable amount of time (set in SAFPOSTINTERVAL) before sending the next eligible transaction from the queue. Once the SAF transactions have been forwarded, the record will be updated accordingly. Refer to the below section for the different SAF record status. ### SAF Record Status | **Status** | **Definition** | | ------------- | --------------------------------------------------------------------- | | ELIGIBLE | Queued / waiting to be processed SAF Records. | | PROCESSED | Approved SAF Transactions. | | DECLINED | Declined SAF Transactions. | | DEFERRED | SAF Transaction which would be at the end of the Queue to be retried. | | NOT PROCESSED | Hard error/Invalid Transaction | Once transactions have been completed (either Processed or Not Processed), these transactions are retained in the table for a configurable number of days (set in SAFPURGEDAYS) and then removed. ## Configuration Parameters Following table details the list of configurable parameters, those are affecting SAF transaction. | **Parameters** | **Description** | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SAFENABLED | This is the global parameter surrounding the SAF functionality. If this is disabled, transaction will not be saved offline or retried. | | TRANSACTIONFLOORLIMIT | This is the parameter which can be used to control the transaction amount below which transaction should go into SAF. | | TOTALFLOORLIMIT | This is the total limit for all transactions in the SAF table. Sum of All transaction amounts in the SAF table should not exceed this limit. | | SAFDAYSLIMIT | This configuration allows SCA to set a limit with regards to the total number of days the unit can be offline and accept SAF transactions. | | SAFMAXPENDINGTRAN | This parameter controls the maximum number of ELIGIBLE transactions that can reside in the terminal at any point of time. | | SAFONLINEPIN | This parameter controls the ability to allow SAF for transactions which actually includes a PIN. | | SAFTHROTTLINGENABLE/ SAFTHROTTLINGINTERVAL | This parameter allows the terminal to implement a staggered approach while posting the SAF transaction from terminal. | | SAFPURGEDAYS | This parameter controls the number of days that the processed transactions should remain in the Database. | | SAFPOSTINTERVAL | This parameter indicates the number of minutes between each SAF transaction posting. | | SAFPINGINTERVAL | This parameter indicates the number of minutes between each check for Host availability. | | CHECKFLOORLIMITTOSAFREFUND | This parameter controls the ability to check the floor limit during the process of SAFing a refund transaction. | | ALLOWCOMPLETIONTOSAF | This parameter controls the ability to store a COMPLETION transaction offline. | | ALLOWGIFTACTIVATETOSAF | This parameter controls the ability to store a COMPLETION transaction offline. There is a lesser risk for merchants here since the activation of a gift card is generally transfer from the merchant’s account to the customer’s gift card. | | ALLOWPRIVLBLTRANSTOSAF | This parameter controls the ability to store Private Label transaction offline. | | ALLOWGIFTTRANSTOSAF | This parameter controls the ability to store GIFT transactions offline. This parameter is used for other Gift commands apart from Gift Activate. | | ALLOWPREAUTHTOSAF | This parameter controls the ability to store a Pre-Auth transaction offline. | | ALLOWREFUNDTOSAF | This parameter controls the ability to store a Refund transaction offline. | | ALLOWVOIDTOSAF | This parameter controls the ability to store a Void transaction offline. | ## SAF Eligibility Check In order to SAF any transaction, SCA applies a series of checks to validate the SAF eligibility. All transactions and all payment types cannot be stored offline. SCA currently supports SAF of Credit and certain Gift transactions based on the configurations enabled on the terminal. The high-level eligibility logic is defined in the flow chart below. Refer to the flowchart in conjunction with the configuration parameter details mentioned in [Configuration Parameters](#Configuration-Parameters) section. Each merchant can choose to apply the configurations for SAF based on the level of risk that they are willing to accept. Some of the offline transaction supported is also limited based on the processor being used. ## Basic SAF (Complete Connectivity Loss) {% stepper %} {% step %} ### After card input After card input is received, a connection to the host is attempted. {% endstep %} {% step %} ### Connectivity fails Since there is complete connectivity loss, attempts to connect fail. {% endstep %} {% step %} ### Gateway / Host attempts * Gateway: After x number of attempts to connect to the gateway within its timeout. * Host: After x number of attempts to connect to the primary port within its timeout, followed by y number of attempts to connect to the secondary port within its timeout. {% endstep %} {% step %} ### Enter offline mode Enter offline mode. {% endstep %} {% step %} ### Eligibility checks The transaction is checked against eligibility criteria for SAF. {% endstep %} {% step %} ### Not eligible If no, then decline offline. {% endstep %} {% step %} ### Eligible If yes, then approve offline and add to SAF batch database. {% endstep %} {% step %} ### Finalize Send transaction result to POS. {% endstep %} {% endstepper %} ## Basic SAF (Partial Connectivity Loss) {% stepper %} {% step %} ### After card input After card input is received, a connection to the host is attempted. {% endstep %} {% step %} ### Packet sent Connectivity is ok, and the packet is built and sent to the host. {% endstep %} {% step %} ### Response timeout Connectivity fails after sending; the attempt times out while waiting for a response. {% endstep %} {% step %} ### TOR Since the approval request was sent but the response was not received, send a TOR (timeout reversal) — we are unsure if host recorded it. {% endstep %} {% step %} ### Enter offline mode Enter offline mode (SAF on Response timeout). {% endstep %} {% step %} ### Eligibility checks The transaction is checked against criteria to validate SAF eligibility. {% endstep %} {% step %} ### Not eligible If no, then decline offline. {% endstep %} {% step %} ### Eligible If yes, then approve offline and add to SAF batch database. {% endstep %} {% step %} ### Finalize Send transaction result to POS. {% endstep %} {% endstepper %} ## Basic SAF (Host Error) {% stepper %} {% step %} ### After card input After card input is received, a connection to the host is attempted. {% endstep %} {% step %} ### Packet sent Connectivity is ok, so the packet is built and sent to the host. {% endstep %} {% step %} ### Host response indicates error An error response is received from the host. {% endstep %} {% step %} ### Check SAF error codes If the response matches a configured list of "SAF" error codes, continue. If it does not match, decline offline. {% endstep %} {% step %} ### Enter offline mode Enter offline mode. {% endstep %} {% step %} ### Eligibility checks The transaction is checked against the SAF eligibility criteria. {% endstep %} {% step %} ### Not eligible If no, then decline offline. {% endstep %} {% step %} ### Eligible If yes, then approve offline and add to SAF batch database. {% endstep %} {% step %} ### Finalize Send transaction result to POS. {% endstep %} {% endstepper %} ## SAF Query Request Fields * FUNCTION\_TYPE * COMMAND * SAF\_STATUS * SAF\_NUM\_BEGIN * SAF\_NUM\_END * POS\_RECON * COUNTER * MAC * MAC\_LABEL Response Fields to POS The POS can send a command (Query SAF) to query the contents of the SAF record table. Below are the fields returned as part of this response. Not all the fields may be valid for all the processors and hence only the applicable fields for a transaction would be returned. * ACCT\_NUM * TRANS\_AMOUNT * INVOICE * PAYMENT\_TYPE * PAYMENT\_MEDIA * SAF\_NUM * SAF\_TOR\_NUM * SAF\_STATUS * SAF\_TOR\_STATUS * TROUTD * CTROUTD * AUTH\_CODE * CARD\_TOKEN * CVV2\_CODE * BANK\_USERDATA * BUSINESSDATE * TXN\_POSENTRYMODE * MERCHID * TERMID * LANE * STORE\_NUM * APPROVED\_AMOUNT * COMMAND * LPTOKEN * PPCV * AVS\_CODE * HOST\_RESPCODE * SIGNATUREREF * APR\_TYPE * PURCHASE\_APR * SVC\_PHONE * STATUS\_FLAG * RECEIPT\_TEXT * CREDIT\_PLAN\_NBR * ACTION\_CODE * PAYMENT\_SUBTYPE * AUTHNWID * TRANS\_DATE * TRANS\_TIME * CARD\_EXP\_MONTH * CARD\_EXP\_YEAR * CARD\_ENTRY\_MODE * EMV\_MODE * EMV\_CVM * EMV\_CHIP\_INDICATOR * POS\_RECON * AUTHNWNAME * ACCOUNT\_TYPE ### SAF Query Sample **Request** \SAF\ QUERY 1 … \REG2\ \ELIGIBLE\ **Response** | **Response - 1** | **Response - 2** | | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | |

\2 SAF RECORDS FOUND\OK\-1\\SUCCESS\1\2\\10.40\\5234561594\\5.20\123456\CREDIT\\MASTERCARD\\1235\\ELIGIBLE\759\17760K\\8834134431340010 | 0AB5DD\\M\
\/CustDataJANEKDOE\`\`\`\`\`00\\40055550019\\5.20\123456\CREDIT\\VISA\\1236\\ELIGIBLE\760\17760K\\8834134431340010 | 0AB5DD\\M\\/CustDataJANEKDOE\`\`\`\`\`00\

| \**0 SAF RECORDS FOUND**\OK\-1\\SUCCESS\1\0\\0.00\ | ## Response Code based SAF - Fiserv (WIP) There may be situations where the processor is unable to process the request fully due to issues with the host processing system or any other services being used for decrypting the card data. Such cases may be a glitch in the system for a minimal amount of time and hence it would be beneficial if the terminal is able to store such transactions offline and retry at a later stage. This helps merchant keep the sale transaction and move on to other customers in the queue. For Fiserv, there are two components in the host processing called **Datawire** and **Rapid connect**. **Datawire** acts like a bridge between the terminal and **Rapid Connect** is the front end for Fiserv’s acquiring system. There would be response codes returned from both these components back to the terminal. Application offline approves the transaction (SAF) based on specific result codes in the response from Fiserv those are configured through SAF\_ERROR\_CODES.DAT file. Currently when these result codes are returning, application will mark them as decline. Going forward (FDRC version 4.0.25 onwards), it will treat it as offline situation and then approves it offline if it meets the SAF eligibility criteria. At present, following response codes are identified as of this publication: ### Rapid Connect - SAF Response Codes | Response code | Description | | ------------- | ---------------------------------------------------------------- | | 402 | TransArmor Service Unavailable | | 906 | System Error. There is a problem with the host processing system | | 907 | Card issuer or switch inoperative or processor not available | | 909 | System malfunction or timeout | | 963 | Acquirer channel unavailable | ### Datawire - SAF Response Codes | Response code | Description | | ------------- | ----------------------------------------------------------- | | 200 | Processor Host Busy | | 201 | Processor Host Unavailable | | 202 | Connect error to Host (Rapid connect) | | 203 | Rapid connect disconnected , before sending response | | 205 | No Response from RC(host) | | 206 | Error while sending request , DW can no longer send request | | 405 | Request could not be processed | | 505 | NW error - Request not processed | | 008 | NW error - Request not processed | ## Reprocessing Declined SAF Transactions (Backlog) A SAF\_EDIT command will be introduced which provides provision to change the DECLINED status to ELIGIBLE from POS. With this feature, POS can control to retry the declined SAF forwarded transaction by marking the SAF status as ELIGIBLE. When the SAF status gets changed to ELIGIBLE, the transaction will be forwarded to processor/Gateway again. | ![](/files/13a3e8e35ee389027e91a640cfd6802d462a7eca) |

Thank you! We are the payments architects who
truly understand commerce. As payment architects we shape ecosystems for online and in-person commerce experiences, including all the tools you need… from gateways and acquiring to fraud management, tokenization and reporting. As commerce experts, we are here for you and your business. With our payment devices, our systems & solutions and our support. Everywhere. Anytime. So that your customers feel enabled, recognized and well taken care of, even beyond their expectations. Verifone. Creating omni-commerce solutions that simply shape powerful customer experiences.

| | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Verifone North America Development The Royal Center Four 11700 Great Oaks Way, Suite 210 Alpharetta, GA 30022 [www.verifone.com](http://www.verifone.com) | | --- | --- | Thank you — end of document. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.verifone.com/sca/tbd-documentation/sca-saf-reference-guide.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.