Payments
Today, every order a caller actually pays for on the phone is paid in cash. Card payment is real, tested architecture — an isolated step built to keep a card number away from Dohos entirely — but the live conversation doesn’t ask for it. This page states that plainly, in the order it actually matters: what happens on a real call today, first, then what the system is built to do next.
Pay at pickup runs completely,
on real calls, today.
None of that touches a Dohos payment system at any point in the sequence — there’s nothing electronic in a cash order for a payment system to touch. Dohos isn’t a party to that money moving at all; it only tracks that the order reached a completed, paid state, the same as it would for any other order.
This isn’t half of a payment story, waiting on the other half to matter. It’s the whole live path a caller experiences on the phone today — proven on real calls, not a fallback running while something else gets finished.
The card moment splits off
behind a hairline, by design.
The reason a caller never reads a card number to Dohos isn’t a policy — it’s that the system is built to never let that moment happen inside the ordinary conversation at all. The instant a card would be used, the architecture splits that step off entirely, onto a separate, isolated channel a caller would use to pay directly.
What Dohos tracks instead of a card number
| NEVER ENTERS A DOHOS SYSTEM | WHAT DOHOS KEEPS INSTEAD |
|---|---|
| Card number | Whether the order is paid, cash due, or unpaid |
| Expiry date and security code | A reference to the transaction at the payment provider |
| Payment touch-tones (DTMF) | The amount and time of the payment attempt |
That structural boundary holds regardless of which payment path an order actually takes. A cash order never generates any of the left column in the first place, because there’s no card involved at all; the right column is simply what a completed cash order’s own record already looks like — paid, an amount, a time — without a provider reference attached, because none was needed.
Real, tested architecture —
not a step a live call reaches.DRAFT — PENDING THE PAYMENTS GATE
To protect your payment information, I can’t take card or bank details by voice. I’ll send or show a secure payment link hosted by [verified payment provider display name] for [verified restaurant seller name]. The total is [currency and verified total]. Please review the seller, items, fees, and total on that page before paying.
Once that secure step is reached, the line is explicit that sending a link isn’t the same as being paid, and that being paid isn’t the same as the restaurant accepting the order:
The secure payment link for [verified restaurant] and [verified total] was sent. Dohos will not ask you to read card details aloud. Payment is not complete until the payment provider confirms it, and the order is not accepted until the restaurant confirms acceptance.
The architecture is also built for the moment a caller starts reading a card number aloud out of habit, on a channel that was never asking for one — designed to interrupt before anything is captured, not to let the caller finish and clean up afterward:
Please stop — don’t say your card or bank numbers aloud. I can’t receive them by voice. I have not intentionally saved those numbers. Use the secure payment link, or I can give you the restaurant’s verified alternative.
Cash is the payment method every live call reaches today, so this specific interruption hasn’t had a live moment to run in. Keeping payment and acceptance as two separate facts, never one collapsed into the other, is the same discipline the rest of the product holds to everywhere else it matters.
“Unknown” is a real state here,
not a gap papered over as paid.
An order’s payment status is never collapsed into a single “done” flag. It’s one of a small, defined set of honest states — and when a provider’s own status can’t be verified, the honest state is unknown, not a hopeful guess.
DISCRETE STOPS, NOT A PROGRESS BAR — AN ORDER DOESN’T MOVE THROUGH EVERY ONE IN SEQUENCE
Every cash order that reaches completion today sits at paid, by a staff member’s own mark. The remaining states exist for the day a card order can move through them — they’re not decoration for a path nobody uses; they’re the actual honest vocabulary the architecture is already built on.
Two different sentences
about two different things.
Neither one is a hedge on the other. Nothing about the card lane is dimmed to imply something’s wrong with it — it’s the same architecture, built to the same standard. It simply hasn’t been the path a live conversation takes.
The cash lane
Accepted → cash due → staff marks collected → completed. Every stop real, and happening today.
- Settles at the restaurant, the same way a walk-in cash sale already does.
- Nothing electronic for a payment system to touch, at any point.
- A reader checking this against a real call should find it exactly as described, every time.
The card lane
The same isolated-step, six-state architecture — drawn, tested, and not what a live call asks for. DRAFT — PENDING THE PAYMENTS GATE
- Built to settle into the restaurant’s own connected account, never a Dohos-controlled balance.
- A payment outcome and a provider reference — never the number the reference points to.
- Not dimmed, not a warning — real, tested, and honestly not reached.
On either path, Dohos isn’t positioned to hold or delay a restaurant’s own money — the design keeps the restaurant as the seller of record for every sale it makes. On the ticket that reaches the kitchen and pickup staff, what shows is simply what’s owed and how — paid, or cash due, and how much — without anyone needing to know which path a payment took to get there.
The same order, traced twice.
A caller orders $34 worth of food for pickup. Today, that call ends the same way every call like it does: the order is accepted, marked cash due, and the caller pays at the counter when they arrive. Staff mark it collected, the order moves to completed, and nothing about that $34 ever touches a Dohos payment system.
Here’s how the system is built to handle the same $34 once a live call reaches that path. At the moment of payment, the conversation would split off into the isolated step above rather than asking the caller to speak a card number — a secure link, hosted separately, showing the same $34 and the same restaurant. A successful result comes back as a payment outcome, not a card number — the exact wording for that moment is quoted in full on payment link problems. The order would still need the restaurant’s own acceptance, separately from the payment succeeding, exactly the way it already does for a cash order.
Objections, answered
So card doesn't work at all?
The mechanism is built and tested at the architecture level — the isolated step, the provider reference, all of it real. A live call simply doesn’t ask for it. That’s the precise answer, not a softer or a harder one.
What happens if a caller only has a card?
Today, cash is the only payment method a live call actually completes — that’s a real gap, not something this page papers over with a workaround. It’s stated plainly rather than invented around.
Is my card number safe?
Yes, structurally. The database this runs on has no field anywhere that could hold a card number, an expiry date, or a security code — there’s nowhere for one to be stored even by mistake.
Who processes the payment?
Not named here. Which payment provider handles the isolated card step is an open comparison, not a settled choice — naming one before that comparison finishes would describe a decision that hasn’t actually been made.
No card payment has been processed end to end on a real call — everything above about the card lane describes what the architecture is built to do, not a measured track record. No payment provider is named on this page, for the card step or otherwise. No PCI compliance level or completed assessment is claimed here — keeping card data out of Dohos’s own systems reduces what Dohos is exposed to; it doesn’t by itself constitute a stated compliance outcome. And no claim is made about payment speed, success rate, or savings for either path: cash is proven because it’s the path every live call already completes; card has no live track record to measure.
Talk through your own menu.
Tell Dohos your price points and fulfillment mix, and see exactly how cash settles for your restaurant today.