Skip to article
← Back to Blog
Operations

How to Correct a Confirmed Kiosk Order With the Wrong Price

By Fleksa7 min read•Restaurant kiosks, Payments, Restaurant operations

A wrong kiosk price can leave staff choosing between a partial refund and replacing an order. Use this worksheet to trace the guest conversation, approval, kitchen instructions and transaction record before selecting a workflow.

When a confirmed kiosk order has the wrong published price, staff need to settle two questions quickly: what the guest will be told, and how the transaction will be corrected. Give one person authority to approve the remedy, then connect the original order, any refund and any replacement in the record.

For an overcharge, a refund of the difference may leave the kitchen order intact. A full refund followed by a replacement may be easier to explain or necessary when a partial refund is unavailable, but it creates more steps and a risk of duplicate preparation. Choose based on what the payment and order systems actually support, not on which button looks simplest.

Set the decision before a price is wrong

A confirmed order may already have reached the kitchen, and the guest may be waiting with a receipt. Correcting the menu price for future guests does not necessarily correct that existing transaction. Treat the immediate order and the published price as separate tasks, with an owner for each.

Give the shift manager or another designated lead authority to approve a correction. Cashiers should know when they can act alone, when to call that lead and what to do if the lead is unavailable. A useful handoff identifies the order number, item, displayed price, intended price, payment status and whether preparation has started.

Start by explaining the discrepancy to the guest without blaming them. Confirm what they paid and what outcome is being offered. If the displayed price was lower than the restaurant intended, do not assume staff can simply charge the difference after confirmation. Agree on the next step with the guest and follow the restaurant's policy; involve a qualified adviser for questions about contract or legal treatment.

Next, stop the same error from reaching more guests. Assign someone to correct or temporarily remove the affected item from the kiosk menu, if the system allows it. Check the updated display before reopening it for orders. Ask whether prices are shared with other ordering channels so staff know where else to look.

A restaurant kiosk can let guests browse, customize and review an order before submission. The correction process after confirmation is a separate buying question: ask the vendor to show how its kiosk, payment and order records handle it.

Compare a difference refund with a replacement

Use a difference refund when the guest was charged too much, the order itself should stay as placed and the payment workflow supports the correction. The staff member should locate the original payment, enter or select the difference, obtain the required approval and tell the guest what to expect. The kitchen should receive a clear instruction that the existing order remains valid.

Before relying on this route, ask whether the refund can be tied to the original order and whether staff can see its status. A submitted refund is not the same thing as money appearing back in the guest's account. The vendor should explain what staff can see and what they should tell a guest who asks about timing.

Use a full refund and replacement when the original transaction cannot be corrected as needed, or when a new order is the clearer operational choice. Staff must establish whether to cancel the original kitchen ticket, whether food has already been prepared and who will enter the replacement. They should also explain that a new payment may be needed and obtain the guest's agreement before initiating it.

Replacement is a poor fit if the team cannot distinguish the old ticket from the new one, or if the guest cannot or does not want to make another payment. It can also create an unwanted delay while the first refund is pending. In those cases, pause and use the restaurant's approved manual recovery rather than improvising an unrecorded adjustment.

Neither route should erase the original transaction from the staff's understanding of what happened. The record should let a manager follow the original order, the reason for correction, the approval, the refund status and any replacement order. Ask how those details appear across the restaurant POS system, payment tools and order history.

Use a correction worksheet at the counter

The following figures are hypothetical. A guest has paid $14 for an item that the restaurant intended to list at $12. The item and its customizations are otherwise correct. The manager agrees to correct the $2 overcharge, and the kitchen has not started preparation.

The table compares the payment movements and handoffs. It is not an operating-cost comparison: fixed costs, processing fees and other variable costs, and exception costs such as wasted food or extra staff time are excluded. The amounts also do not describe tax treatment. Ask a qualified adviser how the restaurant should handle that where relevant.

StepRefund the differenceRefund and replace
Guest and approvalManager approves a $2 refund; guest keeps the existing order.Manager approves a $14 refund and explains the proposed $12 replacement payment; guest agrees.
Payment result$14 paid minus $2 refunded equals $12 net, once the refund is completed.$14 paid minus $14 refunded, plus $12 paid for the replacement, equals $12 net once both transactions are completed.
Kitchen actionShift lead confirms the original ticket remains active.Shift lead cancels or otherwise marks the original ticket according to the kitchen process, then identifies the replacement ticket.
Record and next ownerCashier records the reason and refund reference; manager checks its status.Cashier links the original, refund and replacement references; manager checks both transactions and the ticket handoff.

Under these assumptions, the difference refund is the simpler first choice if the vendor supports it and the manager can trace it. It preserves one kitchen order and avoids asking for another payment. The replacement route reaches the same $12 net only if the full refund and new payment both complete; a pending or failed step needs follow-up.

Now change one condition: the kitchen has already prepared the original item. A replacement ticket could trigger a second item unless the shift lead tells the kitchen what to do. Record whether the original food will be served, held or discarded under the restaurant's policy. Do not assume a refund automatically cancels a kitchen ticket, or that canceling a ticket automatically refunds a payment.

For either route, write down the next action rather than merely marking the incident closed. For example: “Manager to check refund status and contact guest through the agreed channel if follow-up is needed.” Store only the information your restaurant needs under its own policies; avoid putting full card details in a free-text note.

Run a vendor acceptance test before buying

Ask the vendor to demonstrate this workflow with a manager and the people who will handle the counter and kitchen. Start in a sandbox or other isolated practice environment. Use simulated orders and payment outcomes only: the exercise must not trigger a real card payment, guest message or courier dispatch. If the vendor cannot provide a safe simulation, use a walkthrough of screens and sample records instead.

  1. Create and locate the order. Simulate a confirmed order with an incorrect displayed price. Pass if staff can locate the order, displayed amount, payment status and relevant item without guessing. Fail if the records cannot be connected or staff cannot tell which transaction is being corrected.
  2. Approve a difference refund. Ask the vendor to show the requested adjustment and approval path. Pass if the team can identify who approved it, its amount and its status against the original transaction. Fail if the system cannot provide the needed trail; then assess the replacement or manual route instead.
  3. Walk through replacement. Simulate a full refund and a new order. Pass if staff can identify the original and replacement records and communicate the kitchen action without treating both as active meals. Fail if the process leaves the kitchen disposition or payment status unclear.
  4. Try an exception. Simulate a refund that cannot be completed or a manager who is unavailable. Pass if staff can stop, explain the unresolved status and assign a follow-up owner. Fail if the only available instruction is to retry without a record or to promise the guest a completed refund.
  5. Recover manually. Have the team practice using the restaurant's incident log and escalation contact. Pass if the order reference, amount, reason, guest communication and next action can be recorded without storing card details. Fail if the process depends on an undocumented verbal handoff.

Ask support: “If a refund status in the payment tool differs from the order history, who investigates, what reference should we provide, and how do we check progress?” Also ask which permissions, reports and integrations are included in the quote. The answer may depend on the payment provider and setup, so have each responsible party explain its part.

After the simulation, use a separate, carefully supervised live-service pilot only if your restaurant decides it is appropriate. Set an escalation contact, limit who can approve corrections and review real incidents afterward. Do not use real guests or payments to recreate the practice scenario.

Compare this workflow alongside installation, payment compatibility and staff fallback in your wider restaurant management software evaluation. Then compare your kiosk requirements with Fleksa and ask for a demonstration of the correction steps and confirmation of feature availability for your setup.

Frequently asked questions

Should staff change the menu price before refunding the guest?

Assign both tasks promptly. One person can prevent further incorrect orders while another handles the confirmed transaction. Changing the menu alone should not be treated as a correction to an existing payment.

Can a canceled kitchen ticket serve as proof of a refund?

No. Kitchen status and payment status answer different questions. Check and record both, along with any replacement order, so the manager can follow the full sequence.

What if the system cannot refund only the difference?

Ask whether a full refund and replacement is workable for the guest and the kitchen. If not, pause and use the restaurant's approved manual escalation process; record the unresolved amount and who will follow up.

Ready to grow your restaurant?

Explore how Fleksa can support ordering and operations in your restaurant.