Customers and authorized staff can cancel/reject eligible orders before acceptance. Check the original order and its payment/refund record. Acceptance deadlines are set by Business Settings; there is no general accepted-order refund button.
Customer cancellation, staff rejection and acceptance expiry apply before the order is accepted. A refund's money state is separate from the order's visible terminal status.
Which orders can be cancelled or rejected#
Before acceptance, the customer can cancel an eligible pending order and staff can reject it. A pending order can also expire at its server-recorded acceptance deadline.
After acceptance, Restaurant provides no general order cancellation or accepted-order refund feature. Do not promise that pressing a later status button reverses an accepted sale. Resolve the actual customer obligation through the supported fulfillment/recovery process.
What happens to held payment#
Confirmed pending payment sits in escrow1. Eligible cancellation, rejection or expiry starts a durable refund2 to the original character and payment account. It does not credit the restaurant's available balance or choose a different online player.
For example, a bank-paid order is refunded through its original bank path; a cash-paid order follows its original cash path. Do not replace a queued bank refund with an untracked cash grant and leave the original operation pending.
Understand the refund state#
| Situation | Expected behavior |
|---|---|
| Original character and account available | Worker can attempt the queued credit |
| Original character offline | Refund remains queued for the supported original-character path |
| Provider definitely rejects a credit | Retry policy can handle the definite failure |
| Credit result cannot be established | Operation needs review; no blind automatic repeat |
| Credit confirmed | Refund is completed and reported through the normal notification/state |
My Orders where customers inspect the selected order and payment/refund information independently from its status.
A Cancelled or Rejected order does not necessarily mean the credit has already arrived. Customers should read the payment notice and retain the order reference. Returning to the original character may be required for the queued account path.
Acceptance deadlines and downtime#
The configured acceptance duration is captured as the order's persisted deadline. Later config changes do not retroactively create a new deadline for that existing order.
If the resource is offline when a deadline passes, maintenance processes it after resuming. Offline time is not a promise to preserve an indefinitely pending paid order. Use the server order/payment state after restart.
When review is required#
An uncertain outcome3 means the provider may have applied the credit even though confirmation failed. The administrator must compare the original operation with the provider account records and record the verified result with evidence. Current balance alone may be insufficient because later transactions can change it.
The reconciliation action records what already happened; it does not issue the money again. Preserve the operation and order IDs. See Banking and Recovery.
Closing or deleting the restaurant#
Stop new orders independently when ending a shift. Unfulfilled paid obligations and unresolved customer payment/refund outcomes can block disabling, required-location/product removal or deletion. Do not remove the business first and expect deletion to return its remaining balance automatically.
Use Enable, Disable and Delete for the operational consequences. Use Customer Menu for the customer's available cancellation action.
Footnotes
-
Customer money held while a paid order is waiting for staff acceptance. Read the definition. ↩
-
Returning eligible customer money to the character and payment account that paid for the order. Read the definition. ↩
-
A money or item transfer whose final result could not be confirmed. Read the definition. ↩