01The payment boundary
In Dohos's target model, the Restaurant is the seller of food and the merchant of record for a Diner's transaction. A card-paid order is a direct charge against that Restaurant's own verified payment account — not a charge Dohos collects and redistributes, and not funds that pass through a Dohos-held balance. Dohos's own fees, where they apply, are a separately contracted and separately accounted-for line, never blended into the Restaurant's charge in a way that obscures who charged what.
This matters for PCI scope specifically because PCI DSS's requirements attach to whoever stores, processes, or transmits cardholder data — not to whoever merely operates the ordering interface in front of the payment step.
02Why card data never reaches Dohos
A full card number, security code, expiration date, or bank credential is never accepted through the AI voice channel, chat, email, a support ticket, an application log, or an ordinary Dohos-built form. Where a card is needed, the interaction hands off to a provider-hosted collection component — the same pattern as a merchant using a hosted checkout page — and Dohos's own systems never see the raw number pass through.
The voice channel specifically is built to detect a spoken card number, account number, PIN, or similar credential before it is captured or persisted anywhere, interrupt that part of the call, and redirect to the secure payment path rather than ask the caller to repeat it. See how Dohos handles cash and card for what that redirect looks like from a caller's side.
- a card number is never intentionally requested by the AI voice system
- a spoken number is detected and interrupted before it reaches a log, transcript, or model input, not filtered out afterward
- the payment step itself runs through a provider-hosted flow, not a Dohos-built form
- Dohos's own records store the outcome of a payment — authorized, declined, refunded — never the underlying card number
03What this means for a restaurant
A Restaurant's own PCI obligations are not increased by using Dohos, because Dohos never becomes part of that Restaurant's cardholder data environment. The Restaurant remains the merchant of record and keeps whatever PCI posture its own payment provider relationship already requires — Dohos's voice channel sits in front of that relationship, not inside it.
04Scope that remains
Staying out of the cardholder data environment reduces PCI obligations; it does not eliminate every payment-adjacent responsibility. A provider-hosted collection step still needs its surrounding infrastructure — the pages, scripts, redirects, webhooks, and logs that lead into and out of it — inventoried and controlled, because a compromised redirect or a leaking log next to a hosted payment form is still a real risk even when the form itself is provider-hosted.
| STAYS WITH DOHOS | STAYS WITH THE RESTAURANT OR ITS PAYMENT PROVIDER |
|---|---|
| Detecting and interrupting spoken card data before capture | Issuing, authorizing, and settling the actual charge |
| Routing the caller to the secure payment step | Cardholder data environment and its own PCI scope |
| Storing the payment outcome — paid, declined, refunded | Storing or transmitting the card number itself |
| Reconciling order state against the provider's reported result | Chargeback and dispute response as merchant of record |
05Keeping the boundary honest
A payment boundary is only as real as the checks that keep things from drifting across it. Dohos's payments policy requires every script, domain, redirect, webhook, log, support tool, and provider that touches the payment page or flow to be inventoried — not assumed safe because the payment form itself is provider-hosted. That inventory is what "reduces but does not eliminate" actually means in practice: provider-hosted collection removes the biggest single risk, and the surrounding surface still needs its own accounting.
Every webhook the payment provider sends back — a charge succeeding, a refund posting, a dispute opening — is verified before Dohos treats it as true: the provider's signature, a timestamp and replay check, and confirmation that the event actually belongs to the right restaurant and account. An event that doesn't clear those checks is quarantined rather than trusted, and the policy is explicit that a pending request or an unverified webhook is never described to a restaurant as "paid" or "refunded" ahead of that verification.
06Disputes stay evidence-based
When a chargeback or dispute comes in, Dohos's role is to route the provider's notice to the correct restaurant and internal owner promptly, track the deadline, and assemble accurate evidence — order details, acceptance, fulfillment, communications, consent, and refund history — while redacting what isn't needed for that specific dispute. The policy prohibits fabricated or misleading evidence outright; where the restaurant controls the factual merchant response, Dohos still remains responsible for the accuracy of any evidence and representation it creates on its own systems.
Refund authority is handled the same way: Dohos's support does not promise a restaurant-funded refund it doesn't have the authority to approve, every refund is authenticated against the actual order and payment before it's issued, and duplicate or excess refunds are specifically guarded against rather than left to manual attention alone.