Before treating a table bill as paid, staff should check the restaurant’s designated payment record for an approved payment tied to the correct bill and amount. A guest’s screen can help locate the transaction, but it should not be the only proof. A submitted order, a spinning payment screen, or a message that a payment is processing does not establish that the bill is paid.
Choose the authoritative record with your payment provider and software vendor before service starts. Ask where an approved transaction appears, how the bill is identified, and who can resolve a mismatch. Then teach staff what to do when the guest and restaurant views disagree.
Separate the guest screen from the payment record
Three pieces of information may appear during a QR checkout. The guest sees a checkout or confirmation screen. A payment system records a transaction status. Staff see a bill, transaction list, or another operational view. Those views may update at different times, and their labels may not mean the same thing.
For this decision, the important input is the payment status in the record your restaurant has designated as authoritative, not an assumption based on what the guest says or what the kitchen has received. Ask the vendor to identify the source of that status and explain what each label means. In particular, ask whether “approved,” “completed,” and “paid” describe the same event or different steps.
Also decide what proof must be matched. At a minimum, staff need the correct bill or transaction identifier, the amount, and the relevant status. A table number alone may be insufficient if a physical table has hosted more than one guest party or if a party has multiple bills. For a split bill, check each portion against the remaining balance rather than assuming one successful payment clears the whole check.
QR order status answers a different question: did the order reach the intended workflow? It does not by itself prove payment. Fleksa’s QR checkout documentation is a useful starting point for discussing the guest flow; ask for a demonstration of the staff-facing payment record in your own proposed setup.
Compare proof options with a decision worksheet
The following example is hypothetical. Assume one guest party has a $72 bill at physical table 8, with no tip added and no earlier payments. The restaurant has designated the payment provider’s transaction record as authoritative, and a shift lead can access it. These are assumptions for the comparison, not claims about a particular product or integration.
The table shows what staff should do under different observed statuses. The amount is a sale amount, not a processing fee or a deposit. It excludes processing fees, fixed software costs, and exception-handling costs; it is not an all-in operating cost calculation.
| Observed information | Authoritative record | Staff decision |
|---|---|---|
| Guest says payment was submitted | $72 pending for the matching bill | Keep the bill open; ask the shift lead to recheck. |
| Guest screen says payment succeeded | $72 approved for the matching bill | Mark the bill paid using the restaurant’s normal process. |
| Guest screen says payment succeeded | $72 failed for the matching bill | Do not mark paid; escalate and resolve the mismatch. |
| One guest pays $30 of the $72 bill | $30 approved for the matching bill | Record the partial payment; $42 remains. |
Two demonstration outcomes can change the buying decision. In the first, the staff view shows the matching bill, amount, and approved status directly from the designated record. Staff can make the decision without relying on a guest’s phone. In the second, staff can see only that checkout was started, while the shift lead must open a separate transaction record to verify the result. The second workflow may still be workable, but only if access, handoff, and response time fit a busy shift.
Ask the vendor to show both the normal path and a split payment. Can staff distinguish a $30 payment from a fully paid $72 bill? What identifier connects that payment to the right party? If the answer depends on another system, include the extra screen and staff access in the demonstration. A restaurant POS system is relevant here only if the proposed setup actually gives staff the proof they need; do not assume every POS screen receives every payment update.
Before comparing quotes, list any fixed software charges, variable payment-processing charges, and expected exception-handling work separately. Ask vendors which charges apply and what support is included when a payment needs investigation. A processing quote alone is not the total cost of running the workflow.
Plan for a disagreement before a busy shift
Use a simple rule: the staff member who notices a mismatch pauses the paid decision, and the shift lead owns the exception. The lead checks the designated authoritative record using the bill or transaction identifier and amount. The server should not close the bill merely to clear the table, and should not ask the guest to pay again until the lead has checked for an existing payment.
Suppose a guest shows a success screen while the staff view still says pending. First, confirm that both views refer to the same bill and amount. The lead then checks the authoritative record. If it shows an approved matching payment, follow the restaurant’s procedure to update the bill. If it remains pending, keep the exception open and follow the provider’s guidance on when and how to recheck. If it shows failed, explain the status to the guest and offer another payment method once the lead has ruled out an existing approved payment.
Decide in advance who can access the record and who can correct the bill. A server who can see a status but cannot investigate it needs a clear handoff. The lead also needs a way to note the bill identifier, time, observed statuses, and next action without copying unnecessary payment details. Ask the provider what information is appropriate to retain and how unresolved transactions should be escalated.
If the designated record is unavailable, do not invent a paid status. Keep the bill in an exception state and follow your provider’s approved fallback procedure. Ask what staff should tell the guest, who follows up, and how the team will reconcile the bill when access returns. A non-phone payment option should also be available for guests who cannot or do not want to use QR checkout.
These choices belong in the wider service plan. The guide to where QR ordering fits in table service can help you decide when staff should approach a table, while this payment rule determines what they must verify before closing its bill.
Set a pass-or-fail vendor demonstration
Give the vendor your real service requirements: table identification, split bills, staff roles, and the designated payment record. Use a simulated bill and simulated statuses for the demonstration. Confirm beforehand that the exercise will not create a real card payment, send a guest message, or dispatch a courier. A simulated check is for learning and verification; it is not a live service pilot.
- Identify the bill. Ask the demonstrator to show how staff distinguish two bills associated with the same physical table. Pass if the server can identify the intended bill without guessing from the table number alone.
- Trace pending and approved. Show a simulated pending payment, then an approved payment. Pass if the server can see which is which, identify the source of each status, and apply the restaurant’s rule without treating pending as paid.
- Check a partial payment. Show a simulated split payment and the remaining balance. Pass if staff can identify the paid portion and do not close the full bill while a balance remains.
- Create a mismatch. Simulate a guest success view alongside a pending or failed staff view. Pass if the server pauses closure, the shift lead checks the designated record, and the next action follows that record rather than the guest screen alone.
- Practice recovery. Show how an approved matching payment is reflected on the bill, and what happens when the record is unavailable. Pass if the lead can explain the correction or escalation path and name the owner of the unresolved case.
Fail the demonstration if staff cannot identify the bill, cannot distinguish pending from approved, or have no named route for a mismatch. A vendor may offer an extra step or another screen as a solution; repeat the demonstration with that step included and decide whether it is workable. Record the answers and any setup dependencies before signing.
After a simulation passes, decide whether a separate live service pilot is appropriate and agree its scope and fallback with the vendor. Real transactions require the normal operating process; do not treat a simulation as evidence of how every live exception will behave.
Next step: Bring this checklist to Fleksa and compare it with your proposed QR workflow. Fleksa’s QR ordering lets guests scan, order, and pay at the table in a browser. Use the restaurant management software discussion to confirm current support for your staff view, payment record, split-bill handling, and exception process before choosing a workflow.
Frequently asked questions
Is a guest’s QR payment confirmation enough to close a bill?
Use it to help find the transaction, but check the designated restaurant payment record for the matching bill, amount, and approved status before treating the bill as paid.
What should staff do when a payment is pending?
Keep the bill open and ask the shift lead to check the authoritative record. Follow the provider’s recheck and escalation process rather than treating pending as approval or immediately asking for another payment.
Does an approved split payment mean the whole table bill is paid?
No. Match the approved payment to its portion of the bill and check the remaining balance. Only treat the full bill as paid when the applicable balance has been covered and verified.
