A table QR code is a key to the table, and a photo of a key still opens the door. That is the whole lesson of what happened on Lacy’s first stream from Japan, and it applies to every restaurant that lets guests order by scanning the code on the table.
What happened
The American streamer Lacy was eating at a restaurant in Japan during a live stream. Like many restaurants there, it took orders through a QR code on the table: scan it, browse the menu on your phone, order, and the kitchen receives it. At some point the code was visible on camera.
His chat noticed before he did. Viewers scanned the code from their screens and started ordering to his table. Early reports put the orders at more than ¥500,000 (about $3,200); by the time he came back on stream the figure being quoted was ¥1.6 million, roughly $10,000–12,000. “The poor restaurant had to make all this food because chat wanted to troll,” he said, as Spilled and GameRiv reported.
The details are still unsettled — some accounts say staff checked with him, stopped the extra orders and never cooked most of it, and it is unclear what he actually paid — and they matter less than the mechanism, which is not in dispute: a picture of a table code was enough to order to that table from anywhere in the world.
This is not a streamer problem
It would be easy to file this under “influencer forgets what is on camera”. The uncomfortable part is that the same thing works with any photo:
- a selfie at dinner posted with the table code in the corner;
- a review photo of the menu stand;
- a friend’s story from the same table last week.
Most table-ordering codes are static: the pattern contains a fixed address such as order.example.com/shop/123/table/7. That address is the credential. Anyone who has it can open the same ordering page as the person sitting at table 7, and it keeps working until somebody changes the system behind it. You cannot recall a photo, so you cannot recall the code. (If the difference between the two kinds is new to you, static vs dynamic QR codes explains it.)
Why a table QR code you control cannot run away
A dynamic QR code does not encode the ordering page. It encodes a short link of ours, and every scan is looked up and sent on to wherever that link currently points. That middle step is what turns a leak from a disaster into a two-minute annoyance:
- Pause it from your phone. Switch the code off in the dashboard or the mobile app and every copy — the one on the table, and every screenshot of it — stops sending people to the ordering page on the next scan. Nothing to reprint, nothing to peel off.
- Or point it somewhere else. Send the leaked code to a “please ask staff for a new code” page while you swap the table card, then point it back. Re-pointing takes effect within seconds, for every printed copy at once.
- Fence it to your country. A code can be set to allow scans only from the countries you choose. A Tokyo restaurant allowing Japan shuts out a worldwide chat, which is the audience a leaked photo actually reaches.
- See it happen. Every scan is recorded with its country, city and device, and you can be emailed or have a webhook called on each one. A table that normally gets a handful of scans an evening and suddenly gets hundreds from another continent is not hard to spot — the alert is the moment you reach for the pause switch.
- Put a password or an expiry on it. A code can ask for a password before it goes anywhere, or stop on a date, for the cases where a code should only work for the people you hand it to.
And bots never count: link previews and crawlers that fetch a leaked link are filtered out of the numbers and never trigger an alert, so a spike in your scans is people, not a chat app unfurling a URL.
What a QR code cannot fix on its own
Being straight about the limits matters more than the pitch. A dynamic code controls who reaches the ordering page; it does not run the ordering page. Someone who already opened it before you paused the code may still have the page open, and a viewer in the same country passes a country fence. The strongest setups combine the two layers:
- A dynamic code on the table, so a leak can be switched off instantly and spotted from the scan log.
- An ordering system that ties orders to a seating — a session staff open when guests sit down and close when they pay, a short-lived link per visit, or a confirmation step for unusually large orders.
The restaurant in this story reportedly did the second part by hand: staff asked, and the extra food was largely never made. A code with an off switch means the kitchen never has to ask in the first place.
If you run a restaurant with table ordering
- Find out what your table codes encode. Scan one and read the address your phone previews. If it is your ordering provider’s address with a table number in it, it is static, and a photo of it works forever.
- Put a dynamic code in front of it. Point a dynamic code at that same address and print the dynamic one instead. Your ordering system does not change; you just gain a switch.
- Turn on scan alerts for the first weeks, so you learn what a normal evening looks like — which is what makes an abnormal one obvious.
- Allow your own country if your guests are local.
- Ask your provider whether orders are tied to a seating session and whether big orders can require staff confirmation.
For the rest of what QR codes do in a restaurant — menus, Wi-Fi, reviews — see QR codes for restaurants and the full guide to restaurant QR codes, and for the wider question of what can go wrong with a scan, are QR codes safe?