Choose QR pay-at-table when a counter queue regularly interrupts seated service and your team can still see payment status and help guests who need it. Choose a staffed counter when guests already pass it to order or collect food, or when a person needs to handle most payment questions. Many restaurants will need both options.
The payment handoff is separate from the menu and ordering decision. A guest can browse a QR menu and still pay at a counter. Before buying software, map the full trip from order to payment to food collection, then check whether staff can tell what has and has not been paid.
Map the guest journey before choosing payment
Start with the service you actually run, not the features on a sales page. For each option, write down where the guest orders, where payment happens, who delivers the food, and how the team identifies the table or party.
QR pay-at-table: A seated guest scans a code, places or reviews an order where the system permits, and pays at the table. The team needs enough information to prepare and deliver the order to the right place. A server may still bring food, answer questions, and handle issues. Paying by phone does not remove those jobs.
Pay-at-counter: The guest goes to a staffed point to pay. Depending on the restaurant, that may happen when ordering, before collection, or after a seated meal. A staff member can answer questions during payment, but a single queue can form if the same person also takes orders and resolves problems.
Food collection is a separate choice. A guest who pays at the table might collect food from a pickup point or receive it at the table. A counter-paying guest might sit down after paying and have food delivered. Mark these handoffs on your floor plan so the kitchen and front-of-house team know what to do next.
Also distinguish a physical table from a guest party. One table might seat several people, and a party might use more than one table. Ask how the system identifies the right destination, handles a moved party, and prevents an old table assignment from confusing a later order.
A QR ordering system is not the same as a QR menu that only displays food and prices. Fleksa QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask any provider to show your intended sequence, including what staff see after payment, rather than assuming that a menu display includes the payment handoff you need.
Use a capacity worksheet to make the choice
The following figures are hypothetical. They illustrate a dinner period in a small restaurant; they are not results from a test or estimates of what a particular product will deliver.
Assume the dining room has eight physical tables and can seat up to eight parties at once, with one party per table. During a 60-minute period, 12 parties finish their meals. That means at least four table turnovers occur during the hour. Those turnovers could occur at fewer than four distinct tables. The room does not seat 12 parties simultaneously. Assume every party needs one payment handoff, regardless of party size.
For the counter option, assume payment takes two minutes of staff attention per party. One cashier is available for only 20 minutes of that hour because the same person has other assigned work. For the table-payment option, assume nine parties pay by phone and three ask to pay with staff. Each staff-assisted payment still takes two minutes. These assumptions are inputs to the worksheet, not promises about guest behavior or processing speed.
| Measure | Counter payment | Table payment with staff fallback |
|---|---|---|
| Parties needing a payment handoff | 12 at counter | 9 by phone; 3 with staff |
| Assumed staff payment time | 12 × 2 = 24 minutes | 3 × 2 = 6 minutes |
| Available payment-staff time | 20 minutes | 20 minutes |
| Initial decision | 4-minute capacity shortfall; add coverage or change the flow | 14 minutes remain within the assumed payment allocation; retain a staffed fallback |
On these inputs, table payment is the better starting choice for relieving the counter: the assumed payment work fits within the allocated staff time. The four-minute counter shortfall is a capacity warning, not a prediction that every guest will wait four minutes. Arrivals may bunch together, and time spent on ordering, refunds, or questions can make the queue longer.
The 14 minutes remaining in the table-payment column are not proven labor savings. They exclude setup, staff help with phones, payment exceptions, and reconciliation. They also do not mean a server can leave the floor unattended. If most parties prefer staff payment, or if the counter has more coverage than assumed, the result can change.
Make your own version with a busy hour, not a daily average. Count parties that finish in that hour, estimate the time staff spend on each payment, and record how much staff time is actually available. Then run a second version with more guests requesting help. If neither option fits, consider extra coverage or a different collection flow before buying software.
Balance queues, staff visibility, and guest choice
Counter payment puts a person at an important handoff. That is useful when guests have questions, want to pay with a method the phone flow does not support, or need a receipt explained. It can also make exceptions easier to notice. The trade-off is that one payment question can hold up everyone behind it, especially when ordering and pickup share the same counter.
Table payment can move some payment activity away from that queue. It may also let a seated guest finish without waiting for a server to return with a check. But staff still need visibility. Ask to see where an unpaid check appears, how quickly a completed payment is reflected, and what the team should do if the guest shows a payment screen while the staff view shows something different.
Guest choice matters as much as the flow on paper. Some people may not have a suitable phone, want to share one device, or simply prefer a person. Decide who can take their payment and where it happens. A sign can explain the options, but staff should be able to offer help without making a guest justify the request.
Consider the counter's other jobs too. If it is also the pickup point, moving payment away might leave more room for collection. If most guests must visit it anyway to collect food, the benefit of paying elsewhere may be smaller. Walk the path at your busiest time and look for crossings between waiting guests, staff carrying food, and people leaving.
Compare the wider service fit in this related buying guide, but keep the payment decision grounded in your own staffing and floor plan.
Trace an unpaid table and a request for help
Ask a provider to walk through two exceptions, not just a successful payment. Use fictional orders and simulated statuses in a practice environment. The practice must not charge a real card, send a guest message, or dispatch a courier.
A party leaves a table unpaid
- A fictional party finishes at a physical table. The check is still marked unpaid.
- Ask where the server or shift lead finds that status and what identifies the correct check. A table number alone may be insufficient if the table has already been reset for a new party.
- Have the provider demonstrate the staff workflow for investigating the check and recording its resolution. Ask what happens if payment is pending or the guest says they already paid.
- Check what remains visible for the end-of-shift review. Decide who owns unresolved checks and when the shift lead must be notified.
Do not treat a guest's departure or a screen refresh as proof of either payment or nonpayment. Staff need a clear way to check the transaction and escalate conflicting information. Ask whether a staff member can correct a table assignment, and what record remains after a correction.
A guest asks a person to help
- A fictional guest declines to use a phone and asks a server to pay with staff.
- Identify the route: does the server bring a payment device, or does the guest visit the counter? Confirm who is responsible if the counter is busy.
- Show how staff find the correct check and verify its status before taking payment, so the same amount is not requested twice.
- Walk through the guest's receipt request and the staff member's confirmation that the check is settled.
Ask about split payments, partial payments, tips, cancellations, and refunds if they matter to your service. Do not assume that a QR flow supports every variation. If an essential exception cannot be shown, agree on a workable staff procedure before adopting it.
Score a trial on payment and reconciliation
Set acceptance criteria before a demonstration. For example: staff can identify the correct check, see whether it is paid or unpaid, route a non-phone guest to a person, and find unresolved transactions for review. Add your own criteria for split checks or table moves if those are common. Mark each item pass or fail based on the demonstrated workflow; leave an unshown item unresolved rather than calling it a pass.
Next, use simulated checks to practice ordinary and exception flows without real payments or guest contact. Have the people who would work the shift follow the steps. Note where they need instructions, where responsibility changes hands, and what information they cannot find. This is a practice exercise, not evidence of service performance.
Only after the practice meets your criteria should you consider a separately planned live service pilot. Define its hours, staffing, guest fallback, escalation owner, and stop conditions. During that pilot, count parties using each payment route, requests for help, unresolved checks, and visible queue pressure. Review what happened with the shift team before extending the change.
For reconciliation, compare transaction records with the checks they are meant to settle, then review refunds, tips, and unresolved items separately. Sales, payment-processing fees, and deposits are different measures: a sales total is not a deposit total, and a fee is not a sale. Ask the provider which reports show each measure, when deposits are expected, and how staff can investigate a mismatch. Agree who completes that review at close.
Get an operational quote that separates software charges, setup, payment processing, hardware, and any optional services. Compare the same items and term across quotes. Fleksa states there is no Fleksa commission on table QR orders; processing and applicable tax still apply. Confirm the current terms for your setup. For broader pricing questions, review the Fleksa plans and request a written quote. Ask a qualified adviser about contract or tax treatment when needed.
Next step: Bring your busiest-hour worksheet and exception checklist to a Fleksa QR ordering demonstration. Ask the team to show your table-payment handoff, staff fallback, and reconciliation workflow before you decide.
Frequently asked questions
Can guests browse by QR code and pay at the counter?
That can be a workable service design. Confirm how the guest's order or check reaches staff and how the correct amount is identified at the counter. A QR menu alone does not establish that workflow.
Should a restaurant offer both payment options?
Offering a staffed fallback is useful when some guests cannot or prefer not to use a phone. Make sure the team can find the same check and verify its status before taking payment.
What should I check before a live pilot?
Use fictional checks to practice payment status, unpaid checks, staff help, and reconciliation first. Set pilot staffing, success measures, escalation ownership, and stop conditions separately before serving real guests.
