Cancel a transaction

Outlines cancelling a payment before it has finished processing.


Sometimes shoppers change their mind about something as a payment is in progress, and store staff will need to be able to cancel the in-progress payment. Implement an AbortRequest to handle this scenario.

Endpoint

The URL used to send  Terminal API  messages depends on your type of implementation. For more information on the architectures available, see the Terminal API Overview .

Request

For a list of Abort Request fields, see AbortRequest fields.

The SaleID and ServiceID in the MessageHeader should be unique. SaleID and ServiceID combinations are rejected if used recently, within 48 hours.

AbortRequest
{
   "SaleToPOIRequest" : {
      "AbortRequest" : {
         "AbortReason" : "MerchantAbort",
         "MessageReference" : {
            "SaleID" : "POSSystemID12345",
            "ServiceID" : "21795",
            "MessageCategory" : "Payment"
         }
      },
      "MessageHeader" : {
         "MessageType" : "Request",
         "MessageCategory" : "Abort",
         "MessageClass" : "Service",
         "ServiceID" : "26319",
         "SaleID" : "POSSystemID12345",
         "POIID" : "MX925-260193322",
         "ProtocolVersion" : "3.0"
      }
   }
}

The ServiceID in the MessageReference object must match the current running transaction. If the SaleID or the POIID is absent, it will be taken from the MessageHeader. Both values should also match the current transaction.

The AbortRequest should be issued as a separate http(s) request.The original transaction (if not yet completed) will return a result indicating it has been aborted. Future versions of this implementation will generate various event messages.

No response is generated on an AbortRequest. It is not possible to determine the success of an abort other than inspecting the response generated by the original transaction.