When an item sells out after a guest adds it to the cart, checkout should stop long enough to explain the change. The guest should be able to remove the unavailable item or choose an available alternative, review the new total, and confirm the revised order before payment proceeds.
That sounds simple, but the result depends on when the ordering system checks availability, how quickly staff can update it, and what happens if payment or order submission has already started. A good buying decision starts with those transitions, not just a menu screen that marks an item sold out.
Identify when availability is rechecked
Ask a vendor to walk through the full path from adding an item to receiving an accepted order. A menu can show an item as available when the guest selects it, yet the last portion may sell while the cart sits open. The important question is whether the system checks again before committing the order.
Ask what triggers each check: opening the cart, beginning checkout, submitting payment, or another event. Then ask what happens if availability changes between the final check and order acceptance. A check earlier in the journey is useful, but it does not by itself settle that last gap.
Clarify who supplies the availability information. Does a staff member mark an item unavailable manually? Does another system provide a status or quantity? If a connection is involved, ask how updates move between systems and what happens when an update is delayed or the connection is unavailable. Do not assume that an ordering menu knows how many portions are left.
Also ask whether availability applies to an entire item or to specific choices. A chicken sandwich might be available while its gluten-free bun is not. The same question applies to required sides, optional add-ons, sizes, and pickup or delivery times. A useful checkout response identifies the choice that needs attention without unnecessarily removing the rest of the meal.
For a broader view of channel and menu requirements, use the online ordering buying guide. For this decision, keep the focus on the moment a previously valid cart becomes invalid.
Explain the change before payment
The guest needs a direct message at the point of action: name the unavailable item or option, say it cannot be ordered, and show what the guest can do next. A generic error at the top of checkout forces the guest to search the cart and may leave them unsure whether the order went through.
Keep the rest of the cart visible where possible. If the guest has added drinks and a second meal, removing one sold-out dish should not require rebuilding everything. Ask whether notes and other valid selections remain after an edit, and whether the checkout page returns the guest to the right place.
Before the guest confirms the revised order, the system should show the changed items and an updated total. Ask how it recalculates discounts, delivery charges, and other fees when the cart changes. A promotion may no longer apply after an item is removed; that change should be visible rather than a surprise on the final receipt.
There is a practical trade-off in when to interrupt. An early warning gives the guest more time to decide, while a final check catches later changes. Ask whether the ordering flow can do both and what the guest sees if the status changes during checkout. The goal is a clear decision before a payment attempt, not a promise that stock can never change again.
Consider the guest who leaves the cart open while asking a family member what they want. A stale cart is not necessarily an error by the guest. The message should tell them what changed and provide a useful next action, rather than blaming them for waiting.
Offer removal or a verified alternative
Hypothetical example: A guest adds two $12 lunch bowls and one $4 drink. Before checkout, one bowl sells out. The original item subtotal is $28. Removing the unavailable bowl leaves a $16 item subtotal. Choosing an available $10 sandwich instead produces a $26 item subtotal.
These figures include item prices only. They exclude fixed charges, variable charges such as payment processing, and exception costs such as refunds or staff time. Any delivery charge, discount, or other fee must be recalculated separately and shown in the checkout total. The example illustrates the guest decision; it does not describe a particular provider's features.
Removal should be straightforward. If an alternative is offered, ask how it is selected and whether its availability is checked when the guest chooses it. A suggestion that has also sold out merely creates another interruption. The replacement should not be silently added: the guest needs to accept the item and its price.
Check what happens to modifiers and dietary choices. If a bowl with a selected sauce is replaced by a sandwich, carrying the old choice across may make no sense. The guest should be asked for any required choices on the new item. Avoid presenting an alternative as equivalent for an allergy or dietary need unless the restaurant can support that description.
Sometimes removal is the better option. A guest ordering one specific meal may prefer to cancel the cart rather than accept a substitute. Ask whether they can leave without placing the order and whether an empty cart is handled clearly. Staff should also know what the guest saw, so a later call does not begin with conflicting assumptions.
Test payment and order submission safely
Use the following acceptance checklist with the vendor. The expected result is a buying requirement to verify, not a claim that every ordering product supports it. Ask for a demonstration using a simulation or sandbox that cannot take a real payment, send a guest message, or dispatch a courier.
| Simulated check | Action | Expected result | Question to resolve |
|---|---|---|---|
| Stale cart | Add an available item, then mark it unavailable before checkout. | The guest is told which selection changed and can edit the cart. | At what point is availability rechecked? |
| Alternative | Offer a substitute, then make it unavailable before selection. | The guest is not led to confirm that unavailable substitute. | When is the substitute checked? |
| Revised total | Remove the item or select an available alternative. | The guest can review the changed order and recalculated total before confirming. | What happens to fees and discounts? |
| Repeated action | Simulate a slow response and repeat the payment or submit action. | The guest receives a clear status without unintended duplicate payment attempts or duplicate accepted orders. | How are retries and uncertain responses handled? |
| Late change | Simulate an item becoming unavailable after payment begins. | The order and payment statuses are visible to staff, with a defined resolution path. | Who decides whether to adjust, cancel, or refund? |
The first three checks address the guest's decision. The last two cover the harder boundary between checkout and the restaurant receiving an order. Ask the vendor to show both the guest-facing status and the staff-facing record. A guest should not have to guess whether to press the button again, and staff need enough information to avoid preparing the same order twice.
Separate a payment attempt, an authorization, a completed charge, and an accepted order when discussing failures. They are different events. Ask how staff can identify each status, what a guest is told when the outcome is uncertain, and how a duplicate or unwanted charge would be corrected. Do not assume that canceling an order automatically resolves every payment state.
Also ask what the kitchen sees. If an order cannot be accepted because an item is unavailable, is it kept out of the normal preparation queue? If the guest revises it, can staff distinguish the final version from an earlier attempt? Agree on who checks unresolved orders and how the team records the outcome.
A simulation is useful for repeatable checks, but it does not prove every live-service condition. If you later run a live pilot, agree with the vendor on its scope, staff responsibilities, and how actual orders and payments will be handled. Tell the team when the pilot is active and stop it if order or payment status becomes unclear.
Use the checklist on your current setup, then ask Fleksa about restaurant online ordering, including verified US availability and how its checkout handles these specific cases. If you are also reviewing the guest entry point, consider how the ordering flow fits your restaurant website.
Frequently asked questions
Should a sold-out item be removed automatically?
Ask whether the guest can see and approve the change before the order continues. Automatic removal without a clear notice can leave someone paying for an incomplete meal they did not intend to order.
What if an item sells out after payment starts?
The restaurant needs a clear view of both payment and order status, plus a defined way to contact the guest and resolve the order. Ask the provider how adjustments, cancellations, and refunds are handled in that situation.
How often should availability be checked?
Ask for checks that support a clear warning during checkout and address changes before order acceptance. The exact timing depends on the system, so have the provider demonstrate what happens between its final check and submission.
