How to Use QR Codes for Restaurant Tableside Payment

Tableside payment QR codesA 2D matrix barcode that encodes data in a square grid of black and white modulesA single black or white square in the QR grid. The number of modules per side scales with the QR versionThe size of a QR code, numbered 1 (21×21 modules) through 40 (177×177). Higher versions store more data but require more printed space. Read more →, from 21×21 modules for version 1 up to 177×177 for version 40. Read more →. Read more → have to do one specific job. They move the guest from “the meal is over” to “the bill is paid” without forcing the server to walk over with a card reader, wait while the guest reads the screen, and walk back. The job sounds simple. The mechanics are not.

Table-number encoding is the foundation

Use the supported bill link from your payment system. If the link contains a table identifier, verify that it selects the current check rather than a previous service. Do not infer authorization from a public table number. Test wrong-table selection, closed checks, and staff correction before launch. Different payment systems expose different integrations; the QR image does not supply them.

The print logistics that follow are non-trivial. A 60-table dining room needs 60 distinct QR codes, each printed on table-tent or under-glass material that survives bussing and cleaning. The naive approach prints all 60 at once and replaces the whole batch when the URL pattern changes; the pragmatic approach uses dynamic QR codesA QR code that points to a short redirect URL controlled by a service. Read more → where the printed sticker stays constant and the back-end maps each code to a table identifier the POS understands. The dynamic pattern means a code can be reassigned without reprinting if a table is renumbered, which happens more often than restaurants expect during renovation. The URL-to-PNG generator produces raster output sized for table-tent printing.

The bill-display screen earns the tap

A guest scanning a QR on the edge of a table is one click away from a checkout page they have never seen before. Trust collapses if the first screen is a generic Stripe Checkout that says “Restaurant XYZ - $87.40 - Pay.” The guest does not know what they are paying for, cannot verify the kitchen got the order right, and pauses to flag down a server, which is exactly the friction the QR was supposed to remove. The fix is simple. Show the itemized bill on the landing page before the pay button. Each line item, the subtotal, the tax, the suggested tip presets, the total. The guest sees what they are paying for, confirms the kitchen got the order right, and taps pay with confidence.

The design detail that matters is matching the visual hierarchy of the printed bill the server would have brought. Guests are accustomed to a check presentation pattern: items listed top to bottom, total at the bottom, tip line below. The digital version should replicate that pattern, not invent a new one. A landing page that presents the same items in a different order or hides line items behind a “view details” tap loses the trust the printed format earns. For execution depth on the printed-bill conventions, the restaurant menu playbook covers the lamination and lighting decisions that affect under-glass QR placement.

Explain tips and totals before payment

Tip buttons can help guests choose an amount, but the choice needs to be explicit. Display the subtotal used for calculation, the tip amount, taxes, and final total. Include a way to enter another amount and decline a tip where appropriate. A QR payment should not hide costs or assume that preset choices guarantee higher staff earnings.

Check the tip configuration against the restaurant policy and applicable requirements. For split payments, explain whether the amount is calculated from the guest share or the complete bill. Test the final receipt and staff reporting as well as the visible buttons. Avoid treating a layout preference as evidence of a revenue gain.

Split-the-check is the hard UX problem

Check which split modes your installed payment system actually supports. Equal splits and paying selected items are different workflows. Test two guests paying at once, partial settlements, taxes, tips, failed payments, and the remaining balance. Do not assume support merely because a provider has an API; it depends on the configured integration and product.

The UX pattern that works is item-toggle: each line item has a checkbox or tap-to-select state, and the guest selects the items they are paying for. The partial total updates live; the tip preset recalculates against the partial subtotal; the pay button settles only the selected items. The remaining items stay open on the table check until the next guest scans and selects their items. The edge case is shared items (a bottle of wine across two payers) which needs a custom split UI that few platforms get right; for a launch deployment, support even-split and item-level select, and route shared-item splits to the server fallback. The payment links playbook covers the partial-check settlement patterns in more depth.

Measure completed payments and staff time

Measure the interval from bill request to confirmed settlement in your own restaurant. Compare ordinary service with a pilot using the same definition. Include guests who need help and failed or abandoned attempts. Faster checkout does not automatically create more seatings: demand, kitchen capacity, staffing, and how long guests stay all affect the result.

Build a business case from measured usage, integration costs, payment fees, maintenance, and staff time. Do not promise a payback month or annual revenue from assumed minutes saved. The static versus dynamic guide explains why stable URLs can keep printed materials usable while the underlying checkout changes.

The QR-fail fallback is a 30-second handoff

QR scans fail. A phone with a smudged camera lens, an older device with weak QR detection, an under-glass placement that catches a hot spot from the pendant light. The fallback has to be a 30-second handoff, not a 5-minute reset. The server sees a guest pull out their phone, look at the QR, frown, and put the phone back down. That is the visual cue. The server walks over with a portable card reader, processes the payment manually, and the table flips on schedule.

Train the floor on the visual cue. The server who waits to be flagged down loses the time savings the QR was supposed to deliver; the server who watches for the frown-and-pocket gesture catches stuck guests within 30 seconds. The customer reviews playbook covers the post-payment review prompt that some operators chain onto the receipt-delivery email, which captures social proof while the meal is still warm in the guest’s mind. For the print-side decisions on under-glass QR placement, the QR design best practices guide covers contrast and quiet-zone choices that affect scan reliabilityHow consistently a QR code scans across different devices, lighting conditions, distances, and orientations. Read more → under typical restaurant lighting.

Sources

• Stripe — supported Payment Links
• EMVCo — payment QR specifications