dohosGet started
PLATE Nº 096 · DOCUMENT

Payments and card data

TARGET-STATE DRAFT — NOT APPROVED OR EFFECTIVE · PENDING THE PAYMENTS GATE
STATUSDraft — pending the payments gate
LAST REVIEWEDNone yet — no review has run
CONTACTvia /contact/security
DRAFT NOTICEThe rule that a raw card number never reaches Dohos is a settled build requirement, stated plainly below without a hedge. Everything else on this page — the specific payment account model, refund and dispute handling, and PCI scope — is drawn from Dohos's internal payments policy, which is itself an unapproved draft describing a target architecture that has not yet processed a real transaction end to end.

01The rule this is built around

Dohos's build specification states this as a non-negotiable requirement, not a preference to be balanced against convenience: a card number, expiry date, security code, or payment touch-tone digit must not enter the AI system, the speech-to-text pipeline, a call recording, a transcript, an application log, an ordinary backend endpoint, or Dohos's own database — at any point in a call.

That means a caller can place a card-paid order by phone without a human or a machine at Dohos ever seeing or hearing their full card number. It is a design constraint the call-and-order flow is built around, not a claim resting on a long operating history — Dohos states it as architecture, and a reviewer verifying it should ask how the isolation is implemented, not just take the sentence on faith.

02How a card-paid call actually works

When a caller is ready to pay by card, the target design routes that specific moment through a separate, PCI-scoped collection step — isolated from the AI conversation and from Dohos's own recording and transcript pipeline — rather than having the card number spoken into the same channel as the rest of the order. What comes back to Dohos from that step is a payment outcome, not the card details themselves.

ATTENTIONThe specific provider for this in-call collection step is not named here on purpose. The pilot's own build plan is still comparing a small number of PCI-compliant options for it and explicitly calls the choice "a real pilot blocker" not yet resolved. Naming one option as if it had already won would be inventing a decision that hasn't been made.

03What Dohos stores instead of a card number

In place of card details, Dohos records a payment outcome and a reference to the transaction at the payment provider — enough to know whether an order is paid, and to look up the transaction with the provider if a dispute arises, without holding the underlying card number itself. The states a payment can be in are kept distinct rather than collapsed into a single "done" flag:

ORDER PAYMENT STATES
  1. paid
  2. cash_due
  3. failed
  4. voided
  5. refunded
  6. unknown — when the provider's status cannot be verified

"Unknown" is a real, distinct state in this model, not an omission — Dohos's policy is explicit that an order should never be described as "paid" or "refunded" from a pending request or an unverified webhook.

04Confirmation and webhook integrity

A caller's "yes" during the order readback is bound to the exact version of their cart at that moment. If anything changes after that — an item availability update, a price correction — the confirmation no longer applies and the system is designed to re-confirm rather than charge for something the caller didn't actually agree to. Payment submission is designed to happen once, with a unique reference per attempt, so a retried request or a dropped connection can't produce a second charge for the same order.

Notifications from the payment provider — confirming a charge succeeded, failed, or was refunded — are meant to be verified as genuinely coming from that provider, checked for a reasonable timestamp, and matched to the right restaurant's account before Dohos treats them as fact. An unverified or ambiguous notification is meant to be held back rather than trusted at face value.

05The restaurant's own payment account

Under the target payment model, the restaurant is the seller and merchant of record for its own transactions, not Dohos. Charges are designed as direct charges against the restaurant's own connected Stripe account, so the money for a restaurant's sale flows toward that restaurant's own account rather than pooling in a Dohos-controlled balance. Freezing a restaurant's funds, holding a reserve against it, or delaying its payouts is not something this model permits outside a deliberately changed, fully governed process — it is not a lever Dohos's support team can pull informally.

06Cash orders

A cash-due order is settled at the restaurant itself, outside any Dohos payment flow entirely, and reconciled through the restaurant's own end-of-day closeout — cash a restaurant collects never touches a Dohos payment system to begin with, because there is nothing electronic to touch.

07PCI scope

Routing card capture through a dedicated, PCI-compliant provider reduces Dohos's own PCI obligations, but it does not eliminate them outright, and this page does not claim a specific PCI compliance level or a completed assessment. Dohos's own policy is explicit on this point: a payment provider's own compliance does not automatically establish Dohos's compliance, and no PCI claim is made without the actual architecture, scripts, and personnel process behind it being verified first. The fuller compliance framing — what PCI scope actually means for a company that never touches card numbers — lives at PCI.