Most QR ordering pitches start with a slick demo and end with a quiet sentence: "connector to your POS available on request." Two months later you find out "available" means a custom development project, a Lightspeed Partner Program review, and a six-week wait. By the time it ships, the season is over.
Tablario's first version of QR ordering does the unglamorous opposite. No POS connector. No payment processing. No card terminal integration. What it does is capture the order from the guest's phone, show it in real time on a dashboard tab, and play a chime when a new one arrives. The kitchen reads the order off the dashboard or off a printed slip and types it into the same POS they already use. Same workflow as the printed menu — but the guest does the typing.
This sounds underwhelming until you realize that typing the order is the only step QR ordering has ever actually changed. Everything else — fire to kitchen, fire to bar, modifiers, course pacing — your POS already does. We don't need to replace it. We need to feed it.
What "no payment" really means
Today, when a guest orders via QR at a Tablario-equipped table, here's what happens:
- Guest scans the QR code on the table tent. The URL
tablario.com/r/your-restaurant/menu?table=12opens. - They see your menu — same one as on your public restaurant page — with allergens, photos and prices.
- They tap items, build a cart, hit "Send to kitchen."
- The order shows up on your dashboard, with the table number and a timestamp. A chime plays.
- Your team reads the order, types it into your POS exactly as if it had been called over the bar, and fires the kitchen ticket.
- The guest pays at the end, the way they always have — card terminal, cash, or whatever your POS already supports.
That is the whole loop. The guest never enters a card. We never see one. Your POS, your card terminal, your accounting flow — none of them change.
Why this is a feature, not a limitation
In Germany, payment integration is non-trivial. The KassenSichV (Kassensicherungsverordnung) requires every cash-relevant transaction to be recorded by a TSE (Technische Sicherheitseinrichtung). The legal exemption for "Bezahlsysteme" (payment systems that don't store itemized sales) is narrow and depends on what your software persists.
If we shipped payment-integrated QR ordering today, we'd either:
- Become a Kasse under the BMF definition — which requires a TSE, an annual export, and audit-grade storage of every line item. That's a project, not a sprint.
- Quietly violate the rule by storing item-level data without a TSE — which is what some international competitors do, and which exposes their customers, not them.
We picked option three: don't store item-level sales data at all. The order goes to the dashboard for fulfillment. The fulfilled order is logged with a timestamp and a total — nothing else. No item rows persisted. The BMF exemption applies cleanly. No TSE required.
This is also why payment ships in Phase 2, with a documented Rechtsgutachten — when we add payment, the architecture has to change, and we want a German tax lawyer to sign the design before a single euro changes hands.
Allergen tagging that's actually legal
Every dish in the Tablario menu module supports the 14 allergens listed in EU Regulation 1169/2011: gluten, crustaceans, eggs, fish, peanuts, soybeans, milk, nuts, celery, mustard, sesame, sulphites, lupin, molluscs.
This is not optional. Since 2014, EU law requires restaurants to display allergen information for every dish — on a menu, a separate list, or via an app. Most restaurants comply via a hand-typed PDF that nobody updates. The Tablario menu module enforces it at the data model: you can't save a dish without picking allergen tags.
Guests can filter the QR menu by allergen ("Hide everything with milk") before ordering. The kitchen sees the same allergens on the order ticket. The compliance is automatic and the operational benefit is downstream: fewer surprise allergic reactions, fewer comped meals, fewer angry reviews.
Real-time dashboard, not a printer queue
The orders tab in your Tablario dashboard is the operations view. Every active order shows table number, items, modifiers, time elapsed since the order arrived. New orders chime; orders older than five minutes pulse softly. You can mark orders as "fired" or "delivered" — those events feed your guest CRM (so a regular's history is accurate) but they don't go to the POS.
The dashboard runs in any browser. A €50 Android tablet on a wall mount does the job. We tested it.
What this is not
- Not a substitute for table service. Servers still take orders the old-fashioned way for guests who prefer it. QR is opt-in per guest, not enforced.
- Not a replacement for your POS. It feeds your POS by hand. That is a feature today; it will become an integration in Phase 2 for restaurants that want it.
- Not aimed at fast-casual. Fast-casual operators usually run a vertical stack (Square, Toast) where this overlap doesn't make sense. We're aimed at full-service venues that already love their existing POS and refuse to change it.
What you need to start
A printed QR code per table (we generate it and you print on whatever stock you like), a tablet or laptop on the pass for the dashboard, and the menu in the Tablario admin. That's it.
If you want item-level sales reporting, your POS already has it. If you want payment at the table, wait for Phase 2 — and tell us, because the order of POS connectors we ship is determined by which ones our customers actually use.
QR ordering without payment is part of Tablario's Phase 1 release through September 2026. POS connectors and payment integration ship in Phase 2 (planned Q1 2027), gated on a Rechtsgutachten for DE/CH/AT.