3. Aborting a transaction

Abort cancels the operation that is currently in progress, typically a payment waiting for the cardholder. It is the "cashier presses cancel" path. For undoing a completed payment, use Reversing a transaction instead; Abort only works while the transaction is in flight.

The request

POST /abort. The abort terminates the on-going operation on the terminal, there is only ever one (the one-operation-at-a-time rule), so no transaction lookup is involved:

"AbortRequest": {
  "MessageReference": {"MessageCategory": "Payment", "SaleID": "POS_01", "POIID": "POI_01"},
  "AbortReason": "Abort requested by POS."
}

The MessageReference block is part of the Nexo message structure and names the category being aborted; the terminal simply aborts whatever is currently in flight.

Aborting a two-step (card acquisition) payment

A payment running inside the dual flow is aborted differently, with an AdminRequest whose ServiceIdentification carries base64-encoded JSON ({"Action": "DualTransactionAborted", ...}). If you use Card acquisition and two-step payments, wire this variant; a plain AbortRequest does not stop a dual-flow payment.

What comes back

Abort has no meaningful response of its own. The outcome arrives as the original operation's response:

• If the abort succeeded, the pending GET poll on /payment returns 200 with Result: Failure, ErrorCondition: Aborted.
• If there was nothing to abort (the transaction had already completed), the terminal emits an EventNotification, and the original response, if any, stands.

This means your polling loop keeps running after you send an Abort: the abort's effect is visible in the poll result, not in the abort call.

Timing reality

Abort is best-effort. If the cardholder has already presented the card and authorisation is under way, the abort may arrive too late, the payment completes approved. Your POS must handle "abort sent, payment approved anyway": the correct follow-up is a Reversal of the completed payment, and your UI should make that path obvious to the cashier rather than assuming the abort won.

Related

• Checking transaction status: determine the actual outcome when timing is unclear.
• Reversing a transaction: the follow-up when abort arrives too late.