The Store and Forward feature allows a 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. It is broken down into two separate actions.
First, store the transaction by sending a normal request with the additional query string ?action=store.
triPOS completes the transaction, without sending it to the processor, and stores it in the database. If the transaction is completed successfully and triPOS is able to store
the transaction without any errors, 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 indicate this,
instead of the normal HTTP status code of 200 OK for a successful transaction, triPOS returns an HTTP status code of 202 Accepted. Additionally, instead of the normal response statusCode
of Approved, triPOS returns a response statusCode of ApprovedByMerchant. Since the transaction has not been to the processor, some response fields
may be empty if their values usually 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 previously
stored all of the information necessary to process the transaction, it is likely that the only body parameter required in the forward request is the laneId. 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 response as if it had performed the transaction from
start to finish, complete with processor response values. In the case of transactions that typically require 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 actually be processed or make it into the merchant's batch.
The database mentioned above is a Sqlite database that exists on the machine with triPOS. The database does not need to be installed because triPOS creates the database the first time it needs to use it.
If the forwarded transaction makes it to the processor successfully (regardless of the outcome of the transaction), triPOS deletes the stored transaction from the database. For each forward request,
triPOS logs the requestIdToForward, the result of the transaction from the processor, and the transactionId from the processor as an INFO log message for reference. However, none of the other response
values are logged.
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. Even if the transaction is declined by the processor, it will still be deleted from the database.
Store and Forward only supports credit capable cards.