Payment link problems

It's worth being precise about when this actually applies: a phone order completes as a cash-due order by default, settled directly with the customer, unless a restaurant's own payment setup routes it through the secure card path this page describes. Where that path is in use, the five real situations below cover everything that can actually go wrong with it, each with the exact wording written for the moment and the real steps to take.

01The mechanism, briefly

The short version, covered in full on Payments and why card data never enters Dohos systems: Dohos doesn't take card or bank numbers by voice, ever. The moment a payment step begins, the caller is handed a secure link, hosted by an approved payment provider, isolated entirely from the call itself. Nothing typed or spoken into that link ever reaches Dohos's own systems. This page doesn't re-explain that mechanism in full — it picks up specifically where the link, or the payment result behind it, doesn't behave the way it's supposed to.

Every one of the five situations below shares one property worth understanding up front: none of them is ever resolved by falling back to an easier, less secure way of collecting payment. That constraint is what makes the five branches worth learning specifically — each has its own real cause and its own real next step, and none of them is fixed by working around the link itself.

02When the link itself won't work

Two distinct problems can happen before a payment result even enters the picture: no link could be created at all, or an existing link has stopped matching what it's supposed to represent.

The critical thing this line protects against is exactly the failure mode a caller might expect — that a broken payment step gets “fixed” by asking for the numbers directly instead. It never does that. If a secure link genuinely can't be generated, the caller is told plainly that nothing was charged, and pointed toward whatever payment option the restaurant actually has available instead of the secure link.

A link going stale like this usually just means time passed, or something about the order changed after the link was first created — a material change to the order, covered on Order status explained, invalidates whatever was sent before it. The old link simply stops being usable rather than silently accepting a payment against outdated information, and the caller is walked back to review the order fresh.

03When the payment result itself is unclear

Once a link has actually been used, three different outcomes are possible, and each gets its own exact, honest wording rather than one vague “there was a problem with your payment.” The first is the one most likely to cause confusion if it isn't understood clearly: payment can succeed while the order itself is still an open question.

That's the payment and acceptance axes doing exactly what they're built to do — staying independent facts rather than one collapsed into the other. A successful charge is real and stated as such, but it never gets described as the order being confirmed, because those are two different things tracked separately, covered in full on Order status explained.

The second outcome is the one where patience matters most, because the instinct to just try again is exactly the wrong move:

A pending or unverifiable result isn't the same as a failure, and treating it like one by immediately trying a second payment risks the exact duplicate-charge concern covered on Duplicate orders and charges. The same reference gets checked again instead — never a fresh attempt layered on top of an uncertain one.

The third outcome is the most straightforward, precisely because it's the least ambiguous:

Nothing about a failed payment attempt triggers a fallback to asking for numbers directly — the path forward is always a fresh, secure link, generated only after the order and amount are reconfirmed, never a shortcut around the same protection the very first payment attempt went through.

04A pending result, start to finish

The second of the three provider outcomes above is worth walking through in full, since “pending” is the one most likely to tempt a quick fix that actually makes things worse. A caller uses the secure link, enters their card details on the provider's own page, and the call comes back to a result that isn't a clean success or a clean failure. Dohos doesn't tell the caller their card was declined, and it doesn't tell them the payment went through either, because neither of those would be true. It says exactly what's real: the result is still pending or can't be verified, and the caller shouldn't pay again.

What actually resolves this is checking the same payment reference again — not immediately, but after enough time for the provider to actually settle on an answer, and not by generating a second link and hoping the first one sorts itself out in the background. If the same reference clears to a confirmed success shortly after, the order proceeds exactly as it would have if the first check had already shown success. If it clears to a genuine failure instead, that's the moment a fresh secure link is actually appropriate, generated against the same, still-accurate order. What never happens anywhere in this sequence is a second payment attempt stacked on top of the first one before the first one's outcome is actually known.

From an operator's side, a caller describing this exact situation is usually more reassured by hearing that this is a known, expected outcome with a real resolution path than by a vague “let me check on that.” Naming it plainly, the way this page does, is often the fastest way to keep the caller from trying to solve it themselves by paying a second time through some other channel.

05What to actually do, branch by branch

1. No link could be created. Offer whatever payment option the restaurant actually has outside the secure link — paying at pickup or delivery, most commonly — or suggest trying the call again shortly, since this is often a momentary condition rather than a lasting one.
2. The link stopped matching. Don't try to force the same link to work. Walk the order back to review, confirm it's still accurate, and let a fresh link get generated against the current, correct order and amount.
3. Payment succeeded, acceptance is still pending. Check the order's acceptance status separately — don't assume a successful charge means the order is confirmed. If it's sitting in review, that's its own situation, covered on When a call needs a person.
4. The result is pending or unverifiable. Wait and check the same payment reference again rather than attempting a new payment. If it's still unclear after a reasonable check, that's worth escalating directly rather than guessing at the outcome either way.
5. Payment wasn't confirmed. Confirm the order and amount are still correct, then generate a new secure link. Nothing about a failed attempt is fixed by trying to collect payment information any other way.

Across all five, one thing never changes: nothing about a payment problem is ever resolved by taking card or bank details outside the secure link, no matter how stuck or urgent the situation feels in the moment. That boundary holds regardless of which of the five is actually happening, and it's worth restating to a frustrated caller directly — hearing plainly that the protection is intentional, not a glitch getting in the way, tends to land better than silence on the point.