2 August 2026 — order.opened and the deferred-payment blocks
2 August 2026 — order.opened and the deferred-payment blocks
Each event advances on its own version line — there is no global contract number:
| Event | Version |
|---|---|
order.opened |
v1 (new event, first version) |
order.completed |
v1 → v1.1 |
order.invoiced |
v1 → v1.1 |
order.cancelled |
v2 → v2.1 |
Every addition is backward-compatible (new blocks on an existing shape). Nothing here changes a field you already read, and the previous contract of each event stays online behind its version tab.
- New event
order.opened— fires when an order is injected already open: it exists, the kitchen can start, nobody has paid yet. Carries the same V4 snapshot asorder.completed. It does not fire for orders injected asCOMPLETEDorCANCELLED. This event has no v0 — it was born at v1. data.policy.deferredPayment— added to all four order events (order.opened,order.completed,order.invoiced,order.cancelled). Says whether the order may be cooked, invoiced or dispatched before payment. Resolved once at injection and stamped immutably; every later event echoes the same value.data.lastKnown— added to the same four events. Advisory snapshot of kitchen and fiscal state. Never gate an irreversible action on it — it may benullor stale, and Fire itself ignores it and re-reads from source before issuing anything.
Note On
order.opened,payments.paymentMethods[]is what the POS declared, not what was charged —transactionStatusisPENDINGandtransactionIdis usually empty. Fire overwrites the array with the real tenders when the charge settles, and emitsorder.completed. Reading the declared method as settlement evidence is the most common mistake with this event.
Updated in EN / ES / PT.
Don't miss what's next. Subscribe to Fire Docs: