Duplicate orders and charges

This page walks through why a genuine duplicate is rare by design, what a caller is actually told in the moment it's uncertain, and exactly how to check the real records rather than guess either way.

01Why this can look like it happened, even when it hasn't

Every order submission carries its own unique reference, checked before anything is actually created. If the exact same submission arrives a second time — because a call dropped right as an order went in and the caller's device or the connection retried it, or because a caller asked to try again after being told the first attempt couldn't be confirmed — the system recognizes it as the same request rather than building a second order from it. The same protection covers payment specifically: once a card payment is actually captured for an order, that same order can't be funded a second time through a repeated attempt. This isn't a manual check someone has to remember to run. It's built into how an order actually gets created in the first place, checked before anything is written down, not after.

What that means practically: the moments that feel like they should have caused a duplicate — a dropped call, a retried action, a caller asking “did that work?” and trying again to be safe — almost never actually do, because the system is specifically built to treat a retry of the same request as the same request, not a new one. What can genuinely happen instead is two separate, legitimately different orders placed close together, which looks similar from a caller's memory but is a different situation with a different explanation, covered further down this page.

02A dropped call, start to finish

The clearest way to see why this almost never actually duplicates is to follow one real situation through. A caller is most of the way through confirming a pickup order when the line drops. They call back, the call reconnects, and — depending on exactly how much survived the drop — either picks up cleanly from where it left off or restarts the review, covered in full on Reconnecting after a dropped call. Either way, the caller ends up confirming the order again, in full, before it actually submits.

From the caller's side, that can feel like two attempts at the same order — they said yes once, the line dropped, and now they're saying yes again. From the system's side, nothing was actually submitted the first time; the drop happened before or during the confirmation itself, not after a completed submission. The second, successful confirmation is the only one that ever creates an actual order. If, instead, the drop happened after a first submission genuinely went through, and the caller's reconnect leads to a second attempt at the same request, that second attempt carries the same underlying reference as the first — the system recognizes it as a repeat rather than a new order. Either way, one order results, not two, and it's the actual order record — not the caller's memory of how many times they said yes — that settles the question.

The same logic covers payment specifically, which is often the more urgent half of the worry. A caller who confirmed a card payment, then experienced a drop, then reconnected and was asked to confirm again, isn't at risk of being charged twice for it — a completed charge against a specific order can't be captured a second time against that same order, regardless of how many times the confirmation step itself gets repeated around it. A caller anxious about their card is usually better served by checking the actual charge on the order record than by being told, in the abstract, not to worry.

03What a caller was actually told

When Dohos itself can't confirm whether an action already completed — the exact moment where a caller might otherwise be tempted to just try again — it says so plainly rather than letting the caller guess. The exact wording is quoted in full on Reliability, which owns this fact end to end: Dohos holds off rather than guessing, tells the caller directly not to repeat the attempt yet, and checks the same reference itself before treating anything as new.

That's the same discipline behind the idempotent design above, stated directly to the caller in the moment it matters most. Dohos doesn't ask the caller to just try again and hope for the best — it holds off, checks against the same reference rather than starting a new one, and routes to a person if it can't resolve the uncertainty itself. A caller who heard this line and is now asking whether their order went through twice is, if anything, in the safest possible position: the system already flagged the exact same uncertainty they're asking about, rather than silently guessing in either direction.

04Checking it directly

Rather than resolving a duplicate question from memory or from what a caller believes happened, the order records themselves settle it directly.

1. Find the order reference from the call or from whatever the caller remembers — a partial reference is often enough to search with. Order status explained covers how to read the three axes on whatever order actually shows up.
2. Look for a second order close in time, from the same phone number, with a similar or identical item list. If nothing like that exists, the duplicate concern is very likely already resolved — there's simply one order, exactly as the idempotent design above would predict.
3. If a second, similar order genuinely does exist, open both and check their own event histories — the actual sequence of what happened and when for each one, not a summary. Two orders created seconds apart from the same request, both carrying the same underlying reference, point to a display or a caller-memory question rather than two real, separate orders; two orders created minutes apart with their own distinct references and their own distinct confirmations are genuinely two different orders, whatever the reason turns out to be.
4. Check payment specifically, separately from the order count. Because a single order can't be funded twice, confirming there's only one actual charge — even where two order-shaped records somehow exist — is the detail that actually matters most to a caller worried about their card.

05If it genuinely does look duplicated

Occasionally the check above turns up two real, independently created orders rather than one order appearing twice. Before treating that as a system fault, it's worth ruling out the more common explanation first: two separate calls, close together, where a caller genuinely placed two orders on purpose — a second call to add something forgotten the first time, for instance, submitted as its own new order rather than a change to the first one. That's not a duplicate in the sense a caller usually means when they ask about it; it's two real orders that happen to look similar.

A household ordering separately is another entirely ordinary version of the same pattern — two different people, sharing a landline or calling from the same building, each placing their own real order within a few minutes of each other. Two similar-looking orders from the same phone number isn't itself evidence of anything wrong; it's worth actually reading both order's item lists side by side before assuming either one is a mistake.

If both orders trace back to what looks like the exact same original request — same items, same reference lineage, created within moments of each other — that's worth treating as a genuine issue rather than working around it silently. Note exactly what the two order references are and roughly when each was created before escalating. Refund or cancellation for whichever order turns out to be the genuine duplicate follows the same real process as any other cancellation, covered on Refunds and cancellations — nothing about a duplicate changes how that part works.

It's worth saying plainly that a caller raising this concern isn't being difficult or overly cautious — a dropped call genuinely is disorienting, and asking “did that go through twice” is a reasonable question to want answered with something more solid than reassurance. Treating it that way, and actually pulling up the records rather than guessing, is usually faster than it sounds: most of the time, the answer is a single order, a single charge, and a caller who can be told exactly that with the reference number in front of you.