A checkout error should tell the guest which field needs attention, what is wrong, and what to do next. For example, “Enter a five-digit ZIP code” is more useful than “Invalid input.” Put that message beside the ZIP code field and keep the guest’s other entries intact.
The right wording depends on the rule behind the field. Before changing a message, ask who sets that rule: your restaurant, the ordering provider, a payment provider, or another service. A clear sentence cannot fix a rule that blocks a valid order.
Identify the failure before writing the message
Start with the fields a guest sees when placing an order: contact details, pickup or delivery information, payment details, and any required selections. For each one, list what the guest must provide and the different reasons an entry could fail.
A missing phone number is different from a number in a format the system cannot accept. A missing delivery address is different from an address outside the restaurant’s delivery area. If both cases receive “Invalid information,” the guest has to guess what to change.
Ask your provider to explain which rules you can configure and which are set elsewhere. Your restaurant may decide its delivery area and ordering hours, while a payment provider may control how card details are checked. Also ask whether you can edit the message itself or must request a change.
Use the following hypothetical examples as a starting point. The better message assumes the stated rule is actually in effect; confirm the rule before using the wording.
| Failure and assumed rule | Before | More useful message |
|---|---|---|
| Phone number is required | Invalid input | Enter a phone number so we can contact you about your order. |
| ZIP code must have five digits | Check your address | Enter a five-digit ZIP code. |
| Address is outside the configured delivery area | Address error | We can’t deliver to this address. Choose pickup or enter another delivery address. |
| A required item choice is missing | Selection required | Choose a side for your sandwich. |
| Requested pickup time is no longer available | Time error | That pickup time is no longer available. Choose another time. |
The table separates a guest’s action from the system’s reason for stopping. It also shows why a single generic message is a poor fit for several different problems. For an unavailable pickup time, changing the phone number will not help; the message should point to the time selector.
Keep the wording specific without exposing sensitive information. For payment problems, ask the payment provider what messages it permits and what the guest can safely do next. Avoid displaying a full card number or claiming to know why a bank declined a payment when the system has not supplied that reason.
Put the message where the guest can act
Place a field error next to the affected input, preferably after its label and close enough that the connection is obvious on a small screen. Keep the field label visible when the guest starts typing. If the label disappears and the only remaining text says “This is required,” the guest may no longer know what “this” means.
When several fields need attention, a short summary near the top can help a guest understand why checkout did not continue. Pair it with messages at the individual fields rather than making the guest hunt for them. If the system supports it, each summary item can lead to the relevant field.
Timing matters too. Showing an error while someone is still typing a valid email address can feel like an interruption. On the other hand, waiting until the final submit button to report a missing apartment number can force a guest to scroll back through the form. Ask the provider when validation runs and whether the timing can be changed.
Write messages in plain language, without blaming the guest. “Enter a pickup time” gives an action; “You forgot to select a time” adds nothing. Do not rely on a red border alone. A written message helps guests understand the problem even when they do not notice or cannot distinguish the color.
Be careful with errors that belong to a larger choice rather than one text box. A delivery-area message should appear with the address or fulfillment choice, and it should offer only options the restaurant actually provides. If pickup is unavailable, do not tell the guest to choose it.
Keep valid entries when a guest corrects an error
A guest should not have to rebuild an order because one field needs attention. Ask what the checkout retains after a validation error: cart items and modifiers, fulfillment choice, contact details, address, requested time, tip, and any other entries the guest has already made.
Consider a hypothetical delivery order with two menu items and a valid street address. The guest enters a ZIP code with four digits, and the restaurant’s checkout requires five. The error should identify the ZIP code field and request five digits. After the guest corrects it, the two items and valid street address should still be present, so the guest can review the order and continue.
That expectation has limits. A corrected address might change delivery availability or the fee, and an earlier pickup time might no longer be offered. The checkout should show the guest what changed and let them review it before placing the order. Do not promise that every selection can always be retained.
Payment details deserve a separate question. Ask which payment entries remain after an error and which must be entered again. If a retry is needed, the message should say what the guest can do without suggesting that a payment succeeded or failed unless the system knows the outcome. Where the outcome is uncertain, provide a clear path to check the order status or contact the restaurant before attempting another payment.
For a restaurant website, check the whole path from menu to checkout, not just an isolated form. A message can be well written yet still cause frustration if correcting it sends the guest back to an empty cart. The online ordering buying guide can help frame this question alongside the rest of the purchase decision.
Check mobile and assistive technology behavior
Run a simulated checkout with a test cart and deliberate mistakes. Do not submit a real payment, send a guest message, or dispatch a courier during practice. Ask the provider for a safe test environment or a demonstration that stops before those actions. If the system cannot simulate a particular step, ask the provider to demonstrate its behavior rather than triggering a real order.
On a phone, enter an incomplete field and try to continue. Check whether the message is visible without unnecessary scrolling, whether the affected field is easy to find, and whether the keyboard covers the instruction. Correct the entry and confirm that the error clears or updates. Then check that other valid entries remain.
Use a keyboard to move through the same form. Can you reach the affected field, read its message, correct it, and continue without a mouse? If an error summary appears, check whether its links or controls can be reached and used by keyboard.
With a screen reader, check that each input has a clear label and that its error is announced or otherwise available when the guest reaches the field. Ask how newly displayed errors are communicated and whether focus moves to a useful place after an unsuccessful submit. A visible message alone does not tell you how it behaves with assistive technology.
These simulated checks reveal design problems but do not reproduce every device, network condition, or guest interaction. If you later run a live service pilot, treat it separately: agree on the scope and staff response, and use real ordering and payment steps only when you intend to handle a real order.
Use the examples and checks above to review your current checkout, then ask Fleksa about its online ordering system, including verified US availability and which error messages and validation settings can be configured.
Frequently asked questions
What should every checkout field error include?
Identify the affected field, explain the problem in ordinary language, and give the guest a specific action. The action must match the actual rule or failure.
Should an error appear before or after checkout is submitted?
That depends on the field. Avoid interrupting a guest who is still typing, but show useful feedback early enough that they do not have to search the whole form after submitting.
What if the restaurant cannot edit the error message?
Ask the provider who controls the wording, how to request a change, and whether the underlying validation rule can be configured. Include a specific example of the problem and the action a guest should take.
