Two different starting points lead here. A caller can ask to cancel while they're still on the phone, before anything has been charged. Or a customer can come back later — after the order was accepted, after a card was charged — and ask for money back. The two paths overlap in places and diverge in others, so this page keeps them separate rather than folding them into one generic “undo” story.
Cancelling a request and routing it to the restaurant is real today, for any order regardless of how it's being paid. The refund lifecycle further down this page — a captured payment moving back through a payment provider — describes the honest design for when a restaurant's card path is enabled, and is not a live capability on every call yet.
01Cancelling before anything has been charged
A request to cancel doesn't cancel anything by itself. It's a request, routed to whoever actually has the authority to decide — which, for an order placed through a restaurant Dohos answers for, is the restaurant itself. The acknowledgment a customer gets makes that distinction on purpose:
We received your request to cancel order [safe reference] for [verified Restaurant] on [time]. This acknowledgment does not mean the order is canceled or that a refund is due. Current verified order state: [state]. We are routing the request to [authorized decision-maker] and will update you through [verified channel].
Notice what that sentence doesn't say. It doesn't say “cancelled.” It doesn't say a refund is coming. It says the request arrived and it's now in front of the person who can actually act on it — which, in practice, means it's a decision the restaurant makes, the same way accepting or declining the original order was. There's no separate cancel button that skips that step, because skipping it is exactly what would let an order get pulled out from under a kitchen that's already started it.
Two things can happen next. If the cancellation lands before the order crossed some meaningful line, it goes through cleanly, and the customer hears the two facts that actually matter kept separate on purpose:
Order [reference] was canceled at [time] before [verified state transition]. Payment status is [precise Provider-backed state]. [Any refund/release statement separately.]
“Canceled” and “the money's back” are two different facts, stated as two different facts — never collapsed into one sentence that implies the second because it said the first. If a card was authorized but never actually charged, cancelling releases that authorization; if money already moved, releasing it is its own separate step, covered further down this page.
The other outcome is honest instead of convenient: sometimes an order genuinely can't be cancelled through this path anymore, usually because the kitchen already started it or because the restaurant's own policy on late cancellations says no. That gets said directly, with a reason attached and somewhere else to take it:
The order cannot be canceled through Dohos because [specific verified state and applicable policy/Restaurant decision]. You may contact [verified Restaurant/support/ appeal path]. This response does not limit any nonwaivable right.
There isn't a dedicated “Cancelled” state anywhere in the interface today, and no button on an order's own detail screen currently performs a cancel or a reject action. What actually shows the outcome is the order's own real acceptance and payment information — if an order never proceeded, that's what its acceptance reads; if money moved and then came back, that's what its payment reads.
02Requesting money back after the order went through
Once an order has actually been accepted and paid for, “cancel” isn't the right word anymore — the restaurant already agreed to make it, and in some cases already has. From here, a request for money back is a refund, and it runs through its own sequence, slower than a single click on purpose, because a refund is real money moving back out of a restaurant's own account, not a flag Dohos flips on its own. It starts the same honest way a cancellation does — an acknowledgment that doesn't promise the outcome yet, and a name for who does:
We received your refund request for [amount/item/order] on [date]. No refund has been approved or completed yet. The seller/merchant for this order is [verified Restaurant] under the target flow, and the request is assigned to [verified authority]. Please do not submit payment information again.
That last line matters as much as the rest: nothing about a refund request ever needs a customer to say their card number again, to Dohos or to anyone else. If someone hears otherwise, that's not how this works. The restaurant — not Dohos — decides whether the refund is approved, because the restaurant is the seller on that order and the one whose payment account the money actually sits in. When it says yes, that's still not the end of the story:
[Authorized decision-maker] approved a refund of [currency/amount] for order [reference] on [date]. The request was submitted to [verified payment Provider/Connected Account context] under reference [safe reference]. It is not complete until the Provider confirms success.
Approved and complete are two different moments, on purpose. Between them, the request has been sent to the payment provider that actually moves the money, and it hasn't confirmed yet. Once it does, the customer hears the last real fact — and only the facts that are actually knowable at that point:
The payment Provider reports a refund of [amount] for order [reference] completed on [date/time]. It was sent to the original payment method [only if verified]. Posting time depends on the financial institution; Dohos cannot guarantee the posting date. Ledger/ reference: [safe support reference].
“Completed” here means the payment provider has confirmed the refund was sent — not that it has landed in the customer's account yet. Exactly when it shows up on a statement is a bank's own timing, not something either the restaurant or Dohos controls or can promise a date for. Telling a caller “it'll be back by Friday” isn't a kindness if nobody can actually know that.
03When only part of it comes back
Not every refund is the whole order. A missing side, a wrong item, one course out of three — the restaurant can approve a partial refund for exactly the part that was actually wrong, and the customer is told what's coming back and, just as importantly, what isn't and why:
A partial refund of [amount] was [approved/submitted/completed — choose one verified state] for [specific items/reason]. The remaining amount is [amount] because [fact-specific basis and authority]. You may request review through [path].
The remainder isn't left unexplained. If four items shipped fine and one didn't, the refund covers the one, and the reason the rest doesn't come back is stated rather than assumed obvious. A customer who disagrees with that math has somewhere to take it — the same review path named right in the sentence, not a separate hunt to find one.
04When the answer is no
Sometimes a refund request is declined outright. That's a real, legitimate outcome — a restaurant's own stated policy, or the facts of what actually happened, can land on no — and when it does, Dohos says so with an actual reason attached, not a form rejection:
The refund request was denied by [verified decision-maker] on [date] because [understandable fact-specific basis] under [identified terms/policy/law context]. Dohos completed [any direct remediation]. You may use [appeal/complaint/dispute path]. This does not waive nonwaivable payment or consumer rights.
A denial is never the entire conversation ending. There's a reason attached, and there's a path to push back on it — through the restaurant, through Dohos's own channels, or through whatever rights the customer has that a refund process can't override just by saying no.
05When the system genuinely doesn't know yet
Two different moments produce an honest “not sure” rather than a guess, and both matter because the wrong move — retrying, or promising something not yet true — makes things worse, not better. The first happens mid-call, if a caller asks about a refund while they're still on the phone with the assistant:
I can help submit or route a refund request, but I can't say the refund is complete until the verified Restaurant/payment Provider result is received. I'll identify the amount, decision-maker, and expected timing before you rely on it.
The second happens after the fact, when a payment result genuinely can't be confirmed one way or the other:
The payment result is pending or cannot be reconciled. Do not pay again and do not submit a duplicate refund request. We are checking the same Provider reference and order ledger. Next update: [verified time/condition].
Both exist for the same reason: retrying a payment or a refund request while the actual status is unverified risks doing the same thing twice, in either direction. The honest answer is to wait for the same reference to resolve rather than start a second one on top of it — the same discipline that governs a call that got dropped and reconnected or an order that looks like it might have gone through twice.
06What the order itself shows you
An order's payment carries one of four real states today, and each has an exact label on the order's own detail screen: Paid, Cash due, Declined, or Refunded. If a refund has actually completed, “Refunded” is what that order shows — not a separate log, the payment status itself.
| What the label reads | What it actually confirms |
|---|---|
| Paid | The charge went through and hasn't been reversed |
| Cash due | Settles outside any Dohos payment flow — pickup or the door |
| Declined | The attempt didn't go through |
| Refunded | The payment provider confirmed the refund completed |
There's no separate “Voided” or “Unknown” label sitting alongside those four today, even though a refund can genuinely pass through an unresolved moment on its way there — that's the “pending or cannot be reconciled” state above, worth checking back on rather than assuming a missing fifth label means something went wrong.
07If something doesn't line up
- A refund was approved, but the order still reads “Paid.” Approved and completed are different moments — see the sequence above. Check whether the payment provider has actually confirmed yet before assuming anything's stuck; “Refunded” only appears once that confirmation has come back.
- A customer says the money never arrived, even though the order reads “Refunded.” “Refunded” means the provider confirmed the refund was sent, not that it has posted to a specific account yet. That timing is the customer's bank, not something either side controls.
- A refund request seems to have gone in twice. That's exactly the situation the “pending or cannot be reconciled” language above exists for — check the same order reference before treating it as two separate requests.
- A caller wants to cancel an order that's already well into preparation. That's the honest “cannot be canceled” branch, not a bug — the reason belongs in the explanation, and a refund conversation, if one's warranted, is a separate step from a cancellation that simply isn't available anymore.
If an order's real state doesn't match what a customer is describing, or a refund has sat in the same state longer than the sequence above suggests it should, write to support — a real person reads it. Name the location, what you were doing, and any order or call reference you have.