If you're weighing QR ordering, the code itself is the easy part. A guest scans it, your menu opens in the phone's browser, and the order goes from the table to the kitchen, with payment on the same screen if you want it. Nothing to install, and on most current phones the camera opens the link without a separate app. Making the code is quick. The harder calls are which mode it runs in, whether each table gets its own code, where the requests go that a server used to pick up, and who checks that the code on the table is still yours.
Display, ordering, payment: three setups behind one code
Scan to order, QR ordering, order at table, mobile ordering: different names for the same thing. What actually differs between restaurants is how much of it is switched on, and the table above shows the three levels.
So the choice isn't paper or digital. It's how many levels you want and in what order. You can run display only for a season before you take a single order by phone. That also splits the training in two, because the team gets used to the menu screen first and only later deals with a ticket that arrived without them.
After the scan: what the guest actually does
The guest makes four moves. They point the camera at the code and tap the link. They pick a language if the menu has more than one. They add dishes, choose options and leave a note where the kitchen needs one. Then they send the order, and pay on the same screen if payment is on.
Some older phones won't read a code from the camera, and that guest will often wave someone over instead. For the guest's side in more detail, what changes for diners after the scan goes from the first screen to the bill.
Four settings to decide before the codes go on the tables
All four are easier to change now than after the codes are printed.
Start with the mode: display only, or ordering. In display mode the code is a showcase. In ordering mode it's a till in the guest's hand.
Next, table identity. With a code per table, every order arrives already knowing where it came from. One code for the whole room prints once, but it has to ask the guest which table they're at. FineDine groups tables into areas first, so the terrace and the first floor are set up as separate blocks instead of one long list.
Third, the channels. A menu can carry labels for dine-in, pickup, delivery and tablet, and the table code is only the first of them. Taking pickup and delivery through your own channel is a separate decision with its own delivery times and minimums, covered in the do's and don'ts of online ordering.
Last, where the money changes hands. Paying from the phone closes the table without a second trip. Paying on the bill at the end keeps the finish your regulars are used to. Ordering and payment are separate switches, and nothing says you have to turn both on in the same week.
Tampered codes: the 2022 FBI notice and your table cards
In January 2022 the FBI's Internet Crime Complaint Center put out a public service announcement about criminals tampering with QR codes. The scheme swaps a real code for one that leads to a lookalike site, where the victim types in login or card details. On a printed code, the simplest way to make that swap is a sticker over the original.
That's the version that can reach a dining room. It needs no access to your account, just a minute at an empty table. The menu platform has no way to notice, because the code it generated still works. It just isn't the one being scanned.
So the check happens on the floor, not in the software. Put the codes on the opening walk-through, in the same round where someone checks the tables are set. A code printed into the table card, rather than stuck on as a label, makes a second layer on top easier to spot.
The notice's advice to the public also gives your staff something to say. It tells people to check the web address after scanning, to be careful entering payment details on a page they reached from a code, and not to download an app from one. Give the team one line they can repeat at the table: our menu opens in the browser, never asks for an app, and takes card payment through the provider we use. If a table reports anything different, that code gets replaced before the next seating.
Payment is where a swapped code does the damage. When guests pay from the phone, the card details go into the checkout of the payment provider you connected, and how QR code payments work at the table covers where that flow tends to break. The FBI notice doesn't tell people to stop ordering by QR code. On payment, though, it goes further than checking the address: it advises against paying through a site reached from a code and suggests typing in a known, trusted address instead. Some guests will follow that advice, so keep paying on the bill available next to paying from the phone. On your own tables, you're the one who can check where a code leads before a guest scans it.
The jobs a server did on the way to take the order
A server walking over to take an order did more than take it. They cleared the empty glass. They heard that one plate came out wrong. They noticed table six was ready for the bill. Take that walk out of the shift and each of those jobs needs another way to happen.
That's what service requests are for. The operations settings decide what a guest can send from the menu screen: call someone over, ask for the bill, flag a problem with an order already sent. Choose them on purpose. If the screen gives the guest no way to reach a person, expect that to be the first complaint once the rollout is live.
Alcohol has its own switch. You can add an age check to the ordering flow, and it puts the question on the screen. It doesn't put anyone in front of the guest, so whoever carries the glass to the table still decides whether to hand it over.
Timing shifts too. Orders stop coming in at the pace of one server's round and start coming in when guests are ready, which can mean several tickets landing in the same minute.
What a QR ordering system costs beyond the subscription
Ask what QR ordering costs and the answer is usually one number, the monthly subscription. That's one line out of five.
The subscription has caps. Plans differ on how many tables you can run and how many orders a month are included, and because those figures change, they're on the pricing page rather than in this article. Count your tables and pull the order count from a busy month before you compare anything.
If guests pay from the same code they ordered from, the payment provider takes its cut. That rate is set by the provider, not by whoever supplies the menu. You connect an account, Stripe or Iyzipay or whichever one works in your market, and the card fee goes to them.
The POS connection is the line people tend to miss. Some connectors are included, others are billed monthly on top, and which one applies depends on the terminal already on your counter. Look yours up by name.
Then printing. A table code gets reprinted when the room is rearranged, and again when a card wears out or gets tampered with.
The fifth line isn't on any invoice. For the first few services someone stands at the tables explaining the code, and you're paying for that time.
Where scan to order doesn't fit
Some guests won't scan, whatever the training. Keeping printed menus at the host stand isn't a failed rollout. It's what stops a table from sitting there waiting.
Low light works against the camera, and so does glossy laminate under a spotlight. Print matte, and put the code where plates and the bread basket won't cover it.
A first-time guest often wants someone to tell them what to order. A screen can show a photo of every dish and still not answer what's good tonight.
A large party splitting the bill can be awkward for software in ways a server handles without thinking. Watch how yours deals with it before you promise it to a group booking.
And QR ordering adds no kitchen capacity. Waiting on the floor can drop while the pressure moves to the pass, and orders that arrive sooner only help if the kitchen can keep up.
A two-week trial on one area before the whole room
Pick one area, the terrace or a block of tables near the pass, and run it for two weeks. Codes for one area cost little to print and little to throw away. Printing for the whole room is the decision that's hard to undo.
Collect three numbers before the fortnight starts. None of them needs anything bought. First, time how long an order takes to reach the kitchen from the moment a table is ready to give it, across three services. Second, read the last 50 tickets and count how many carry a note or a modifier, because that count is the detail currently living in somebody's memory. Third, if you want to know whether ordering from the table moves the average check, run both ways side by side in the same service and compare your own figures, not a case study about someone else's restaurant.
Measure the same three things afterwards. Without a baseline, all you have is how the shift felt.
Running the trial area from FineDine
In FineDine the pieces sit in three places. The menu comes first, since every channel reads from it. Codes and their modes are under settings, generated per table or as one code for the room, with display and ordering as separate choices. Ordering settings hold the channel switches, the age check and the minimum order, and operations settings hold the requests a guest can send.
Once the trial area is live, orders and average ticket show up in FineDine IQ, where you can set a date range against the one before it. The before figures for the tables without a code are still in your till, and the comparison is yours to make.
The current table and monthly order caps are on the pricing page. To see how the flow works on your own menu, ask us for a walkthrough and bring a service you'd call busy.
| Setup | What the guest does | What staff still do | What changes on the shift |
|---|---|---|---|
| Display only | Reads the menu on their phone | Take the order and the payment as before | The paper menu goes, nothing else moves |
| Ordering | Sends dishes, options and notes from the table | Run food, answer requests, settle the bill | Tickets arrive when guests are ready, not at the pace of a server's round |
| Ordering and payment | Orders and pays from the same screen | Run food, answer requests | Nobody carries the card machine back to the table |
Frequently Asked Questions
- Does a guest need to download an app to order from the table?
- No. The code opens the menu in the phone's browser. If a code at your restaurant ever asks a guest to install something, treat it as tampered and replace it.
- Can I start with a view-only menu and add ordering later?
- Yes. Display and ordering are separate modes, so you can run the menu as a showcase first and turn ordering on when the team is ready. Payment from the phone is another separate switch.
- Is one code for the whole room enough, or does every table need its own?
- Both work. A code per table tells the kitchen where each order came from without asking. A single code prints once and asks the guest for their table number, so printing is simpler but the guest has one more step.
- How much does QR code ordering cost with FineDine?
- The subscription and its caps on tables and monthly orders are on the pricing page, which is kept current. Card fees go to the payment provider you connect, and some POS connectors are billed monthly on top, so check yours by name.
- Can guests read the menu in their own language?
- Yes, from the languages you've added. The guest picks one on the menu's first screen. How many languages you can add depends on the plan, and the pricing page lists it.
