Fire Docs

Archives
Log in
Subscribe
August 4, 2026

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 as order.completed. It does not fire for orders injected as COMPLETED or CANCELLED. 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 be null or 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 — transactionStatus is PENDING and transactionId is usually empty. Fire overwrites the array with the real tenders when the charge settles, and emits order.completed. Reading the declared method as settlement evidence is the most common mistake with this event.

Updated in EN / ES / PT.


Read the full changelog

Don't miss what's next. Subscribe to Fire Docs:
← Newer 4 August 2026 — Subscribe to the changelog by email
Powered by Buttondown, the easiest way to start and grow your newsletter.