Guests may be able to complete a table order after declining optional tracking, but you need to check the particular ordering and payment flow before buying. Ask the vendor to demonstrate the path with optional cookies declined, from the first scan through a simulated payment outcome and staff handoff.
The key distinction is between data used to run an order and data used for optional analytics or marketing. A guest may decline the latter while the ordering service still needs a way to associate a cart with a table. The vendor should be able to explain what is used, why it is used and what happens when the guest says no.
This question is separate from whether a guest must create an account. Even a browser-based flow without an account can use cookies or other storage. Check both the privacy choice and the ordering journey on the devices your guests are likely to use.
Separate order session data from optional tracking
Start by asking for a plain-language inventory of the data and technologies involved in one table order. Do not assume that everything called a cookie serves the same purpose. The flow may also use browser storage, a URL parameter or a server-side session.
Order-related information may include a table identifier, cart contents, a session identifier and payment status. Ask which items are needed for the workflow, where they are stored, how long they remain and what happens if they are unavailable. For example, a table identifier can help route an order to the right place, but it must still identify the correct physical table after the guest makes a privacy choice.
Optional analytics or marketing may include tools used to measure visits, track behavior across pages or support advertising. Ask the vendor to identify these separately, including any tools supplied by payment or other third parties. A category label alone is not enough: request the purpose and behavior of each item.
Also ask how a guest can decline optional tracking and later change that choice. Check whether decline is as visible and understandable as acceptance. The practical buying question is whether that choice leaves the ordering path usable, not whether a banner appears on the screen.
Trace a declined-consent scan from table to cart
Use a simulated environment for the first walkthrough. It must not create a real charge, send a message to a guest or dispatch a courier. Ask the vendor to show you what staff would see using test records and simulated payment outcomes. Then decide whether a separate, controlled live-service pilot is warranted.
Hypothetical example: A restaurant assigns a test QR code to physical table 6. One party scans it, declines optional tracking and adds two meals and one drink to the cart. The owner wants the cart to retain all three items and the order to stay associated with table 6 through the payment handoff.
Begin with a fresh browser session. Scan the code, decline optional tracking and check the menu. Add the items, change a quantity and remove an item. Navigate away from the cart and return using the ordering flow. Does the cart still show the intended items, and is the table association still correct?
Repeat the path with a second simulated party at a different physical table. The acceptance requirement is separation: neither party should see the other party’s cart or be assigned the other table. If your service model allows several guests at one physical table to order independently, ask how those carts and payments are kept distinct. Do not assume that one table code automatically supports the way your dining room splits checks.
Include a common interruption. Lock the phone or switch briefly to another app, then return. Ask what happens if the guest refreshes, closes the browser or scans again. Some session loss may be acceptable, but staff need a clear recovery path. Decide in advance whether the guest must rebuild a cart or whether the system can restore it without introducing a table mix-up.
Check cart, payment and staff handoff
A QR menu is not automatically an ordering or payment system. Before comparing products, write down what your service requires: browsing only, ordering for staff payment, or ordering and paying in the browser. Fleksa’s QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. Confirm the consent behavior and setup for the workflow you intend to use.
For a flow that requires payment, ask the vendor to demonstrate the transition from cart to payment with optional tracking declined. Check that the item summary and amount presented for payment match the cart, and that the table identity is preserved. Use a simulated payment result rather than a real card.
Walk through at least three outcomes: payment succeeds, payment fails and the guest leaves before the outcome is clear. For each, ask what the guest sees, what staff see and whether the order is sent for preparation. Your acceptance criteria should prevent staff from treating an uncertain payment as confirmed. Also ask how staff can resolve an abandoned or duplicated attempt without guessing.
Consider the people who cannot or do not want to use their phones. Can staff take an order and payment through your normal process, and can they tell it apart from the QR order? If you use a restaurant POS system, ask how order and payment status appear there and whether the intended connection is available in your setup. A clear fallback matters more than forcing every table through the same route.
A separate live-service pilot, if you choose one, should have staff ownership, a limited scope and an agreed fallback. Unlike a simulation, it involves actual service, so agree in advance how real orders and payments will be handled. Do not treat a successful simulated screen as proof that every service condition will work.
Use a decision worksheet and request evidence
The worksheet below applies to the hypothetical table 6 scenario. It records the owner’s requirements, not a claim about any vendor. Use the same rows when comparing quotes and demonstrations. Add a requirement only if it matters to your own service model.
| Decision point | Owner’s acceptance criterion | Evidence to request | Result to record |
|---|---|---|---|
| Privacy choice | A guest can decline optional tracking and continue to the menu. | Demonstration from a fresh browser session and an explanation of what remains active. | Pass only if decline is available and the menu opens. |
| Table and cart | Table 6 remains correct; the cart reflects the guest’s edits without mixing with another table. | Two-table simulated walkthrough, including a return to the cart. | Record each table assignment and any lost or mixed items. |
| Payment handoff | The displayed amount matches the cart; a failed or uncertain payment is not shown to staff as paid. | Simulated success, failure and interruption, with guest and staff views. | Record the status and recovery action for each outcome. |
| Storage and control | The owner understands what is stored, for how long and how a guest changes their choice. | Written data inventory, retention details and consent settings for the proposed setup. | Record unanswered items and who will resolve them before purchase. |
For each row, note the device and browser used, the configuration shown and whether the demonstration matches your intended service. A pass on one phone is useful evidence, but it does not establish behavior on every device. Ask which browsers and devices the vendor supports and which combinations should be included in your own checks.
Request the information in writing as well as on screen. Ask who controls consent settings, who can change retention periods and whether changes apply to third-party tools. Find out what happens when an order session expires, how abandoned carts are handled and how an owner can request a change. If the vendor cannot demonstrate a required behavior, record it as unresolved rather than assuming it works.
Finally, compare the operational quote with the service you actually plan to run. Ask what setup, support and payment-processing charges apply, and which third parties are involved. A quoted processing fee is not the same as the all-in operating cost. Fleksa states that it charges no commission on table QR orders; processing and applicable tax still apply. Get the costs and workflow details for your proposed setup in writing.
For more on the service-model decision, see the guide to where QR ordering fits in table service.
Next step: Use the worksheet to compare your requirements with Fleksa. Share your acceptance criteria with the team and ask for a simulated demonstration of the relevant QR ordering workflow before buying.
Frequently asked questions
Can a guest decline optional cookies and still order?
That depends on the ordering flow and its configuration. Ask for a demonstration with optional tracking declined, including the cart, table association and payment path if your service requires payment.
Does declining tracking mean no order data is stored?
Not necessarily. An ordering service may need session and order data to maintain a cart or identify a table. Ask the vendor what is stored, its purpose and retention period, and which items are optional.
What should staff do if the payment result is unclear?
Use an agreed fallback rather than assuming the guest has paid. Ask the vendor how staff can check and resolve an uncertain status, and practice the process with simulated outcomes before live service.
