Skip to content
DataRestro

QR table ordering

Guests order from the table, straight to the kitchen.

Each table gets a QR code. The guest scans it with their phone camera and orders from your menu without an app or an account. The order reaches your POS and kitchen with the table number on it, so nobody types it in again.

Try it in the demoGet started

QR table ordering works today when the restaurant is online. Paying from the phone needs your own payment gateway account. Ordering over the restaurant's Wi-Fi during an internet outage is not built yet. The menu shown is sample data.

Table 12 · Thamel

Himalayan Kitchen

  • Chicken Momo

    Steamed, 10 pcs · tomato achar

    Rs 320

    1

  • Jhol Momo

    In sesame-tomato broth

    Rs 360

  • Dal Bhat Set

    Seasonal tarkari, pickle, papad

    Rs 450

  • Masala Chiya

    Milk tea, cardamom, clove

    Rs 90

  • Sekuwa is 86’d tonight, so it isn’t listed.

Pay at the counter when you leave

Meanwhile, at the pass

POS · OrdersWaiting

Place the order on the phone.

Submit requests

Idempotency-Key: qr-order-7f3a91c2

One key per basket. Tap Place order two or three times, like a guest on bad Wi-Fi.

Where it works: Dining room

Walk the whole restaurant

What happens after a guest scans the code

The guest scans, sees your menu, picks dishes and options, and sends the order. It is the same order record the POS uses, so it goes to the kitchen, appears on the bill and counts in the reports without anyone copying it across.

  1. 1The guest menu is your POS menu. Change a dish or a price once and every table sees it.
  2. 2Variants and modifiers (half or full plate, spice level, extras) are priced the same way as at the till.
  3. 3Guests can call a waiter or ask for water or the bill from the same screen. Requests show up on staff screens.

Step

  1. 01ScanGuestPoints the camera at the card on table 7.HouseNothing yet. No app, no login, no download.
  2. 02Table identifiedGuestLands on the menu for this restaurant, already at table 7.HouseThe opaque token resolves to one active table, server-side.
  3. 03MenuGuestBrowses your live menu, the same one the POS rings.HouseUnavailable dishes are filtered before the page is drawn.
  4. 04ModifiersGuestHalf or full plate, spice level, extra achar.HouseVariants and modifiers resolve against your own menu records.
  5. 05CartGuestReviews the basket; notes for the kitchen.HouseTotals come from the same calculation as the till.
  6. 06OrderGuestTaps “Place order” once, or five times.HouseOne idempotency key per basket: one order, whatever the taps.
  7. 07KitchenGuestSees “Received”.HouseWaits at the POS for Accept, or fires straight to KDS + KOT on Auto.
  8. 08StatusGuestReceived → preparing → ready → served.HouseCooks bump the ticket; the guest screen follows.
  9. 09PayGuestAsks for the bill, or pays online where you’ve enabled it.HouseSettled at the counter by default, recorded on the same order.

Codes that can’t be guessed or edited

Each table’s QR code holds a long random token instead of a table number. Changing the link does not lead to another table, because there is no number in it to change.

  1. 1The server looks up the token and finds one active table. An inactive table or a closed business shows a “not valid” message.
  2. 2The phone only sends which items and how many. Prices, tax and totals are calculated on the server.
  3. 3Too many orders from one table in a short time are refused, so a shared photo of the code can’t flood the kitchen. You can replace a table’s code at any time.

What the QR code encodes

Example token

The usual way · guessable

menu.example.com/?restaurant=42&table=7

Change a number, order to someone else’s table, or someone else’s restaurant.

DataRestro · opaque

/order/Xq3v9TzL0bRk_2mPwq8sYd1FhN4cVe7J

  • 192 random bits: nothing to count up from
  • Names no restaurant, branch or table
  • Regenerate a table’s code any time
  • Inactive table → “This QR code is not valid”

Staff accept orders, or they go straight through

One setting decides. On Manual (the default), guest orders wait at the POS until a member of staff accepts them. On Auto, they are accepted as soon as they arrive and go to the kitchen display and KOT printer the same way a POS order does.

Either way, if a guest taps send twice, the kitchen gets one order.

Manual

Default
  1. 01Guest places order
  2. 02Waits at the POS · “New QR order, table 7”
  3. 03Staff taps Accept
  4. 04KDS ticket + KOT print

A person sees every guest order before the kitchen does. Right for busy floors and new menus.

Auto

Opt-in
  1. 01Guest places order
  2. 02Confirmed in the same transaction
  3. 03KDS ticket + KOT print
  4. 04Staff see it on the POS

No one in between: the ticket fires through exactly the same routing as a POS send.

When the internet is down

Today QR ordering needs the internet: the guest’s phone sends the order to DataRestro online. If the connection is down, the guest page says ordering is unavailable. It never shows “received” for an order that didn’t arrive. Staff can keep taking orders on the POS, which queues them until the connection returns.

Local restaurant mode, where guest phones order over the restaurant’s own Wi-Fi through DataRestro Local during an outage, is planned but not built.

Cloud mode

Available
  1. Guest phone
  2. Mobile data or Wi-Fi
  3. DataRestro cloud
  4. POS · KDS · KOT

How QR ordering works today. If the restaurant’s internet is down, the guest page says so and never claims an order was received. Staff keep ringing on the POS’s offline queue.

Local restaurant mode

Planned
  1. Guest phone
  2. Restaurant Wi-Fi
  3. DataRestro Local
  4. POS · KDS · KOT

Designed, not built: the in-house agent serves the menu on the LAN, takes orders into a local outbox and replays them to the cloud once each when the line returns.

How it connects

Where a QR order goes

A guest's order is handled the same way as a counter order. It has a table, kitchen tickets, a payment and a place in the reports.

QR table ordering

Resolves the table from its token, checks every line against live availability, prices it on the server and creates one order per idempotency key.

QR ordering features

Partial means it works today with the limit stated. Planned means it is not built yet.

Available
Available
Partial
Partial
Planned
Planned

  • Per-table QR codes

    Available

    Opaque random tokens; regenerate any table’s code at any time.

  • Live menu with modifiers

    Available

    Variants, modifiers and notes, priced by the shared calculation.

  • One order per basket

    Available

    Idempotency key per basket, so retries and double taps return the first order.

  • Manual or automatic acceptance

    Available

    Wait at the POS for staff, or fire straight to KDS and KOT.

  • Table requests

    Available

    Call waiter, water, bill or assistance, straight to staff screens.

  • Flood protection

    Available

    A burst of orders from one table is refused with a message to ask staff.

  • Order status for the guest

    Partial

    Received → preparing → ready → served. Refreshed by polling, not pushed.

  • Pay from the phone

    Partial

    Khalti, eSewa or Stripe checkout with your own merchant account; not yet verified against live accounts.

  • Local restaurant mode

    Planned

    Ordering over the restaurant’s Wi-Fi through DataRestro Local while the internet is down.

  • Live push to guest screens

    Planned

    Status and availability pushed instead of polled.

  • Kiosk self-ordering

    Planned

    A self-order screen at the counter on the same flow.

QR ordering questions

Do guests need an app or an account?
No. The phone camera opens your menu in the browser. A phone number is optional; if given, it links the order to the guest’s loyalty profile.
Can someone order to another table by editing the link?
No. The link carries a long random token, not a table number, so there is nothing to change. If a code is photographed and shared, generate a new one for that table and the old one stops working.
Do QR orders go straight to the kitchen?
You choose. Manual (the default) holds them at the POS until staff accept them. Auto sends them to the kitchen display and KOT printer as soon as they arrive.
What happens if the restaurant’s internet goes down?
Today QR ordering needs the internet. The guest page shows that ordering is unavailable and never claims an order was received, while staff keep taking orders on the POS, which queues them offline. Local restaurant mode, which would keep QR ordering running on the restaurant’s own Wi-Fi, is planned.

Try the demo

A sample restaurant in your browser. Take an order, send it to the kitchen, mark it ready and take payment. No account needed.

Try the live demoGet started
Next featureGrowRestaurant websitesA restaurant website built from the menu you use at the till.