Ingenico Developer Guide 2.03.024-028
Ingenico Download Configuration and Troubleshooting Guide 2.03.024-028
Telium Developer Guide 2.02.021
Verifone Developer Guide 2.19
Verifone Download Configuration and Troubleshooting Guide 2.19
Verifone Guides 2.18
Implementing TLS 1.2 to Simplify
Simplify Payment Process
After the Simplify Pay@Table process sends a Make Payment Request, the next steps in processing a Pay@Table transaction are performed by the Simplify Payment process. For supported Tran Types, this processing is identical to that performed by Simplify for non-Pay@Table transactions:
The POS builds and sends a financial request to Simplify.
Simplify display screens to obtain customer account data (including PIN if debit).
Simplify builds and sends the host request to Fusebox.
Fusebox attempts to obtain transaction authorization and sends the host response to Simplify.
Simplify processes the host response, and builds and sends a financial response to the POS.
The type of financial request that the POS should send is determined by the Type of Transaction field (5217) that it receives in the Make Payment Request. If the value in this field is 01, the POS should send an Auth Only Request. (As always, if an Auth Only Request is sent, a Completion transaction will also need to be performed.) If the value is 02, a Sales Request should be sent, and if 09, a Return Request.
Stand-In is supported for Pay@Table transactions using current rules (as defined under Stand-in Processing). Cashback is not supported on Pay@Table transactions.
If a timeout or other communication error occurs while waiting for a financial response, the POS can send an Inquiry Request if required to recover the financial transaction.
If the POS cannot post an approved transaction, it must decline the transaction and inform Simplify of the transaction decline. This can be done by sending Simplify a Void Request.