On this page

Use references that survive retries

Ask each provider how it identifies a repeated submission. The practical requirement is one accepted order for one intended purchase, even if the request travels twice. A stable idempotency key, source order ID or documented deduplication method can support that behavior. A freshly generated reference on every retry cannot identify the retry as the same purchase.

Define the retention window and scope. A key that is unique within one location may collide if another location uses the same sequence. A deduplication window that expires before staff investigate may allow a late retry to create a second order. These are questions for the implementation owner, not details to infer from a product brochure.

Separate three failure states

  • Rejected: the destination explicitly refused the request. Capture the reason and correct it before resubmission.
  • Accepted but not produced: an order ID exists but no usable kitchen acknowledgement has been verified. Recover production routing without creating another sale.
  • Unknown: the client timed out or lost connection without a final response. Search before retrying.

A guest saying “I did not get a text” is useful information but not a definitive order state. Confirmations can fail separately from order submission. Search using the source reference and permitted guest details, then explain the verified state to the guest.

Run a recovery drill

Use a provider-approved test flow to interrupt the acknowledgement after submission. Let the staff member follow the normal exception process rather than telling them the answer. Check whether they can identify the order, prevent duplicate production, reconcile payment and communicate a corrected pickup time.

Also test duplicated incoming events and out-of-order status updates. An old “accepted” event should not overwrite a later cancellation. Record timestamps and state transitions so an investigator can reconstruct what happened without relying on memory.

Close the loop

A recovered order is not complete until the kitchen, guest and payment record agree. If food was produced twice, decide how that loss is recorded. If a replacement order was needed, link it to the original incident. Do not erase the evidence by deleting the failed reference.

Give every unresolved exception an owner and a next review time. The launch-readiness guide explains how to rehearse that ownership before a pilot. The validator flags channels without a documented retry rule.

An unknown order is not permission to resubmit

Illustrative incident: source request P-014 times out after submission. Staff find accepted order K-207 using the supported lookup. The next action is to verify its kitchen and payment states, not create P-015. If the lookup cannot establish the outcome, keep the case unresolved and follow the provider’s escalation process.

Use Loman’s Olo order-routing description to locate the documented system boundary, then request the actual lookup and retry rules for your installation. This example describes a review method, not a tested provider implementation.