When a guest asks for a receipt after ordering from their phone, first check whether the payment was completed. Then offer a receipt through a supported channel, or help the guest find it. If payment is still pending or failed, explain that an order confirmation is not proof of payment.
Build that distinction into your QR ordering workflow before a busy shift. Staff need to know where to look, what they can share, and what to do when the guest entered the wrong email address or phone number. The aim is simple: give the right guest useful proof without exposing another guest’s information.
Choose receipt formats and delivery channels
Start by asking what your guests expect. Some want a digital record they can find later. Others need a printed copy before they leave. A guest who shares a table may need proof for only their own payment, not a record of everyone’s order.
Ask each vendor which of these options it supports, and whether they apply to your particular payment setup:
- On-screen confirmation: Can the guest view a receipt after payment and return to it if they close the page?
- Email: Can the guest request a receipt, check the address, and ask for it again?
- Text message: Is a receipt sent directly, or does the message contain a link? What happens if the number is wrong?
- Print: Can staff print a customer copy, and what printer or connection does that require?
- Staff-assisted lookup: Can an authorized employee find the transaction and provide an appropriate copy?
Do not assume that every confirmation page is a receipt, or that a printed kitchen ticket serves the same purpose. Ask to see what each document contains: merchant name, date, items, total, payment status and any transaction reference. If guests need other details, ask whether those can appear before choosing a system.
Fleksa’s QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. When evaluating it or another system, ask which receipt channels are available with your payment setup and whether guests can choose among them. A browser-based ordering flow alone does not tell you how receipts are delivered.
Also decide whether a contact detail is needed for the guest’s chosen delivery method. If someone wants a printed copy, ask whether staff can provide one without collecting an email address. If email is the only digital option, make that clear before the guest finishes.
Use payment status to choose the next step
An order can reach the restaurant without its payment being complete. Your procedure should separate the order record, the payment record and the document sent to the guest. A receipt described as proof of payment should follow a completed payment, not simply an accepted order.
Use the following decision tree as a starting point. The staff action depends on what the system shows, not on whether the guest received an order confirmation.
| What staff see | What it means for the request | Next action |
|---|---|---|
| Payment completed | A payment receipt may be available. | Match the transaction to the guest and provide a supported copy. |
| Order accepted; payment pending | The order exists, but completed payment is not yet shown. | Check again through the approved workflow; do not label the order confirmation as a paid receipt. |
| Payment failed or canceled | There is no completed payment to document for that attempt. | Explain the status and follow the restaurant’s payment procedure. |
| Status unclear or records disagree | Staff cannot safely confirm payment from the information available. | Escalate to the person responsible for checking the payment record. |
The table is a service guide, not a substitute for your provider’s status definitions. Ask the vendor what each status means, where it appears to staff, and whether a payment can remain pending after the kitchen has received an order. Agree on who can investigate a mismatch and how quickly staff should ask for help.
Hypothetical example: A guest orders a sandwich and a drink at the table. The order screen says the order was accepted, but the staff payment view says pending. The server can confirm that the order is in the system, but should not tell the guest the payment is complete or hand over an order confirmation as a paid receipt. If the payment later shows completed, the server follows the restaurant’s receipt procedure. If it fails, the server follows the payment procedure instead.
Split payments deserve their own question. Can staff see which part each guest paid, and can the system produce a receipt for that payment without disclosing another guest’s details? Ask the vendor to show the exact staff and guest views. For more on the distinction between table payments and paid-status proof, see QR payment, split bills and paid-status proof.
Give staff a path for missing receipts
A missing message does not necessarily mean the payment failed. It may have gone to the wrong address, been filtered, or never been requested. Start with the payment status, then look for the right transaction using the information your system permits.
- Ask for a limited starting point. Use an order reference if the guest has one. Otherwise, ask for details such as the approximate time, table and order items. A table number alone may not identify the right guest, especially when several parties have used the table.
- Find the order and check payment. Look in the approved staff view. If your restaurant POS system and QR ordering system show different information, follow the escalation path rather than guessing.
- Confirm the match without displaying other records. Ask the guest to describe the order or give an available reference. Do not read out a list of names, email addresses or other guests’ purchases.
- Offer an available copy. If the transaction is paid and matched, use a supported channel. Ask the guest to enter or confirm a destination privately if a digital copy is needed.
- Record an unresolved request. If staff cannot match the payment or the delivery tool is unavailable, tell the guest who will follow up and how. Do not promise an immediate receipt that the system cannot produce.
Decide in advance who can resend or print a receipt. A server may be able to look up an order, while a manager handles corrections or uncertain matches. Ask whether access can be limited by role and whether a resend creates a record that staff can check later.
For a guest who has already left, establish a separate callback process. Collect only the details needed to locate the transaction and contact the guest. Do not send a receipt to a newly provided address until staff have followed your matching procedure. If the match remains uncertain, escalate rather than guessing.
Protect contact details and practice the handoff
Receipt delivery puts guest contact details in the service flow, so make the handoff deliberate. Ask the vendor where email addresses or phone numbers appear, which employees can see them, and whether staff can correct a destination without changing the underlying transaction. Find out how long the system keeps contact details and how your team can handle a guest’s request about them. For contract or legal questions, consult a qualified adviser.
Use private entry where the system supports it. If staff must confirm an address aloud, avoid repeating the full address across a crowded dining room. A staff screen should not be turned toward a guest if it displays other orders or contact details. A printed receipt should be handed to the matching guest, not left in a shared pickup area.
Before launch, run simulated checks with fictional guest details and test records in a safe environment. The simulation should not trigger a real payment, guest message or courier dispatch. Walk through a completed payment, a pending payment, a failed payment, a mistyped address, a closed browser page and two similar orders at the same table. For each, ask staff to explain what they see, what they would offer, and when they would escalate. Confirm with the vendor how to perform these checks safely.
A live service pilot is different: actual guests and transactions are involved. If you choose to run one, brief staff on the approved workflow, limit access to the records they need, and have a manager available for uncertain cases. Review whether guests could get the copy they requested and whether staff could resolve issues without exposing someone else’s details. Do not treat a successful simulation as proof that every live-service exception is covered.
Next step: Write down your preferred receipt channels, the payment statuses staff must recognize, and who handles an unresolved request. Bring that list to a restaurant management software evaluation and ask the vendor to walk through the same receipt request from the guest and staff sides.
Frequently asked questions
Is an order confirmation the same as a receipt?
Not necessarily. An order confirmation can show that an order was accepted without proving payment completed. Check the payment status and the contents of the document before describing it as a paid receipt.
What if a guest entered the wrong email address?
First match the guest to the transaction and confirm payment status. Then use the system’s supported correction or resend process. If staff cannot establish the match or change the destination safely, escalate the request.
Can each guest get a receipt after splitting a bill?
That depends on the ordering and payment setup. Ask the vendor whether it can provide a receipt for each completed payment and what information about the other guests appears on each copy.
