When a guest says an online payment failed, check two things separately: whether the restaurant accepted an order and what the payment provider shows for the attempt. Neither the guest’s error message nor a pending bank entry alone answers both questions.
Start by finding the order in your ordering system. Then have an authorized person check the payment record. If either result is unclear, tell the guest what you know, avoid promising a charge or refund outcome, and send a concise handoff to the right support team. Don’t ask the guest to place another order until you have checked for an existing one.
Separate the payment attempt from the order
A guest may see an error after entering payment details without knowing how far the order got. The restaurant may have an order record, a payment attempt, both, or neither. Those records can update at different times, so a quick look at one screen is not a complete answer.
Ask the guest for the name used on the order, the approximate time, the order total, and any order number or error message. Ask whether they received an order confirmation and whether their bank shows an entry. A screenshot of an error can help, but ask them to remove card numbers and other sensitive details before sharing it.
Search the ordering system using the permitted details. Check the order’s status, items, fulfillment time, and whether the kitchen has received it. An order number helps narrow the search, but staff should still verify the status rather than treating the number alone as proof that the order was accepted.
Next, an authorized staff member should check the payment provider’s record using the available reference, amount, and time. Record the status exactly as displayed. If the screen uses a term your team does not understand, pass it to support rather than translating it into a promise to the guest.
The table below shows how to act on common combinations. It is a starting point, not a substitute for checking the actual records.
| Order record | Payment record | Staff action |
|---|---|---|
| Accepted | Successful or completed | Confirm the order details and fulfillment plan with the guest. |
| Accepted | Pending, failed, or unclear | Pause and ask an authorized manager to check how the order should be handled; do not assume the charge outcome. |
| No accepted order found | Successful, completed, or pending | Escalate with both records; do not promise that placing another order is risk-free. |
| No accepted order found | No matching attempt found | Recheck the time, amount, and channel; ask support to investigate if the guest still reports a bank entry. |
Agree on one person to own the case. Otherwise, the kitchen may prepare a duplicate while the front counter tells the guest to try again. The owner should note who is checking payment, who is checking the order, and when the guest can expect an update.
Check the payment status with permitted access
Give front-line staff enough access to find an order and identify the next step, without giving everyone unrestricted payment-account access. A manager or designated payment contact can check provider details where necessary. Decide in advance who covers that role during evenings and weekends.
For each attempt, capture the provider name, the status wording, the amount, the time shown, and a transaction reference if available. Note the time zone if the provider and ordering system display different times. If the guest tried more than once, list each attempt separately; matching only on amount can connect the wrong payment to the order.
Look for a status history or later update if your provider makes one available. A record marked failed may have a reason or a reference useful to support. A record marked pending may need further investigation. An absent record may mean the search details are wrong or that the attempt did not reach the place you are checking. None of those possibilities should be presented as a settled fact without confirmation.
Keep the search narrow and protect the guest’s information. Staff do not need a full card number, security code, banking password, or login to investigate an order. Use the provider’s approved support channel for any payment details it requires. Avoid putting sensitive payment data in a shared shift note or ordinary email.
Before buying or changing systems, ask how staff can find an order and match it to a payment attempt, what permissions are available, and which team handles mismatches. The online ordering buying guide can help frame the wider setup questions. Also ask whether support can see both records or whether your team must contact separate companies.
Explain a pending authorization without guessing
A pending bank entry can be an authorization rather than a completed charge. It may affect what the guest sees as available funds, but the restaurant should not say it has been collected, reversed, or refunded solely because the entry says pending. The payment provider and the guest’s bank may each have information about what happens next.
Hypothetical example: A guest attempts a $28 online order and sees an error. Their bank shows one $28 pending entry. The restaurant finds no accepted order, while an authorized manager finds a payment attempt marked pending. There is no confirmed sale to fulfill in the order system, and the pending entry does not establish a completed charge.
Those are two observations, not a final outcome. The manager should save the attempt reference, ask the payment provider what the status means and what follow-up is needed, and check the order system again before advising the guest about a new order. If the guest wants to order immediately, explain the unresolved attempt and agree on a path with a manager; a second attempt could create another payment entry or order.
A useful guest update is: “I can see a payment attempt, but I can’t yet confirm its final status. I haven’t found an accepted order. I’m checking with our payment support and will update you by the time we agreed.” Give only the facts you have verified. Don’t promise a release date or call a pending entry a refund.
If the guest asks about funds shown by their bank, suggest they contact the bank for account-specific information while the restaurant follows up with its payment provider. Record the next update time and the channel the guest prefers. If support has not answered by then, send a short progress update rather than letting the case disappear between shifts.
For staff training, walk through this example using fictional records or a safe simulation. Make sure the simulation cannot create a real payment, send a guest message, or dispatch a courier. A live service pilot is different: use actual cases only under your normal permissions and support procedures.
Route the case with a complete handoff
Start with the provider responsible for the record that needs explanation. An order missing or incorrectly displayed points first to ordering-system support. A payment status or transaction question points to payment-provider support. If the records disagree, contact both as needed and give each team the other system’s reference when permitted.
Some restaurants use one vendor for the ordering interface and another for payment processing. Ask each provider who owns the investigation and whether they need the restaurant to pass information between them. Do not assume one support team can see the other’s records.
Use this checklist before escalating or passing the case to the next shift:
- Guest and contact: Name used for the order, preferred contact method, and agreed update time.
- Order details: Ordering channel, approximate time, amount, order number if any, and the exact order status found. Note whether the kitchen received an order.
- Payment details: Provider, attempt time, amount, transaction reference, and exact status for each attempt. Include the time zone where useful.
- Guest report: Error wording, whether a confirmation arrived, and whether the guest reports a pending or completed bank entry. Identify these as the guest’s observations.
- Actions already taken: Searches performed, any provider case number, and whether the guest has placed another order. Do not include card numbers or security codes.
- Open question and owner: State what needs an answer, which provider has been contacted, who will follow up, and when.
A good handoff ends with a specific question, such as: “Does transaction reference A relate to order reference B, and what is the current payment status?” That is more useful than “Guest says payment failed.” Keep the case open until the responsible team has answered and the guest has received the agreed update.
Run the checklist against your current restaurant website and ordering setup: identify the people with access, the support contacts, and the information each team needs. Then ask Fleksa about its restaurant online ordering, including verified US availability and how payment-status handoffs work for your intended setup.
Frequently asked questions
Does a failed checkout mean the guest was not charged?
Not necessarily. Check the payment provider’s record and its current status. An error on the checkout screen does not by itself establish the final payment outcome.
Should staff tell the guest to order again?
First check for an accepted order and any matching payment attempts. If the status is unresolved, explain that another attempt could create a duplicate and involve a manager in deciding how to proceed.
What if the payment provider and ordering system show different results?
Record both statuses and their references, then contact the relevant support teams. Assign one person to coordinate the case and update the guest while the mismatch is investigated.
