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.