Guests may be able to continue a QR order after switching networks, but you should not assume every ordering system handles the change the same way. The decision turns on what happens to the cart, table identity, submission status, and payment state—not simply whether the menu reloads.
Ask the vendor to show the complete path in both directions: restaurant Wi-Fi to mobile data, and mobile data to restaurant Wi-Fi. Set your pass criteria before the demonstration, then check what a guest and a staff member can actually see.
Start a cart on restaurant Wi-Fi, then switch
Begin with the service model you intend to use. Does a guest scan a code fixed to a physical table, choose a table after scanning, or show staff a code? A cart that survives a network change is less useful if the order loses its table assignment.
In a simulated environment, connect a phone to the restaurant Wi-Fi and scan the table code. Add items with the kinds of choices your menu requires: a size, a modifier, a special instruction, and a changed quantity. Leave the cart open, switch the phone to mobile data, and return to the same browser tab. Do not close the browser; this check isolates the network change rather than testing browser closure.
Look at the cart before touching the order button. Are the items, quantities, selected options, and displayed total still present? Is the same table identified? If the page needs a refresh, note whether refreshing restores the cart or starts a new one. A vendor should explain what the guest must do, not just say that a session is supported.
Then switch back to Wi-Fi with another simulated cart. A phone may take a moment to reconnect, so watch for a clear message rather than tapping repeatedly. Record the device, browser, connection direction, and result. One successful phone check does not establish behavior on every device your guests carry.
Fleksa’s QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask how the specific network-switch workflow behaves in the setup you are considering.
Check the cart and the order state separately
A visible cart is not proof that an order reached the restaurant. An empty cart is not proof that it did. The risky moment is a switch near submission, when the guest may be unsure whether to press the button again.
Use a vendor-provided test environment to trace three distinct points: before submission, immediately after submission, and after an order confirmation appears. For each point, ask what the guest sees and what staff see in the order system. The useful outcome is a recognizable state: still in cart, submitted and identifiable, or not submitted with a safe way to try again.
Ask how the system handles a second tap if the first result is delayed. Does it prevent a duplicate, or provide enough information for staff to identify and resolve one? Do not treat a loading screen as a confirmation. Equally, do not instruct a guest to reorder until staff have checked the order status.
Table identity matters in both views. Staff need to know which physical table the order belongs to, while the guest needs enough information to recognize the order they just placed. If your service uses a restaurant POS system, ask the vendor to demonstrate the handoff into the actual configuration you would use. A screen in isolation cannot show whether the front-of-house team can find the order.
Decide what happens when the system cannot give a clear answer. A practical fallback might be for staff to locate the order by its displayed reference and table, then enter an order manually only after checking for an existing submission. Confirm that the information needed for that check is available to the right staff member.
Trace a network change during payment
Payment needs its own check. A cart can remain intact while the payment screen is waiting for a response, and an order status may not tell the guest whether a payment was authorized. Ask the vendor to show how its ordering system and payment provider display the result at each step.
Start a simulated order on mobile data. Move to restaurant Wi-Fi just before the simulated payment response returns. In the test environment, examine the guest screen, the staff view, and the payment test record. Repeat with the switch after the response. Ask what happens if the result remains pending and how staff can resolve it without guessing.
Use a sandbox or another vendor-approved simulation that cannot create a real charge, send a guest message, or dispatch a courier. Do not use a real card for this practice. If the vendor cannot safely simulate the payment handoff, request a walkthrough and written explanation of the states instead; do not represent that as a completed live check.
Your acceptance criteria should cover more than a successful payment. A guest should be able to tell whether to wait, seek staff help, or retry. Staff should be able to check the payment and order states before advising a retry. Ask who can access those records, how a pending result is resolved, and what reference connects the guest’s screen to the staff view.
After a satisfactory simulation, a separate live service pilot can evaluate the operating procedure with the vendor and your team. Agree on its scope and safeguards beforehand. A practice simulation and a live pilot answer different questions; neither guarantees uninterrupted service in every network condition.
Use a decision worksheet before you buy
The following example is hypothetical. An owner with a table-service restaurant wants guests to order from their phones, while servers remain available to help. The owner uses one test phone and one table code for an initial simulation. The criteria below are the owner’s requirements, not claims about any product.
The worksheet connects each change to a result the owner can observe and evidence the vendor should provide. A result that needs staff intervention may still be acceptable if the owner has agreed to that workflow and can train the team for it.
| Moment | Owner’s acceptance criterion | Evidence to request | Decision if unmet |
|---|---|---|---|
| Wi-Fi to mobile, cart open | Items, options, quantity, total, and table remain identifiable in the same tab. | Demonstration and written recovery steps, including whether a refresh is needed. | Do not rely on guest self-recovery; assess staff fallback. |
| Switch near submission | Guest and staff can distinguish an unsubmitted cart from an identifiable submitted order. | Guest and staff views, plus duplicate-tap handling. | Require a workable status-check procedure before proceeding. |
| Mobile to Wi-Fi during simulated payment | Staff can check payment and order status before advising a retry. | Safe simulation or documented walkthrough of pending, successful, and unsuccessful states. | Keep this requirement open until the workflow is demonstrated. |
| Unclear result | A server can identify the table and follow a defined escalation path. | Staff instructions, support contact, and relevant order references. | Revise the service procedure or reconsider the product. |
Mark each row as demonstrated, explained but not demonstrated, or unresolved. Keep the device and browser details alongside the result. If the payment path was only explained, do not score it as a passed simulation. Ask for another demonstration when a software update, payment setup, or service configuration changes the workflow you evaluated.
The owner should also decide which exceptions are tolerable. For example, a refresh might be acceptable if the cart and table return and the guest receives a clear prompt. A lost table assignment may be unacceptable if staff cannot reliably reconnect the order to the right table. These choices depend on the restaurant’s service model, not a generic feature checklist.
Prepare staff guidance and vendor support
Write a short instruction for the people who will handle an uncertain order. It should say where to look for the table and order reference, whom to ask about payment, and when to escalate to the vendor. Include a non-phone fallback for guests who cannot or prefer not to use QR ordering.
Practice the conversation without creating a real order or payment: “Let me check whether your order came through before we try again.” Then walk through the staff screen in the test environment. The goal is to avoid both a duplicate order and an assumption that a missing confirmation means nothing happened.
Before signing, request written answers on session recovery, table identity, duplicate submissions, payment status, and support availability. Ask whether the answers apply to your intended devices, browser flow, payment provider, and POS configuration. For the broader operational fit, compare the workflow with your restaurant management software and read the guide to fitting QR ordering into table service.
Next, use the worksheet to compare your requirements with Fleksa QR ordering. Ask for a demonstration of the relevant workflow and resolve the open rows before buying.
Frequently asked questions
Will switching Wi-Fi always erase a QR cart?
Not necessarily. Recovery depends on the ordering system and its configuration. Check the same browser tab after the switch, including the items, options, total, and table identity.
Should a guest submit again if the screen is still loading?
Not until the order status is clear. Staff should check for an existing submission and payment result before advising a retry.
Is a simulated payment check the same as a live pilot?
No. A simulation should avoid real charges and guest communications. A separately planned live pilot evaluates the operating procedure under service conditions, with agreed safeguards.
