Duplicate restaurant orders occur when a delivery event or API request is processed again after a timeout or missed acknowledgment, and the receiving system creates a new POS transaction instead of recognizing the original. Start by matching the external order ID to every POS and kitchen record. Then test deduplication, safe retries and recovery before changing production logic.
Why webhook retries can create duplicate POS orders
Webhook delivery and business-order creation are different operations. A webhook may be delivered twice without the customer ordering twice. Conversely, two orders placed intentionally by a customer must remain two transactions even when items and totals match.
The practical goal for a restaurant order management system is not to block repeat messages; it is to ensure a repeated technical message does not cause a second unintended preparation task. This article focuses on the incident test matrix, rather than a general introduction to restaurant API integration.
Symptoms to distinguish
- One marketplace order ID maps to two or more POS transaction IDs.
- A kitchen receives duplicate tickets shortly after an upstream timeout or retry.
- A status update such as accepted or cancelled unexpectedly creates another sale or preparation record.
- An operator presses a manual resend button after the original request reached the POS but its response was lost.
- Two different channel orders appear similar but must not be merged because they have separate source order IDs.
Do not infer the implementation language, queue, or processing guarantees of a particular restaurant vendor without documentation. These failure patterns apply generally to distributed integrations.
How to diagnose the source of duplicates
Preserve the original evidence before deleting a record or retrying. Investigate at the business-order level as well as the message level. An identical payload is insufficient evidence: discounts, edited modifiers or later status events may make two messages different while still describing one customer order.
- Channel evidence: channel order ID, brand, branch ID, event type, creation time and attempt identifier if present.
- Connector evidence: receipt timestamp, correlation ID, retry count, error response, and whether the original message was acknowledged.
- POS evidence: every matching transaction ID, creation time, source reference, and state.
- Kitchen evidence: print or KDS task identifier and whether more than one ticket was acted upon.
- Operator action: manual resend, change of branch, reconciliation or cancellation taken between attempts.
Build a short timeline in one time zone. If the POS created an order at 19:04 but the connector timed out at 19:05, a later retry at 19:06 must first check that original receiving-side outcome. A network timeout is an unknown result, not proof of a failed transaction.
Microsoft’s resilient event processing guidance explains why consumers should tolerate repeated deliveries. It is an architectural reference, not evidence that LYNNC uses Microsoft infrastructure.
Step-by-step solution: idempotency keys, retry windows and logs
- Choose the business-operation identity. For create-order actions, a candidate key is source platform + restaurant account + external order ID. Include a branch dimension only if the business rules require it and do not allow a branch change to create a second order accidentally.
- Separate event identity from order identity. Multiple status events can describe the same order. Use the event ID to deduplicate an event where supported, and the business order ID to avoid duplicate order creation.
- Establish one authoritative receiving record. Store or retrieve the POS transaction ID corresponding to the external order and reuse it when the same operation is repeated.
- Make claim-and-create safe under concurrency. The technical design should prevent two parallel workers from both treating the key as unused. A non-atomic “check then create” alone is insufficient.
- Classify retryable outcomes. Temporary timeouts may justify a bounded retry with backoff; invalid item mappings or denied credentials require correction rather than endless replay.
- Observe the provider’s retry horizon. Specify how long the order reference remains recognized, accounting for delayed events and support-assisted replay.
- Reconcile after ambiguous outcomes. Query the receiving POS or its supported lookup interface before a retry that could create another kitchen task.
- Preserve incident logs. Record original attempt, each replay, deduplication decision and final POS outcome without exposing unnecessary customer data.
Idempotency is a system design requirement to validate with technical providers. Do not assume a middleware dashboard exposes configurable idempotency keys or duplicate suppression unless the connector documentation confirms it.
Duplicate-order UAT matrix for delivery integrations
Test these scenarios in an approved sandbox or controlled restaurant pilot. A check passes only when the final business and kitchen outcomes are correct, not simply because an API returned success.
| Scenario | Expected result | Required evidence |
|---|---|---|
| Identical create event delivered twice | One POS order and one kitchen production record | One source ID linked to one POS ID |
| First POS call succeeds; response times out | Retry finds existing order, not a new one | POS lookup plus retry log |
| Two workers process same event simultaneously | No unintended duplicate creation | Concurrent test execution results |
| Later status event arrives before an earlier one | Existing order moves to allowed state without new creation | Event history and state rule |
| Same cart purchased in two intentional orders | Two distinct POS orders retained | Two different external order IDs |
| Order changes branch after creation | No duplicate branch production; owner resolves move | Original order reference and branch audit |
| Invalid modifier causes permanent rejection | Visible exception; no blind repeated production | Validation error plus recovery owner |
| Manual resend after connection restores | Existing order recognized; fallback record reconciled | Operator audit and receiving receipt |
Hypothetical Riyadh incident and safe recovery
Hypothetical example: a Riyadh restaurant receives a marketplace order at 20:14. Its integration sends the create-order operation; Food preparation starts. The connector sees a timeout because the acknowledgment was interrupted, not because the POS failed to write. A worker retries, and a second kitchen ticket prints.
The shift lead identifies the duplicate by the external order reference rather than matching by food description alone. The team retains the original POS order, follows its established procedure to stop the unintended second kitchen task and records whether any refund or reconciliation is required. IT then tests the receiving-side duplicate-protection logic and verifies the behavior under concurrent retries.
The incident is not resolved merely by suppressing all repeats. The corrected system must still allow a genuinely new order with a new external ID. This is an illustrative scenario, not an actual incident, measured success story or documented LYNNC capability.
What to verify in a supplier demonstration
Ask the vendor to demonstrate the same source order being delivered twice and deliberately make the POS reply ambiguous. A clean “happy path” video cannot establish safe recovery under failure.
| Vendor question | Proof to request | Failure indicator |
|---|---|---|
| What identifies an order? | Source business ID and POS ID linkage | Only comparing item names or totals |
| Where is deduplication enforced? | Architecture description and repeat test | No documented receiving-side guarantee |
| How are retries bounded? | Retry policy and permanent-error path | Endless replays without exception queue |
| What if the POS writes then times out? | Receiving lookup and reconciliation trace | Blind second create request |
| Can a staff member retry safely? | Permissioned recovery screen and audit history | Manual resend always creates a new transaction |
| Can operations stop duplicate preparation? | Named escalation and POS/KDS procedure | No responsibility for second ticket |
AWS documents that event-based architectures may deliver events at least once and therefore need appropriate consumer behavior; see the EventBridge event delivery reference. Ask what guarantee applies to the actual connector rather than assuming an infrastructure provider by association.
KPIs, monitoring and release acceptance
Unintended duplicate-order rate = the count of unique external orders that generated more than one unintended POS creation divided by eligible external orders. Separately track duplicate kitchen tickets and manual recovery cases. A repeated webhook itself is not automatically a business failure if it is handled safely.
- Set up a report that shows one-to-many source-to-POS mappings, grouped by branch, channel and incident type.
- Confirm the system can identify an order whose outcome is unknown after timeout, not only successful and failed orders.
- Review out-of-order status handling, clock differences and reconciliation after a manual fallback.
- Run controlled regression tests after connector upgrades, menu changes and POS version updates.
- Keep a rollback strategy if the corrected connector causes missing orders or unacceptable preparation delays.
The POS delivery integration UAT guide covers broader acceptance testing. This matrix should be attached as a duplicate-specific regression test after incidents and upgrades.
Frequently Asked Questions
Why do webhook retries create duplicate kitchen tickets?
An earlier order creation may have succeeded even when the sender did not receive its acknowledgment. A repeated create operation can produce another POS record if the receiving workflow fails to recognize the same business order.
How should an operator check idempotency IDs and retry logs?
Match the marketplace order identifier with event IDs, retry attempts and every POS transaction produced. Then confirm the receiving-side rule treats a repeated creation as the original order rather than a new sale.
What should a Saudi restaurant test in a demo?
Require a repeated-event test, a successful POS write followed by a simulated timeout, and a simultaneous retry. Confirm one kitchen task remains and that two legitimately different customer orders are not collapsed.
Which KPI proves the duplicate issue is controlled?
Track unintended duplicate POS and kitchen records per eligible external order, not simply total event retries. Also review missed orders to ensure strict deduplication has not started blocking valid transactions.
Decision: Choose a connector only after proving safe order identity, failure recovery and operator ownership. Request a workflow fit demo to discuss supported POS handoffs and duplicate-order acceptance scenarios.
