The Store and Forward feature allows the client to run a transaction without sending it to the processor right away. From the cardholder's perspective, the transaction is performed as usual, but triPOS stores the transaction in a local database until the client tells triPOS to forward it to the processor. This functionality is broken down into two separate actions.
First, store the transaction by sending a normal request with the additional query string ?action=store. Sale, Authorization and Refund may all be stored.
triPOS completes the transaction, without sending it to the processor, and stores it in its local database. If the transaction is stored successfully without error,
triPOS returns a response indicating that the transaction was accepted. It is very important to keep in mind that,
at this point, the transaction has only been "approved" locally. This means that triPOS accepted the transaction successfully but has NOT sent it to the processor for
approval. To clearly indicate that the transaction has not been processed online, triPOS returns an HTTP status code of 202 Accepted instead of the normal HTTP
status code of 200 OK. Additionally, triPOS returns a statusCode of ApprovedByMerchant instead of the normal statusCode
of Approved. With the addition of the automatic store feature, triPOS now returns a new response value isOffline that will be set to true if
triPOS is offline. Since the transaction has not been sent to the processor, some response fields will be empty if their values
come from the processor response. If the transaction is stored successfully, it can be identified by the request ID that
is returned in the header field tp-request-id of the store response.
Second, forward the transaction to the processor by sending a normal request with the additional query string
?action=forward&requestIdToForward={requestId
from store}
. Since triPOS supports storing three kinds of transactions, the client should keep track of which type of transaction corresponds to each tp-request-id.
The client may also use the GET /api/v1/storedTransactions endpoint described in the Automatic Store and Forward documentation to obtain the transaction
type of each stored request. When triPOS receives a forward request, it pulls the stored transaction with the given requestIdToForward from the database and sends
it to the processor. At this point, triPOS returns a normal response that is complete with processor response values. For each forwarded request, triPOS logs the
requestIdToForward, the result of the transaction and its transactionId from the processor as an >INFO log message for reference.
In the case of a transaction that requires a signature, the signature is obtained during the store action
while the cardholder is present, so the forward response returns a signatureStatusCode of SignatureNotRequiredByTransactionType.
If the stored transaction is never forwarded to the processor, the transaction will not be processed and it will not make it into the merchant's batch.
Once a transaction is successfully forwarded to the processor, triPOS will update the state of the stored transaction to Processed.
When using the Store and Forward feature, errors can occur. It is important to understand how triPOS will behave in each error case to fully understand the scope of the
liability taken on by the client.
If triPOS attempts to forward a request, either manually or automatically, and cannot communicate with Express or Express cannot communicate with the processor, then triPOS sets the
state of the transaction back to Stored and considers itself offline. The forward can be retried when network connectivity is re-established.
If the data stored in the database becomes corrupt, preventing triPOS from constructing a valid Express message, triPOS will set the state of the transaction to Error.
At this point, triPOS will not be able to forward this transaction to the host. Depending on how the data is corrupted, the client may not even be able to execute a successful query
to obtain information about the transaction.
Lastly, if triPOS receives a successful response from Express, even in cases such as Decline or Duplicate, triPOS will consider the request successfully processed and
will set the state of the transaction to Processed.
There are two methods that can be used to void a transaction. triPOS v5.15 introduces a DELETE /api/v1/storedtransactions/{requestIDToDelete} endpoint, which can be used to void a transaction from the local SQL database so that it is not sent to a processor. Alternatively, the integrator can choose to void a transaction by using the transaction ID obtained from the original transaction and send the void directly to Express.
At that point, only when triPOS is online, the client can send a
request to POST /api/v1/void/{transactionId} for triPOS to void the transaction.
In the current version of Store and Forward, triPOS does not provide a mechanism to store an authorization completion, or to complete a stored authorization offline.
In order to perform an authorization completion, the client will first need to forward the stored authorization online to obtain a transactionId from the processor.
At that point, only when triPOS is online, the client can send request to POST /api/v1/authorization/{transactionId}/completion for triPOS to complete through the processor.
The database mentioned above is a SQLite database that exists on the same machine as triPOS. The database does not need to be installed separately
because triPOS creates the database upon startup. In this phase of the Store and Forward feature, triPOS provides a way to delete records from the database
via the DELETE /api/v1/storedtransactions/{requestIDToDelete} method regardless of its state.The S&F database archives transactions.
If the database reaches capacity, older transactions will have to be purged to make room for new transactions.Alternatively, a new S&F database can be established for continued archive use.
Once the transaction is forwarded to the processor, it is still possible for the processor to decline it. Storing the transaction with triPOS does not guarantee the transaction will be approved.
Store and Forward only supports credit capable cards, and does not allow EMV transactions that require an online PIN. If a refund transaction requires online PIN, it will be accepted and stored, but the cardholder will not be prompted for a PIN. If a credit EMV transaction allows cashback, cashback will not be supported when storing. Make sure that the tp-request-id provided in the header is unique, otherwise the attempt to store the transaction will fail.