This allows a POS to update the status of an order.
Id assigned by the POS, may be the same as the orderId
Status to be updated
Some POS systems use a separate Id for the order Id
_id and the receipt that was printed for it (
receiptId). The latter is usually something human-friendly, while the former can be a long internal ID if a separate
receiptId does not apply, it's a good practice to default the value to that of the
orderId. The receiptId is a required parameter.
When a status is not supported, it can be skipped. It is, however, crucial to sync statuses back. Some channels will only mark the order successful when the status is
ACCEPTED or higher, and some channels take the
PREPARING state into account. The more data you can provide, the better the experience for the customer.
(For some channels, such as Takeaway.com, orders will not be retrieved if they aren't put to status
PRINTED. In this case, their support will call the restaurant if it takes more than five minutes to reach that status).
If you want to specify a reason for a status change (for instance when it failed), you can set the reason property.
The table below lists statuses and their corresponding integer value. There is no specific sequence of statuses as they will correspond to your POS workflow/processes. Deliverect does need to know when all POS processes have completed and are in the
Deliverect status tag
PARSED (system status)
received and parsed by Deliverect
RECEIVED (system status)
received by POS
received by POS and receipt is created
SCHEDULED (system status)
order has been received in Deliverect and is 'buffered', awaiting POS injection based on 'average preparation time' and 'pickup time'
DUPLICATE (system status)
order has been received multiple times on the POS due to a technical error
READY FOR PICKUP
ready for pickup
en route to customer
finalized, order is fully handled and no further status updates are coming
accepted by POS, but any other status updates unsupported by POS (to be avoided at all costs!)
CANCEL (system status)
should be voided. This status is applied by online channels when an order should be voided on the POS
has been voided on POS
POS RECEIVED FAILED
not received by POS
DUPLICATE should only be used if the order is already in the POS and was (accidentally) submitted a second time.
FINALIZED means that the order is finalised in the POS.
FINALIZEDdoesn't necessarily mean that the order has been delivered to the end customer!
FAILED is a status that should be used when the POS could not be reached, or when an order could not be processed correctly. For example, when a product is available on the merchant's online store but deleted in their POS account.
This is a status sent to the POS when we ask for it to be cancelled.
Such a request comes in at the orders webhook endpoint, as an order with the
CANCEL status. For more information and an example, look at the documentation for the Orders webhook. In the case of an order with status
CANCEL, Deliverect will resend that order to the POS, with the same
channelOrderDisplayId (information available on the Orders webhook page).
Your POS should never send an order status update request with this status to Deliverect.
This means that the order was canceled by the POS.
In case of an order with the CANCEL status, Deliverect will resend that order to the POS, with the same channelOrderId and channelOrderDisplayId (information at Orders webhook).
An example of an order status update request to Deliverect to confirm cancellation by the POS can be seen on the right. Select the example from the drop-down box.
- On the POS side, it should be made very clear to the user that the order needs to be canceled. Printing new tickets for orders that indicate the order was canceled (so the kitchen knows they don't need to prepare the order) is a correct way of doing this. Whether a canceled order should be voided or not is up to the logic of the POS.
- The POS should send Deliverect a status
CANCELED(110) back, so Deliverect knows the order has been canceled in the POS.