The code opens the merchant's public menu with its configured table number attached.
Generate the starting point from the restaurant account
An authenticated LiftedPOS operator can request an SVG QR for a table number. The generated destination uses the merchant's company prefix on LiftedPOS.com and opens the guest ordering route with that table attached. That gives a restaurant a printable, table-specific starting point without creating a disconnected menu account or asking a guest to install an application.
Printing, placement, camera behavior, lighting, guest Wi-Fi, cellular coverage, and physical table mapping still belong in rollout testing. A working SVG does not prove that a laminated stand, a dim dining room, or every phone camera will perform the same way. The launch checklist should scan every printed code from the seat where a guest will use it and confirm that the displayed table matches the physical table.
Publish the menu the guest can actually order
The guest surface loads the restaurant or hybrid tenant's categories and sellable simple products and variants. Product name, description, image, current price, category, brand, and taxability are available to the menu. Guests can switch categories, open a product, add it to the cart, change quantities, remove it, and optionally provide a name before placement.
The browser presents a useful subtotal, tax estimate, and total, but it is not allowed to declare the money authoritative. The order request carries product identities and quantities rather than accepting client-supplied prices. LiftedPOS loads the products again, rounds each line, separates taxable from non-taxable lines, applies the configured tenant tax rate, and persists the server result. If tax has not been configured, the route fails closed instead of silently treating the order as tax-free.
Reject a table that the restaurant does not recognize
A table number supplied by the guest flow must match a configured restaurant table. That guard matters because a copied or edited URL should not manufacture a ticket for a nonexistent destination. The current rail also retains a blank-table path for the existing no-table or takeaway behavior, but the table-specific restaurant experience is validated against the live table list.
Order size and per-item quantity are capped before the tenant database work begins. Suspended, cancelled, or expired tenants do not expose the public menu. The public endpoints are rate-limited, and QR ordering is available only for restaurant-style business types. Those controls are part of making a guest-accessible surface safe enough to connect to real restaurant work.
Hold the order where staff can make the decision
A successful placement creates an order in pending state, records its line items and server totals inside one transaction, and broadcasts a new-order notification to the restaurant. The staff view can list pending and accepted QR orders with table, guest name, money, time, and item detail. From that queue, an authenticated employee can accept or reject the pending order.
Acceptance is intentionally a separate state change. LiftedPOS atomically claims the pending order and creates the kitchen-pending record used by the KDS. Two employees cannot both successfully accept the same pending order. A rejected order does not enter production. This is why the page says that an accepted ticket routes to the kitchen rather than claiming automatic direct-to-kitchen acceptance.
Protect status access beyond a sequential order number
The placement response includes the order ID and an unguessable per-order status token. A status lookup must present both. A visitor who changes the sequential ID without the matching token receives the same not-found behavior as a missing order, reducing the chance that one guest can enumerate another table's name, total, or status.
The current guest confirmation shows the placed order number, table when present, item count, subtotal, tax, total, and pending state. The restaurant should train staff on how that pending order becomes accepted, rejected, paid, and reconciled. A guest confirmation is evidence that the order was stored—not that payment has happened or that the kitchen has begun making it.
Current product boundary
What this QR flow does not promise
The current guest rail does not include QR-side modifiers, guest preparation notes, tip entry, discount entry, online payment, card capture, delivery, scheduled pickup, order-ahead scheduling, waiter calls, or automatic direct-to-kitchen acceptance. Payment is completed at the POS after the restaurant follows its configured workflow.
Restaurants that require those guest-side capabilities should treat them as requirements to verify, not features inferred from the words “QR ordering.” LiftedPOS can still carry modifier and kitchen-note context from staff-entered restaurant orders, but that does not make those controls available on the current public QR page.
Evaluate the whole route before printing the room
Build a small published menu with taxable and non-taxable products, images, and categories. Generate codes for two real tables. Scan each from a guest phone, create a one-item and a multi-item cart, compare the browser preview with the server confirmation, and try an edited nonexistent table. Confirm that the order appears in the staff queue, that reject keeps it out of the KDS, and that accept creates one—not two—kitchen tickets.
Then validate the payment and closeout procedure, because the QR flow does not take online payment. Confirm who owns a pending order during a rush, what the guest is told, how staff match the order number, how the restaurant handles an unavailable product, and what happens if the guest loses connectivity after placement. The useful question is not “do you have QR codes?” It is whether the restaurant can trace the guest's action through every controlled state.