Skip to main content
An order is a confirmed purchase — items, totals, store, channel, and how it will be fulfilled. Fire spark receives orders from every connected channel and routes them into your POS or RMS so the kitchen sees one consistent ticket flow.

​
What defines an order commercially

​
Why unified orders matter

Without a hub, each channel sends orders through a different path. Support cannot see full history; finance reconciles per platform; operations juggle multiple tablets. With Fire spark, orders from all channels enter the same operational stack. Commercial and support teams can reason about volume and mix across channels, not only inside one app.

​
Orders and customer experience

  • Owned channels — You often know the customer and can support reorder and loyalty.
  • Aggregators — The marketplace owns much of the UX; your focus is accurate menu, timing, and handoff.
Fire spark does not replace aggregator customer service rules; it ensures the operational side of every order is reliable.

​
How an order is paid

Tenders live on a payment intent, not as a single payment on the order. Save them while the cart is OPEN, then place locks the intent. Fulfillment waits on the PAYING step until the tenders in that step’s scope are settled. If nothing has been captured yet, reopen voids those tenders and returns a new OPEN order. Optional order_id can be any id from genId (genOrderId is one option: default ord-<store>- plus 12 alphanumeric characters; length is at least 8, default 12, and format can change the hash). A literal may sit next to the hash, as in genId().literal("BB21921").hash(8, "numeric").build() (BB2192100000001). Omit order_id and the generated id stays. The two orders point at each other in metadata.reopen. That new order can be reopened again the same way once it is placed and still cancelable.

Channels

Where orders originate

Fulfillment

How orders complete

Stores

Where orders are prepared