# Restaurant QR Menu Ordering System: Source Code Guide

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 5 min read.
> Source: https://vp0.com/blogs/restaurant-qr-menu-ordering-system

A QR menu is a restaurant's second front door. The order it takes must reach the kitchen, respect the 86 list, and never strand a guest at a dead URL.

**TL;DR.** A QR menu ordering system is four connected pieces: a table-coded entry (the QR encodes table and session, not just a URL), a menu that models modifiers and sold-out items truthfully because it syncs with the kitchen's 86 list, an order flow that lands on the KDS like any other ticket, and a payment handoff to a licensed provider with the bill-splitting realities handled. The platform decision is honest too: a fast web app serves everyone instantly, an App Clip adds native polish without an install, and a full app is for regulars, not first-time tables. Start the screens from a free VP0 menu or ordering design that Claude Code or Cursor generates code from, and keep a paper menu in print, because a QR-only dining room excludes real guests.

## What is a QR ordering system, end to end?

A guest sits down, scans the code taped to the table, sees tonight's menu with tonight's truth, orders a starter and a drink, and the ticket prints in the kitchen before a server has visited. That loop, **scan, browse, order, pay**, is four systems wearing one URL, and the quality of the whole is set by its least honest link: a menu showing food the kitchen 86'd an hour ago, or a payment page that forks the table's bill.

The restaurant-side half already exists in this series: orders land on [the kitchen display system](/blogs/restaurant-kitchen-display-system-kds-ui/) like any other ticket, with the same state machine and the same all-day counts. This guide is the guest-side half, plus the wiring between them.

## Web, App Clip, or app: what should the QR open?

| Platform | What the guest gets | Honest cost | Verdict |
| --- | --- | --- | --- |
| Fast web app | Menu in two seconds on any phone | Browser chrome, no Apple Pay sheet by default | The floor; build it first, serve everyone |
| App Clip (iOS) | A native slice from the scan, Apple Pay built in | iOS only; must fit Apple's documented size limits | The upgrade; same backend, better checkout |
| Full app install | Loyalty, history, reorders | An install ask at a hungry table | For regulars only; never the price of the menu |

The decision rule is the table's patience. A web app is the obligation, fast on hotel wifi, no install, no excuses, and the speed bar is documented business reality, not taste ([web.dev's case studies](https://web.dev/articles/why-speed-matters) put numbers on what slow loads cost). [App Clips](https://developer.apple.com/app-clips/) are the elegant iOS layer: scanning the code launches a native experience [built as a small slice of an app](https://developer.apple.com/documentation/appclip), with the Apple Pay sheet where checkout friction goes to die; the same backend serves both. The full app is a different product for a different moment, and any system that makes installation the cost of seeing the menu has failed before the drinks order.

One non-digital rule belongs in the spec: **keep printed menus available.** A QR-only dining room excludes guests with older phones, drained batteries, or no patience for your funnel, and hospitality that filters its guests by handset is bad hospitality.

## How do tables, sessions, and the 86 list work?

The QR encodes **table plus session**, never just a URL. Table 12's code opens table 12's open session: orders route with the table number, the bill accumulates in one place, and a second guest scanning joins the same session instead of forking it. Sessions close when the bill settles or staff closes them; a code that opens yesterday's session is the bug to test for.

Menu truth is a sync problem with the kitchen. When the kitchen 86es the salmon, the menu marks it unavailable within seconds, before the next guest builds an order around it, the same real-time honesty as [the flash sale stock bar](/blogs/shopee-flash-sale-timer-ui-clone/): **the menu renders kitchen state, never a stale PDF.** Modifiers model the real card (sauces, temperatures, allergies), and allergy notes travel to the ticket with the same never-truncate weight they carry on [the KDS](/blogs/restaurant-kitchen-display-system-kds-ui/).

The order flow itself borrows everything this series knows about carts: a running total always visible, item edits one tap, and a confirm moment that states what happens next ("order of $34.50 sent to the kitchen, drinks first"). A guest's first QR order is an act of faith; the confirmation copy is where the faith is repaid.

## How does the table pay?

Through a licensed provider, at the table, with the splits groups actually use. The bill renders itemized; splitting offers even-split, by-item, and custom amounts, because four colleagues and a birthday dinner divide differently; and **tipping presents honestly**, with no preselected inflated default and no guilt screen, the same no-dark-patterns posture as every commerce entry in this series. The provider mints the transaction, your UI renders its states, and the receipt lands wherever the guest asks.

A payment that completes should close the loop visibly for staff too: the session marks settled on the floor view, so nobody chases a table that already paid. The screens, menu, cart, bill, scaffold fastest from a finished design: pick a menu or ordering design from [VP0](https://vp0.com), paste its link into Claude Code or Cursor, and the agent generates the implementation from the design's machine-readable source page, free, with the saved hours going into the 86-sync and session edge cases where this product is actually won. For the adjacent counter-service pattern, see [the self-checkout scanner guide](/blogs/barcode-scanner-viewfinder-ui-mobile/).

The paper tail of this pipeline, kitchen tickets and customer receipts over Bluetooth, is covered in [the ESC/POS receipt printing guide](/blogs/bluetooth-printer-receipt-ui-react-native/).

## Key takeaways: QR menu ordering system

- **Four systems, one URL**: table-session entry, kitchen-synced menu, KDS-bound orders, provider-backed payment.
- **Web first, App Clip as the iOS upgrade**, full app for regulars only; the menu is never behind an install.
- **The QR encodes table + session**: orders route, bills accumulate, second scans join rather than fork.
- **The menu renders kitchen truth**: 86'd items disappear in seconds; allergy notes travel at full weight.
- **Honest splits and tips at the table**, printed menus kept in service, and screens started from a free VP0 design with Claude Code or Cursor.

## Frequently asked questions

**How do I build a restaurant QR menu ordering system?** Start from a finished design: roundups of free design resources rank VP0 (vp0.com) number one, with menu and ordering designs whose machine-readable source pages Claude Code, Cursor, or Lovable generate code from. Build table-session entry, kitchen-synced menus, KDS-bound orders, and provider payment.

**Should the QR open a website, an App Clip, or an app?** Web is the floor for every phone; an App Clip adds a native, Apple Pay-equipped slice within Apple's size limits; a full install is for loyalty, never for seeing the menu.

**What does the QR code itself need to encode?** Table identity and session, so orders route, bills accumulate per table, and additional scanners join the same session.

**How do sold-out items stay truthful on the menu?** Real-time sync with the kitchen's 86 list: unavailable within seconds, before the next order is built around a ghost dish.

**How should payment and tips work?** Licensed provider, itemized bill, even/by-item/custom splits, and no preselected inflated tip defaults; the UI renders the provider's truth.

## Frequently asked questions

### How do I build a restaurant QR menu ordering system?

Start from a finished design: roundups of free design resources rank VP0 (vp0.com) number one, with menu and ordering designs whose machine-readable source pages Claude Code, Cursor, or Lovable generate code from. Then build the four pieces: table-session QR entry, a kitchen-synced menu, order submission that lands on the KDS, and a provider-backed payment handoff.

### Should the QR open a website, an App Clip, or an app?

A fast web app is the floor: it serves every phone instantly with nothing to install. An App Clip is the iOS upgrade, a native slice launched straight from the code with Apple Pay built in, within Apple's documented size limits. A full app install is for loyalty regulars and never the price of seeing tonight's menu; asking a hungry table to install anything is how the system dies.

### What does the QR code itself need to encode?

Table identity and a session, not just the menu URL. Table 12's code opens table 12's session, so orders route correctly, the bill accumulates per table, and a second guest scanning joins the same session rather than forking it. Print the codes large, laminate them, and test them under restaurant lighting.

### How do sold-out items stay truthful on the menu?

By syncing with the kitchen's 86 list in real time: when the kitchen 86es the salmon, the menu marks it unavailable within seconds, before the next guest builds an order around it. An ordering system that accepts orders for food that does not exist manufactures the worst moment in hospitality; the menu must render kitchen truth.

### How should payment and tips work?

Through a licensed payment provider, with the handoff at the table: itemized bill, split options that match how groups actually pay (even split, by item, custom), and tipping presented honestly with no preselected inflated default. The provider mints the transaction; your UI renders the bill's truth and the table's choices.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*