Skip to content

Cancellations

Sometimes an order cannot be fulfilled — the kitchen is buried, an product has run out, the customer changes their mind. Cancellation is structured rather than ad hoc: a reason from a list you define, a refund that follows your rules, and an optional fee that a permitted role can waive.

Everything is on one settings page:

  • Master switch — whether cancellation is available at all.
  • Staff cancellation — whether outlet staff may cancel, and in which statuses. Allowing it while an order is ACCEPTED or PROCESSING but not once it is READY is a common and sensible line.
  • Reasons — two lists, one for staff and one for your admin team.
  • Fees — optional, fixed or a percentage.
  • Refunds — automatic or manual, with a default method and an optional wallet fallback.
  • Permissions — per role: who may cancel, and who may waive the fee.
  • Notifications — whether the customer and the outlet are told.
  1. Open the order and choose Cancel. The action only appears in the statuses you allow.
  2. Pick a reason, and add a note if it helps (“customer rang to cancel”).
  3. Confirm. The customer is notified if you have that on, and the refund follows the rules below.

A cancelled order keeps its full detail in history — products, reason, who cancelled, any fee, the refund. Nothing disappears.

Two lists, because the two audiences cancel for different reasons.

Staff reasons ship as: out of stock, customer requested, outlet closed, delivery not possible, payment issue, other. Admin reasons ship as: fraud suspected, duplicate order, system error, customer requested, operational issue, other. Both are yours to edit, and a reason can be marked as requiring a note.

Structured reasons are what make the cancellation reports worth reading. Keep the lists short and unambiguous — the note field covers everything else.

A cancellation fee can be a fixed amount or a percentage of the order. Roles you permit can waive it during the cancel flow, which is the right tool for a loyal customer or an honest mistake.

The fee is deducted from the refund and tracked separately in reports, so your accounting stays legible.

For prepaid orders:

Setting What it does
Auto-process on cancel The refund fires immediately, with no second step for staff
Default method Where it goes unless staff choose otherwise
Allowed methods What staff may pick when refunding by hand
Wallet fallback Credit the wallet when a card refund fails or is not supported, rather than leaving it stuck

Two rules clear orders that were never going anywhere, and they live here rather than with the other automation:

  • Unaccepted orders — cancelled after a set time with nobody accepting, so a customer is not left waiting on a closed kitchen.
  • Unpaid orders — cancelled when payment was never completed, so they do not accumulate in the live list.

Both refund or release payment according to the rules above.

Permission Allows
Can cancel Cancel an order in the allowed statuses
Can waive cancellation fee Skip the fee during a cancellation

A common setup: managers can cancel and waive, counter staff escalate instead. Roles are managed in Users & roles.

Two independent switches: tell the customer when their order is cancelled, with the refund detail, and tell the outlet when a cancellation happens somewhere else — from the dashboard, for instance. Channels are covered in Customer communications.

Report Route
Cancellation Summary /reports/cancellation-summary
Cancellation List /reports/cancellation-list
Cancellation Fees Collected /reports/cancellation-fees-collected
Aging Pending Refunds /reports/cancellation-aging-refunds
Customer Cancellation Frequency /reports/cancellation-customer-frequency
Pending Refunds /reports/pending-refunds

Watch Customer Cancellation Frequency for serial cancellers, and the two refund reports for anything that needs a manual nudge.

Related: Editing & refunds · Order lifecycle · Refunds & disputes · Reports

Was this page helpful?