When a kiosk stops responding during payment, staff should first check the payment result in the payment system—not ask the guest to tap again. Then check whether an order exists and whether the kitchen has received it. A frozen screen alone cannot answer any of those questions.
Move the guest to a staffed position if needed, but keep the original transaction and cart identifiable until their status is resolved. The goal is to avoid both a duplicate charge and a duplicate meal while giving the guest a clear next step.
Trace the cart, payment and order separately
Think of an interrupted kiosk transaction as three related records. They may not all be at the same stage when the screen freezes.
- Cart: What did the guest select, customize and review? A cart may still be visible without an order being complete.
- Payment: Did the payment system report a completed transaction, a decline, a pending result or no identifiable attempt?
- Order: Was an order created? If so, did it reach the kitchen, and has preparation started?
Assign a staff member to check each record using the identifiers your system provides. Depending on the setup, those might include a kiosk number, approximate time, order number or transaction reference. Ask the guest what happened, but do not collect a full card number or other sensitive payment details to reconstruct the event.
Check the payment system's own status and follow the processor's instructions for interpreting pending or completed transactions. A guest's phone notification or the kiosk's last screen can help locate an attempt, but should not be the only evidence used to decide whether to charge again.
Then check the restaurant POS system for an order and the kitchen display system or other kitchen workflow for a matching ticket. Ask the vendor how staff can find these records and whether they can see a common reference across them. Do not assume a payment record automatically means the kitchen has a ticket, or that a cart on screen means payment succeeded.
Use a decision worksheet at the counter
Hypothetical example: A guest selects a sandwich and a drink, taps a card, and sees the kiosk freeze. A staff member notes the kiosk number and approximate time, then checks payment and order records. The worksheet below shows possible findings and responses; each row is an alternative, not a sequence.
| Payment finding | Order finding | Staff response |
|---|---|---|
| Completed | Matching order is in the kitchen | Do not charge again or create another order. Confirm the order with the guest and check its progress. |
| Completed | No matching order found | Keep the payment reference. Follow the manager's documented process to fulfill or resolve the paid transaction; check the kitchen before any manual ticket is sent. |
| Declined, with no other successful attempt found | No order sent | Explain the result and offer a new payment attempt at a working staffed position, after confirming the first attempt's status. |
| Pending or cannot be identified | Order status uncertain | Do not retry payment yet. Escalate to the person who can check the processor and kitchen records; explain the wait and available options. |
The difficult row is the last one. A pending or unknown result is not proof of either payment or failure. Your manager should know where to look, whom to contact and how to document the issue if the processor cannot provide an immediate answer. Set an internal escalation path rather than leaving a cashier to guess.
For a completed payment with no order, a manual ticket may be a practical way to feed the guest, but only after staff confirm that a matching ticket is not already being prepared. Record how the paid transaction relates to that ticket. If fulfillment is not possible, use the processor's and restaurant's documented resolution process; do not promise that a payment will disappear or be returned by a particular time.
Use plain language with the guest: “The screen stopped, so I am checking whether the payment went through and whether the kitchen received your order. Please hold off on tapping again.” Give an update if the check takes time. If the guest chooses not to wait, record a contact method only under the restaurant's normal privacy procedures and explain who will follow up.
Test interruptions on both sides of confirmation
Before buying or changing a restaurant kiosk, ask the vendor to walk your team through what happens when a session stops responding before payment confirmation and after payment confirmation. The distinction matters: the same frozen display can accompany different payment and order results.
Start with a simulated check in a designated training or test environment. Agree on the test conditions with the kiosk provider and payment processor. The simulation must not cause a real card payment, guest message or courier dispatch, and it must not send a real kitchen ticket. Use simulated payment outcomes and a test kitchen destination or another safe way to observe the order state.
- Before confirmation: Simulate an interruption while payment is being attempted. Have a cashier locate the cart, inspect the payment status and determine whether an order was created. Try both a simulated decline and a simulated pending result.
- After confirmation: Simulate a completed payment followed by a kiosk interruption. Check whether the order exists and whether the simulated kitchen destination received it. Also ask how staff should handle a completed payment with no matching order.
- At handoff: Have another staff member take over using only the recorded references and handoff notes. They should be able to identify what is known, what remains unresolved and who owns the next action.
Record the acceptance criteria before the walkthrough. A useful pass means staff can find the payment result without guessing, distinguish an existing order from a cart, identify any kitchen ticket, and choose the correct response from the worksheet. For a pending or unknown result, the expected response is escalation, not another charge. If a status cannot be found or a handoff depends on memory, record the gap and ask the vendor how it will be resolved.
Keep this simulation separate from a live service pilot. A live pilot involves actual guests and operating systems, so agree on staffing, escalation, guest communication and transaction-handling procedures before starting it. Do not deliberately interrupt a real guest's payment to create a practice case. Observe normal use and log genuine incidents without assuming the test environment proves every live outcome.
Make the handoff and reset safe
Put a short interruption form beside the register or in the staff system. It should capture the kiosk identifier, time, relevant order and transaction references, payment status, kitchen status, action taken, person responsible and next check. Record only the payment details needed to find the transaction; avoid writing down full card numbers.
Make ownership explicit. For example, the cashier can stay with the guest while a shift lead checks the payment system. If the lead takes over the case, the notes should say whether the guest is waiting, whether the kitchen has been contacted and what must happen next. A shift change should not turn an unresolved payment into a forgotten one.
Do not immediately clear the kiosk just to make it available for the next guest. First preserve the references and check whether the current session can be safely ended. Ask the vendor which reset steps close a session, what happens to a pending payment and cart, and how staff can prevent the next guest from seeing the previous guest's information. Follow the documented procedure for your hardware and payment setup.
Once the original session is safely closed, a staff member can direct the next guest to the kiosk or to another ordering point. If the status remains uncertain, take the kiosk out of use until the responsible person decides it is safe to return. The unresolved transaction still needs its own follow-up; resetting a screen does not settle a payment.
Before your next vendor conversation, take the worksheet and your handoff form to the counter. Ask Fleksa to show how its available workflows would support each check in your proposed setup, including the payment and kitchen connections you plan to use. Compare your kiosk requirements with Fleksa's kiosk workflow.
Frequently asked questions
Should a guest tap their card again if the kiosk freezes?
Not until staff have checked the first attempt's status. If it is pending or cannot be identified, escalate rather than risking a second charge.
What if payment completed but the kitchen has no order?
Keep the payment reference and check for a matching ticket before creating another. Follow the manager's process to fulfill the paid order or resolve the transaction.
Can staff reset the kiosk during an unresolved payment?
Record the relevant references first and follow the vendor's reset procedure. Confirm what the reset does to the session and pending payment; a reset does not itself resolve the transaction.
