Payments
Money changing hands on an order — or failing to — kept separate from whether the order itself is correct, which is its own topic entirely. The three situations here sit at three different points relative to the moment money actually moves.
It's worth being specific about who's actually in motion in each case, since that changes what a restaurant can realistically do about it. A stuck payment link is something happening between a customer and a secure page — a restaurant can help route around the problem, but can't force a link to load. A refund is something a restaurant itself decides and requests. A dispute is something a customer's own bank initiates, entirely outside the normal order flow, and neither the restaurant nor Dohos is the one deciding whether it happens.
Urgency runs in a different direction across the three than it might seem to at first. A stuck payment link tends to feel most urgent because it's blocking something in progress right now. A refund rarely has that same immediacy — the order it concerns already happened, and the request moves through its stages on its own timeline. A dispute is the slowest of all three by its very nature, since it's being reviewed by a bank on a schedule the restaurant doesn't control, even though the moment a restaurant first learns about one can feel exactly as urgent as the other two. Matching the right expectation to the right situation is half of what each article below is actually for.
A phone order today is cash-due by default, settled directly with the customer at pickup or delivery. The in-call secure card path two of the three articles below describe is the honest design for when a restaurant's own card path is enabled — not yet a live option on every call. Each article says so again at the point it matters.
Payment link problems covers the earliest of the three moments — a secure link that was supposed to let a customer pay and, for one of a few specific reasons, isn't doing that. Refunds and cancellations picks up after money has already moved, and it's the longest of the three lifecycles by a wide margin — a request has to be made, then approved, then actually carried out by a payment provider. Customer disputes a charge is the odd one out, because it doesn't start with anyone asking Dohos or the restaurant anything at all — it starts with a customer going straight to their own bank instead, and the restaurant finding out about it after the fact, through a notice rather than a request.
One fact shapes what all three articles can honestly promise: the restaurant, not Dohos, is the seller on every order, and every payment question above is answered within that boundary rather than around it. A stuck payment link is something Dohos can diagnose and help route around, but whether an order proceeds without a completed payment is the restaurant's own call. A refund moves through an approval stage precisely because approving one belongs to the restaurant — Dohos can submit the request and report honestly on what's known about its progress, but it can't approve a refund on the restaurant's behalf, and it can't manufacture certainty about a posting date no payment provider has actually confirmed. A dispute is the starkest version of the same boundary: when a customer's bank gets involved, it's reviewing the restaurant's own transaction, and the notice that arrives asks the restaurant specifically for the facts needed to respond, not Dohos.
None of that means Dohos sits on the sidelines — every article describes real, concrete actions Dohos actually takes: routing a stuck request toward a working path, carrying a refund request to the person who can approve it, surfacing exactly what a payment provider has and hasn't confirmed. What none of the three can do is skip past the restaurant's own role, or speak with more certainty than the restaurant's own payment provider has actually given. The honest version of each situation is rarely a flat yes or no delivered instantly — it's a specific stage, a specific next step, and a specific reason nothing more certain can be said yet. None of the three articles here names a specific bank, card network, or payment provider — what matters to a restaurant reading any of them is what stage a payment is actually at, not which company sits behind the scenes.
None of the three articles above says anything about whether an order's own contents are correct — a wrong item, a missing modifier, an ingredient question — which is a separate topic entirely, covered under Orders & menu instead. A payment can be flawless on an order that's otherwise wrong, and an order can be perfectly correct while its payment gets stuck. The call that a payment problem happened during belongs under Calls, separate from the payment question itself.
It's also not the place for a question about the restaurant's own billing relationship with Dohos — its invoices, its own subscription, or a charge on the account itself rather than on a customer's order. That's a genuinely different kind of payment, handled through billing support instead of anything in this topic. A customer's order payment and a restaurant's own account invoice can both reasonably be called “a payment issue,” but conflating them sends a request to the wrong place entirely.
Every dollar figure a caller or a customer hears through any of these three situations comes from the order or the refund itself, never a separate estimate — if a number ever looks different from what actually shows up later, that's worth checking rather than dismissed as rounding. If one of the three articles still doesn't settle it, write to support — a real person reads it. Name the location, what you were doing, and any order or call reference you have.