When a guest cannot complete an online order, start with the last step they reached. If ordering is closed before they build a cart, check service availability. If the cart will not advance, check item requirements and order rules. If pickup works but delivery does not, investigate the address and delivery settings. If the guest reaches the payment screen, focus on the handoff and payment response.
Change one condition at a time. Otherwise, you may get a cart through without learning what blocked the guest. Use a simulated checkout for practice, and stop before any action that could charge a card, send a guest message, submit a real order, or dispatch a courier.
1. Reproduce the failure without creating an order
Ask the guest what they saw and where they got stuck. “Checkout does not work” can mean a closed ordering page, a missing item option, an address rejection, or a payment screen that never returns. Those need different checks.
Record the time and time zone, pickup or delivery, requested fulfillment time, device, browser or app, and the exact visible message. Note the items and options in the cart, but leave out the guest’s name and contact details unless they are necessary for an authorized support request.
Try the same path in an approved test environment if one is available. If it is not, reproduce only as far as you can safely go on the live site. Do not click a final submission button simply to see what happens. Ask the provider how to simulate later steps without creating a real order, payment, message, or courier dispatch.
The table below maps the last successful step to the next useful check. It is a starting point, not proof of the cause: an error can appear later than the setting that caused it.
| Last step reached | Check next | Useful comparison |
|---|---|---|
| Ordering page opens, but service is unavailable | Service hours, location, and requested time | Another eligible time or pickup instead of delivery |
| Items are in the cart, but checkout will not advance | Required choices, item availability, and minimums | One simple available item versus the original cart |
| Pickup advances, but delivery does not | Address entry and delivery eligibility | The same cart and time with pickup selected |
| Payment screen opens, but the guest cannot finish | Payment response and return to checkout | An authorized simulated payment path, if available |
If the issue appears only on one device or browser, note that difference. Ask the guest to try another browser or refresh only when doing so will not risk a duplicate submission. A browser change can help isolate the problem, but it does not explain whether the original issue was a page, connection, or payment problem.
2. Check service availability and the cart
Start with the location and service the guest selected. A restaurant may be open for pickup while delivery is unavailable, or a requested time may fall outside the ordering window. Check the relevant service schedule, special closures, and any lead time or cutoff configured for that location. Compare the requested time with another time that should be eligible.
Next, simplify the cart. Start with one available item and all required choices selected. If that cart can advance, add the original items and options back one at a time. Pay attention to items sold only during certain hours, options that became unavailable, and required selections that may be easy to miss on a small screen.
Check minimum order rules against the amount to which the rule actually applies. A guest may see a cart total above the minimum while the qualifying subtotal is lower because the rule excludes certain charges. Ask your provider where that threshold is shown and which amounts count toward it. Do not assume the displayed total and qualifying amount are the same.
Hypothetical decision example: A guest selects delivery for 6:30 p.m. and adds a sandwich with a required side. The cart will not advance. An operator recreates the cart in a safe test environment and sees that no side is selected. After choosing a side, the cart advances to address entry. The useful finding is a cart-validation issue; payment has not yet been tested. If the side was already selected, the next step would be to compare the item’s availability and the service time rather than changing several settings at once.
When a rule is working as intended but guests repeatedly miss it, look at how the requirement appears on the ordering page. A clear prompt can matter as much as the setting itself. Your restaurant website should also make it easy for guests to find the correct location and ordering entry point.
3. Separate delivery address problems from payment problems
Keep the cart and requested time the same, then compare pickup and delivery. If pickup advances and delivery stops at the address step, check the address format and the restaurant’s configured delivery area. A street address, apartment number, or ZIP code may have been entered in the wrong field. Ask the guest to check their entry rather than collecting more personal information than you need.
Next, check whether the selected location serves that address at the requested time. A delivery boundary and a delivery schedule are separate conditions. An address can be within the area but still unavailable for a particular time. If the address should qualify, give support a sanitized description of the result and use their approved method for sharing any location detail needed to investigate.
If both pickup and delivery stop before payment, return to service and cart checks. If both reach payment and fail there, a delivery boundary is less likely to explain the shared failure. If only delivery fails after the payment screen opens, retain that distinction for support; do not assume the address is the cause just because delivery was selected.
At the payment stage, note what the guest actually sees: a declined response, a loading screen, an error after returning to checkout, or no clear confirmation. These are different symptoms. Check the ordering provider’s and payment provider’s status or support channels, and ask who owns the handoff between them.
Use an authorized test payment method only in a provider-approved test environment. A practice scenario must not create a real charge, order, guest message, or dispatch. If no safe payment simulation is available, stop before submission and ask the provider to help trace the handoff. Never ask a guest to send a card number, security code, or full payment screenshot for troubleshooting.
If a guest is unsure whether an order went through, check the restaurant’s order records and ask the payment provider how to verify the transaction before suggesting another attempt. A missing confirmation is not, by itself, proof that nothing was submitted or charged.
4. Escalate with a short, sanitized sequence
Send support a sequence another person can follow, not just “checkout broken.” Include the location, approximate time and time zone, service type, requested fulfillment time, device and browser, and the exact error message. List the cart items and choices needed to reproduce the issue, along with the last successful step.
Also say what you compared. For example: “The same cart advanced with pickup but stopped after delivery address entry.” Or: “A single item advanced; adding the second item brought back the required-option message.” These observations help support choose a starting point without treating your first guess as the answer.
Remove names, contact details, full addresses, card data, and payment credentials from notes and screenshots. Use the provider’s approved secure channel if specific account or order information is needed. Ask support which identifier is safe and useful to share instead of sending a complete payment record.
For an active service problem, give staff a temporary procedure: who checks for an existing order, who contacts support, and what alternative ordering method staff may offer. Keep that separate from a live service pilot. A pilot uses real operating conditions and needs an agreed plan for handling real orders, payments, guest communications, and delivery; it is not a substitute for a safe simulation.
Once the immediate issue is understood, review whether your ordering setup gives staff enough visibility into service rules and errors. The online ordering guide covers broader system choices. For a potential provider, ask how its team handles test environments, payment escalation, and delivery eligibility checks.
Next step: Review Fleksa’s restaurant online ordering page. If it fits your operation, ask for a demonstration using a failed-cart and delivery-address scenario, including how to test safely before a live launch.
Frequently asked questions
Why can a guest order pickup but not delivery?
Delivery may have different hours, address eligibility, or other configured conditions. Compare the same cart and requested time with each service selected, then check where the delivery path stops.
Should I ask a guest to try paying again?
First check whether an order or payment was already recorded. A missing confirmation does not establish that the attempt failed, and an immediate retry could create a duplicate.
What should I send ordering support?
Send the time, location, service, device, exact message, last successful step, and a sanitized sequence of what you tried. Do not send card details or unnecessary guest information.
