4. Checking transaction status

TransactionStatus answers one question: what happened to the last transaction? It exists for the moments when your POS does not know, after a crash, a network cut, or an abort race. Building it correctly is what makes your integration recoverable and resilient, to avoid duplicate transactions.

The request

POST /status with an empty request body:

"TransactionStatusRequest": {}

There is no transaction reference to supply. The terminal returns the status of the last or current Payment, CardAcquisition, or Reversal transaction, as a RepeatedMessageResponse wrapping the original response it produced — the same PaymentResponse (or other response), receipts included.

The recovery pattern

The canonical use is POS crash recovery:

  1. Your POS crashes (or loses network) after POSTing a payment but before reading the result.
  2. On restart, before doing anything else, send TransactionStatus.
  3. Match the repeated response against your journal: compare its SaleData.SaleTransactionID with the transaction you have flagged as sent but unresolved.
  4. Approved → record it (including POIData.POITransactionID); declined or aborted → record that.
  5. Result: Failure with ErrorCondition: NotFound means the terminal has no transaction to report — only then may the payment be treated as never processed.

The rule this enforces: never re-send a payment to resolve uncertainty. Re-sending is how duplicate charges happen — the terminal does not deduplicate. Status first, always.

Warning

The terminal reports the last transaction. Resolve any uncertainty before starting a new transaction — once the next payment runs, the previous result is no longer retrievable this way. On POS restart, the status check comes first, unconditionally.

Receipt reprint

The repeated response includes the receipt data, which makes TransactionStatus the mechanism for reprinting the last receipt (a "duplicata"): request the status and print PaymentReceipt[] again.

Related

  • How the message model works — the two transaction identities you match against your journal.
  • Troubleshooting: duplicate payment — the incident this operation prevents.