Order Cancellation
Introduction
When an order is cancelled, the cancellation notification is sent to the endpoints of type Cancelled order notification defined in the Integrations Portal.
To configure them → POS Endpoints Management
SINGLE ATTEMPT
The cancellation notification is sent once per configured endpoint. There is no automatic retry if the endpoint returns an error or does not respond.
Format
The payload is JSON and is forwarded verbatim, without reprocessing. Any new field or value reaches the endpoint untouched.
{
"order_id": "101614832566",
"store_id": "TEST__111111",
"cancel_reason": "PRODUCTS_NOT_AVAILABLE",
"payment_strategy": "PAY_NOTHING"
}| Field | Description |
|---|---|
order_id | Identifier of the cancelled order — matches the order_id field of the original notification |
store_id | The order's store, in PREFIX__storeId format |
cancel_reason | Reason for the cancellation |
payment_strategy | Whether the order products are paid to the partner |
Expected response
Any 2xx code. The response body is not read.
cancel_reason
| Value | Description |
|---|---|
PRODUCTS_NOT_AVAILABLE | Products are not available in store |
STORE_CAN_NOT_DELIVER | Order could not be delivered by the partner |
PARTNER_PRINTER_ISSUE | Cancelled due to an issue with the partner's device |
USER_ERROR | The customer cancelled the order |
ORDER_NOT_FEASIBLE | The customer's request cannot be fulfilled |
OTHER | Other reasons that do not fall into the categories above |
VALUES SENT
The values sent on cancel_reason are those listed in the table above. STORE_ERROR is not part of the enumeration.
payment_strategy
| Value | Description |
|---|---|
PAY_NOTHING | Order products are not paid to the partner |
PAY_PRODUCTS | Order products are paid to the partner |
PAY_WASTED_PRODUCTS | Already prepared products are paid |
The field may also arrive as null.
There is no fixed correspondence between cancel_reason and payment_strategy. The value depends on the moment of the cancellation and on the store type.
Extensible enumerations
STORE AS TEXT
Both enumerations may be extended with new values.
The recommendation is to store both fields as text rather than as an enum. Strict deserialization will fail on an unknown value.