Order lifecycle, receipts & refunds
Every status an order can hold, how a restaurant ticket travels from kitchen to payment, and exactly what a refund reverses.
The statuses
Dashboard → Orders
| Status | Meaning |
|---|---|
| Draft | Started but not sent anywhere yet |
| Sent to kitchen | On the kitchen board, waiting to be worked |
| Preparing | Kitchen is cooking it |
| Ready | Prep is done, waiting to be served or collected |
| Served | With the customer, not yet paid |
| Awaiting payment | The bill has been presented |
| Paid | Money received in full |
| Completed | Finished and closed |
| Pending / Processing | Older simple flow — placed, not yet closed |
| Cancelled | Called off; stock reversed |
| Refunded | Money returned; stock reversed |
Retail branches usually go straight from placed to paid to completed, because the money arrives at the same moment as the goods. Restaurants use the longer fulfilment flow, because the food goes out well before the bill is settled.
A restaurant ticket, end to end
Two rules govern this chart: nothing reaches Paid or Completed until payment is recorded, and Refunded or Cancelled is the end of the line.
Read this diagram as text
- Draft → Sent to kitchen
- Sent to kitchen → Preparing
- Preparing → Ready
- Ready → Served
- Served → Awaiting payment
- Awaiting payment → Payment recorded?
- Payment recorded? → Refused: payment must be received first (no)
- Refused: payment must be received first → Awaiting payment
- Payment recorded? → Paid (yes)
- Paid → Completed
- Paid → Cancelled or Refunded (refund)
Goods and money change hands together, so a retail sale usually settles in one step — unless it is paid by M-Pesa, which waits for confirmation.
Read this diagram as text
- Order placed → Tender settles at the till?
- Tender settles at the till? → Paid (cash, card…)
- Tender settles at the till? → Pending (M-Pesa)
- Pending → Confirmation arrives?
- Confirmation arrives? → Failed (no)
- Confirmation arrives? → Paid (yes)
- Paid → Completed
An order cannot be marked Paid or Completed until payment is recorded
The rule is enforced on the server, not just hidden in the interface. If you try, you are told that payment must be received first. Record the payment — including a split-payment breakdown — and the status will move.
Move an order along
Dashboard → Orders → open an order
Open the order from the Orders list.
Set the new status.
You need either Create orders or Kitchen permission; kitchen staff can advance tickets without touching money.
What the status control will not do
- It cannot cancel or refund — those run through flows that also reverse stock and money.
- It cannot touch an order that is already refunded or cancelled; those are closed for good.
- It cannot mark an unpaid order as paid or completed.
Find an order
- Dashboard → Orders lists this branch's orders with number, status, payment status, total and date.
- Filter by status, payment status, payment method and date range; sort by any column.
- Organization → Orders shows every branch in one list for a head-office view.
- Opening an order shows its line items, totals, customer details, notes and its transactions.
Receipts
Open the order and click Print Receipt.
The receipt prints in thermal-printer format.
It carries the branch contact block, the header and footer notes from branch settings, and the paid/served stamp if that setting is on.
Open the order and enter the customer's email address.
Click Email.
An HTML receipt is sent. An invalid address is rejected before anything is sent.
Refund an order
Open the paid order you need to reverse.
Click Refund order.
You need the Refund orders permission; owners, admins and branch managers hold it implicitly.
A refund is not a status change — it unwinds the sale across stock, loyalty and the audit trail in a single transaction.
Read this diagram as text
- Refund order → Paid, not already refunded, and you hold the permission?
- Paid, not already refunded, and you hold the permission? → Refused with the reason (no)
- Paid, not already refunded, and you hold the permission? → Stock returns (yes)
- Stock returns → Earned points taken back
- Earned points taken back → Order marked Refunded
- Order marked Refunded → Written to the audit log
What a refund reverses
- Retail: each line's quantity goes back to on-hand and its sold counter comes down.
- Restaurant: the dish's sold counter comes down and every recipe ingredient it consumed is returned to stock.
- Loyalty points the sale earned are taken back off the customer's balance.
- The order moves to Refunded and can no longer change status.
- The action is written to the audit log against the member who performed it.
Only paid orders can be refunded, and only once
An unpaid order has no money to return — cancel it instead. An already-refunded order is rejected, so a double-click can never refund twice.
M-Pesa money is not sent back automatically
A refund reverses the sale, the stock and the points inside Wezo. Returning mobile-money funds to the customer is done through your M-Pesa account as a separate step.
Voiding versus refunding
| Void | Refund | |
|---|---|---|
| Use when | The order should never have existed | A real sale is being reversed |
| Money | Nothing was taken | Money was taken and goes back |
| Permission | Void orders | Refund orders |
| Audit trail | Logged | Logged |
The question is only ever whether money moved.
Read this diagram as text
- Order is wrong → Has money been taken?
- Has money been taken? → Void it (no)
- Has money been taken? → Is the order marked paid? (yes)
- Is the order marked paid? → Refund it (yes)
- Is the order marked paid? → Record the payment first (no)
Keep voids for mis-keyed tickets caught before payment. Once money has changed hands, refund — it leaves the honest trail an accountant and the tax authority both expect.