Table Postpaid Ordering

When a customer scans a table QR code, OpenApp resolves the QR code to a restaurant location and POS table identifier. OpenApp then creates or joins a table session where customers can add selected products.

This flow is postpaid: customers can submit one or more batches of items to the POS during the table session, and payment happens later through Postpaid Bill Payment. OrderSubmissionRequested does not include payment in this flow.

For prepaid ordering in any fulfillment context, including a table context, see Prepaid Ordering.

OpenApp asks the POS for the current table or open-check state when the session starts, when state must be refreshed, and before payment-sensitive actions. The POS returns either the current table state or a rejection reason.

This diagram is logical. It omits delivery-mode details; see Architecture for the delivery model.

Message types:

Message type	Direction	Purpose
TableOrderSnapshotRequested	OpenApp -> POS	Request the current POS table or open-check state.
TableOrderSnapshotResolutionResult	POS -> OpenApp	Return resolved table state or rejection details.
OrderSubmissionRequested	OpenApp -> POS	Submit selected postpaid table-session products to the POS order.
OrderSubmissionResult	POS -> OpenApp	Confirm accepted products or reject products with business reasons.

Typical rejection reasons include out of stock, insufficient stock, delisted item, closed order, and price changed. See Mutation rejection reasons.

POS Order Changes

The POS should notify OpenApp about relevant POS-side changes to a table order. This includes waiter-added items, kitchen cancellations, delivered items, discounts, removed lines, and order closure.

OpenApp updates the customer-facing session and derives customer notifications internally. The POS does not need to target OpenApp users directly.

A successful TableOrderSnapshotRequested both returns the current table state and activates push delivery of TableOrderSnapshotChanged for this table. The first snapshot must include every order line currently on the POS check, including lines added by the waiter before the customer scan; OpenApp learns about pre-scan activity only through this initial snapshot. The POS maintains one stream per table; subsequent snapshot requests are idempotent reads. The stream terminates when the POS pushes TableOrderSnapshotChanged with changeType=ORDER_CLOSED, after which the POS stops pushing changes for the table until a new session is opened by a new TableOrderSnapshotRequested.

Message type	Direction	Purpose
TableOrderSnapshotChanged	POS -> OpenApp	Notify OpenApp about POS-side order state changes.

See Change types for the set of POS-side change reasons.