Point-of-sale icon

Verify transaction status

Learn how to verify the status of a transaction when you don't receive a response.

When you make a transaction, a communication or technical issue can prevent your POS app from receiving a response. Without this response it is unclear to your staff if the transaction has been processed. They may try to cancel or refund the transaction, or repeat the transaction.

Instead, your integration should request the transaction's status to verify whether the transaction is:

If the transaction has been processed you also receive the original transaction response, indicating the result.

If you are making frequent transaction status requests then you may have a network connectivity issue. Make sure that your terminal is connected to the internet, and see our network recommendations.

Check the transaction status

We recommend that your integration automatically checks the status of a transaction any time it fails to receive a transaction response.

Payment requests time out after a while. If you do not receive a payment response (or you receive a response indicating a time-out) after 120 seconds (local integration) or 150 seconds (cloud integration), and the internet connection hasn't dropped, your integration should automatically check the transaction status.

To get the status of a transaction:

  1. Make a POST request to a Terminal API endpoint, specifying:

    If you're using cloud communications, make the request to a /sync endpoint.

    Parameter Required Description
    ProtocolVersion -white_check_mark- 3.0
    MessageClass -white_check_mark- Service
    MessageCategory -white_check_mark- TransactionStatus
    MessageType -white_check_mark- Request
    SaleID -white_check_mark- Your unique ID for the POS system component to send this request from.
    ServiceID -white_check_mark- Your unique ID for this request, consisting of 1-10 alphanumeric characters. Must be unique within the last 48 hours for the terminal (POIID) being used.
    POIID -white_check_mark- The unique ID of the terminal to send this request to. Format: [device model]-[serial number].
    • TransactionStatusRequest:

      • ReceiptReprintFlag: true

      • DocumentQualifier: Receipt data you want to receive in the response. Can be one or both of:

        • CashierReceipt: cashier receipt, including signature data.
        • CustomerReceipt: shopper receipt.

      • MessageReference: this object is optional. If you do not include it you receive the status of the most recent transaction made by the terminal that you route the transaction status request to.

        • SaleID: the SaleID of the POS system component that made the original transaction.
        • ServiceID: the ServiceID of the original transaction.
        • MessageCategory: the original transaction type, either:

          • Payment: payment request.
          • Reversal: refund request.
          • StoredValue: request to activate or load balance on a gift card.

    The example below shows how to check the status of a payment with the ServiceID 29235.

    For a complete list of fields you can pass when requesting a transaction status, see the TransactionStatusRequest API reference.

  2. In the response, check the TransactionStatusResponse.Response.Result. This indicates whether the transaction has been processed:

    • Success : the transaction has been processed. The original transaction response is also provided.
    • Failure: the transaction has not been processed. The reason is indicated by the ErrorCondition:

    For an example of each result, see the next sections.

Transaction processed

A TransactionStatusResponse.Response.Result of Success indicates that the transaction reached an end state: approved, cancelled, or declined.

To determine the result of the transaction, use the original transaction response, provided in the RepeatedResponseMessageBody. For example:

  • PaymentResponse.Response has Result Success: the payment succeeded.
  • PaymentResponse.Response has Result Failure and ErrorCondition Aborted: the payment was cancelled from the POS app.
  • PaymentResponse.Response has Result Failure and ErrorCondition Cancel: the payment was cancelled from the terminal.

See the TransactionStatusResponse API reference for a processed transaction.

Transaction in progress

A TransactionStatusResponse.Response.ErrorCondition of InProgress indicates the transaction is still being processed. This is usually due to the terminal waiting for input from the shopper. For example, the shopper is entering their PIN, adding a tip, or selecting currency conversion.

When you receive an InProgress response, you can submit repeated transaction status requests in a loop until you receive a response that indicates the transaction reached an end state. There is no need to apply a polling delay, because the terminal will handle that for you.

The example response below indicates that this transaction is still in-progress.

See the TransactionStatusResponse API reference for an in-progress transaction.

Transaction not found

A TransactionStatusResponse.Response.ErrorCondition of NotFound indicates that we were not able to find the transaction with the SaleID and ServiceID you specified. The AdditionalResponse has Message not found and echoes the category of the transaction (such as Payment), the SaleID, and the ServiceID you specified in the request.

When the transaction is not found, this means that either:

  • The POIID, SaleID or ServiceID you specified in the transaction status request are incorrect. Check that you provided the POIID, SaleID, and ServiceID from the original transaction in the TransactionStatusRequest.MessageReference.
  • We did not receive the original transaction request. The cause can be a dropped internet connection or an unexpected power loss. You can retry the original transaction.

The example response below indicates that this transaction was not found.

See also