This is a proposed notice for future U.S. Restaurant transactions supported by Dohos. It is not current, approved, effective, or evidence that a Restaurant, Payment Provider, connected account, charge type, fee, refund process, dispute process, support contact, or transaction capability is active. The future Dohos legal entity, Restaurants, merchant configuration, Provider agreements, payment flow, jurisdictions, product behavior, and operational contacts remain unverified. This draft must not be published or shown in a transaction until every statement matches the exact live configuration and every activation condition is satisfied.
01Purpose
This notice explains the target roles and steps for:
- reviewing and submitting an Order Request
- Restaurant acceptance or rejection
- payment authorization, holds, capture, and receipts
- prices, taxes, fees, tips, and totals
- cancellation, substitution, and fulfillment issues
- refunds and reversals
- unauthorized, duplicate, or incorrect charges
- payment disputes and chargebacks
- support and evidence
The transaction-specific information presented before final confirmation controls over a general example. The activated notice must identify the Restaurant, location, seller, Payment Provider role, amount components, fulfillment method, material Restaurant policy, and support route.
02Who sells Restaurant Products
Under the target launch model, the identified Restaurant — not Dohos — is the seller of Restaurant Products and the principal responsible for:
- its menu and Restaurant Content
- prices, discounts, availability, and hours
- ingredients, allergens, dietary information, preparation, and food safety
- Restaurant taxes and mandatory charges, subject to Dohos's direct duties for its own charges or representations
- accepting or rejecting Order Requests
- preparation, packaging, substitutions, pickup, and Restaurant-controlled delivery
- cancellation and refund decisions under its policy and law
- Restaurant customer service
Dohos provides the activated technology used to receive, structure, route, confirm, and evidence the interaction and may provide support for that technology.
This role statement is valid only if the Restaurant contract, Payment Provider account, checkout, descriptor, receipt, funds flow, accounting, tax reporting, control, and actual conduct match it. If they do not, the affected capability must not launch under this notice.
03Order Request versus Accepted Order
An Order Request is the reviewed information submitted to the Restaurant asking it to provide specified Restaurant Products.
Submitting an Order Request does not by itself mean:
- the Restaurant accepted it
- an item is available
- preparation started
- a delivery or pickup time is guaranteed
- a payment hold or authorization was captured
- the Restaurant approved an allergy or dietary accommodation
- a receipt or automated acknowledgment is proof of acceptance
An Accepted Order exists only when the Restaurant accepts the exact Order Request through the approved acceptance mechanism. The activated service must clearly communicate whether the request was received, accepted, rejected, needs correction, or remains pending.
04Review before submission
Before the final submission and payment action, the activated flow must clearly present or read back:
- Restaurant legal/trade identity and location in an understandable form
- items, quantities, options, substitutions, and material instructions
- allergy or dietary instruction exactly as captured, without promising accommodation
- fulfillment method, destination or pickup location, and material timing information
- item prices and discounts
- taxes
- mandatory Restaurant or delivery charges
- any separately approved Dohos fee
- voluntary tip and intended recipient/treatment
- total amount and currency
- material cancellation, refund, substitution, and fulfillment policy
- whether the payment action creates a hold, authorization, or charge
- the effect of Restaurant rejection
- the exact action that submits and authorizes the transaction
The Diner and Payer must have a practical, accessible way to repeat, inspect, remove, correct, or decline each material item before confirmation.
Silence, a conversational "okay," background speech, adding an item, asking a question, failing to interrupt, or continuing to browse is not final confirmation.
05Prices and discounts
The Restaurant supplies or approves its item prices and promotions. The price version used at final review should govern unless an obvious error, law, or clearly disclosed Restaurant term requires correction before acceptance.
The activated service must not:
- show a lower headline amount by hiding a mandatory charge
- add a post-confirmation price without lawful authorization
- represent an expired or unavailable discount as available
- use a strikethrough, comparison, scarcity, or percentage claim without substantiation
- discriminate unlawfully in price or offer presentation
- create a dark pattern around an optional add-on or tip
- state that a Provider or Restaurant approved a price without evidence
If a price or discount changes before submission, the complete revised total must be presented for a new confirmation.
06Taxes
The activated flow should identify taxes as accurately as the Restaurant Transaction and jurisdiction require. The Restaurant is the target seller responsible for its transaction tax obligations, while Dohos remains responsible for taxes and disclosures applicable to its own fees and conduct.
A Payment Provider, software calculation, Restaurant setting, or label does not by itself determine the correct legal tax treatment.
If tax cannot be calculated reliably, the service must not guess or conceal the issue. The approved process should correct the configuration, block the transaction, or use a lawful disclosed alternative before confirmation.
Tax questions should be directed to the responsible Restaurant or Dohos contact identified in the activated receipt. Neither the AI system nor this notice provides tax advice.
07Fees
Every mandatory fee must be disclosed with its amount or calculable method and responsible party before confirmation.
The activated service must distinguish, as applicable:
- Restaurant item amount
- Restaurant service or packaging fee
- delivery fee
- taxes
- tip
- approved Dohos fee
- another lawful charge
Dohos must not label its own fee as a Restaurant fee, tax, tip, Provider fee, or delivery compensation. It must not represent a Restaurant fee as a Dohos fee to change responsibility.
The activated Restaurant agreement, Provider configuration, checkout, receipt, ledger, invoice, accounting, tax treatment, refund allocation, dispute evidence, and public text must use the same fee identity.
08Tips
A tip must be voluntary unless law and the clearly disclosed transaction provide otherwise. The activated flow should:
- identify the intended recipient or allocation
- permit an accessible selection, custom amount, and no-tip option where applicable
- avoid preselection or visual pressure that makes an optional tip appear required
- include the tip in the total before confirmation
- preserve the amount and authorization
- handle refunds, adjustments, reporting, and payout consistently
Dohos must not retain, redirect, or describe tips contrary to the disclosed and lawful arrangement.
09Payment Provider
Payments apply only when an approved Payment Provider and Restaurant payment account are activated.
Under the target model:
- the Restaurant is verified for its Restaurant Payment Account
- Restaurant Transactions use the approved direct-charge or other counsel-approved configuration that makes the Restaurant the target Provider-account merchant
- Dohos may receive only a separately approved and disclosed fee through the lawful Provider mechanism
- Platform Charges, arbitrary funds control, wallets, escrow, stored value, and unapproved transfers remain disabled
The activated notice will identify the Payment Provider where required and will link or present any independent Provider terms without implying agreement to hidden terms.
No Payment Provider is named as active because actual account, contracts, configuration, transaction, and reconciliation evidence were not verified.
10Payment credentials
Payment credentials must be entered or captured only through the approved secure Payment Provider path.
Do not provide a full card number, security code, PIN, bank credential, wallet secret, authentication value, or one-time code in:
- an ordinary AI or voice conversation
- a recording or transcript
- a free-form order note
- an SMS or email reply
- a support ticket or chat
- Restaurant Content
- an analytics, feedback, privacy, or accessibility form
Dohos and Restaurant personnel should not ask for those credentials through an ordinary channel. The activated service may retain only permitted nonsecret payment evidence, such as Provider object identifiers, brand, last four digits where lawfully returned, amount, status, timestamps, and receipt/refund/dispute records.
11Payment authorization
By taking the clearly labeled payment action, the Payer authorizes the disclosed amount and purpose through the identified Payment Provider.
The authorization must be limited to:
- the exact Restaurant Transaction and amount presented
- a separately disclosed recurring Restaurant or Dohos arrangement that has its own express consent, confirmation, cancellation, and legal terms
Possession of a phone, device, Account, card, prior order, or delivery address does not by itself prove payment authority. The activated flow must use Provider and risk controls appropriate to the transaction.
Payment authorization is separate from acceptance of the Website and Diner Terms, Restaurant acceptance, marketing consent, recording consent, and privacy choices. See how Dohos handles cash and card for how this boundary is enforced end to end — card data is entered only through the approved Payment Provider path and never reaches the AI, the transcript, or a Dohos database.
12Holds, authorizations, capture, and settlement
Depending on the approved Payment Provider flow, a Payer may see:
- a verification attempt
- a temporary authorization hold
- an uncaptured authorization
- a completed charge
- a partial or adjusted capture
- a reversal or void
- a refund
- a bank/card statement posting that remains pending for a period controlled partly by financial institutions
The activated checkout and receipt must describe the relevant state accurately. An authorization hold is not a settled charge, and a Provider "succeeded" event does not necessarily establish Restaurant acceptance or final bank posting.
If the Restaurant rejects an Order Request, the approved workflow should void or reverse the authorization or issue the required refund promptly. The time a financial institution takes to release or post an amount can vary. The service must not promise a specific bank timing without Provider and operational evidence.
13Restaurant acceptance and capture
The target sequence should link capture to the approved Restaurant acceptance state and risk rules. The exact order of authorization, Restaurant review, acceptance, preparation, capture, and fulfillment must be approved and disclosed where material.
Dohos must prevent:
- capture for a rejected or nonexistent Restaurant Transaction
- duplicate capture from retries or webhook duplication
- capture above the confirmed amount without new authorization
- a refund or cancellation state that fails to reconcile with the Provider and ledger
- a displayed status that differs from authoritative Restaurant/Provider evidence
Every state transition should preserve actor/system, authority, amount, order version, Provider event, time, prior state, reason, and outcome.
14Receipts and descriptors
The activated receipt should identify:
- Restaurant seller and location
- date/time and transaction/order identifiers
- accepted items, quantities, instructions, and fulfillment
- price components, taxes, fees, tip, total, and currency
- payment method description that excludes full credentials
- payment, acceptance, cancellation, refund, and fulfillment status
- applicable Restaurant policy
- support routes for Restaurant and Dohos issues
- the exact Terms/notices or versions where appropriate
The card or bank statement descriptor should be accurate and understandable enough to reduce confusion. It must match the approved merchant configuration and must not conceal Dohos's role or make Dohos appear to be the Restaurant if that is false.
15Cancellations and corrections
The Restaurant's disclosed policy and applicable law govern whether an Accepted Order can be cancelled or changed. Timing may matter because preparation or fulfillment can begin quickly.
The activated service must explain:
- how to request cancellation or correction
- whether the request is pending or completed
- whether the Restaurant has accepted or begun preparation
- who decides the request
- any lawful charge or nonrefundable amount disclosed before confirmation
- payment reversal/refund status
- the escalation route
Submitting a cancellation request does not itself cancel the order. Dohos or the Restaurant must communicate the outcome accurately.
The service must not create an unnecessary obstacle, require an honest review to be removed, or condition a lawful remedy on marketing consent or waiver of rights.
17Refunds
Refund eligibility depends on the Restaurant policy, applicable law, transaction facts, and responsible party. Dohos may provide the intake, evidence, routing, and Provider operation but does not promise that the Restaurant will approve a refund.
An activated refund process should record:
- requester and authority
- Restaurant, order, items, payment, and fulfillment facts
- reason and evidence
- decision-maker and applicable policy/law
- approved amount and components, including tax/fee/tip allocation
- Provider operation and identifier
- ledger and receipt update
- recipient communication
- expected posting information without an unsupported guarantee
A partial refund must explain what was and was not refunded. A Provider refund event does not by itself prove funds reached the Payer's account, and a bank delay does not automatically mean no refund was initiated.
18Duplicate, incorrect, or unauthorized charges
If a Payer sees a charge that appears duplicate, incorrect, or unauthorized, the activated notice should direct the Payer to the monitored support route and identify the Restaurant/descriptor.
Dohos and the Restaurant should promptly:
- locate the transaction and Provider evidence
- protect the Account and payment path
- distinguish authorization, pending hold, duplicate display, duplicate capture, refund, and final posting
- preserve logs and evidence
- correct or refund as appropriate
- coordinate with the Payment Provider
- provide clear status
Do not send full payment credentials to Dohos or the Restaurant. Use the financial institution's official contact for an urgent compromised payment method.
Nothing in this notice limits a non-waivable right to dispute a charge with a card issuer, bank, Payment Provider, regulator, or court.
19Payment disputes and chargebacks
A Payer may have rights to dispute a transaction through the applicable financial institution or Payment Provider. The process and deadlines are controlled by law, network rules, and Provider terms.
If a dispute is opened, Dohos and the Restaurant may provide truthful relevant evidence such as:
- Restaurant seller/location
- exact order and amount version
- confirmation and authority evidence
- Restaurant acceptance and fulfillment evidence
- receipt and communications
- refund/cancellation history
- device/session/security metadata permitted by law
- applicable policy presented before confirmation
Evidence must exclude full payment credentials, irrelevant sensitive data, misleading claims, fabricated status, and another person's or Restaurant's information.
A chargeback is not automatically proof of fraud, and a Provider decision does not resolve every underlying Restaurant, consumer, contract, or legal issue. Retaliation, harassment, or suppression of a lawful dispute is prohibited.
20Restaurant quality, safety, and fulfillment complaints
Issues concerning food preparation, quality, ingredients, allergens, cross-contact, packaging, missing items, substitutions, pickup, Restaurant-controlled delivery, or personnel should be routed promptly to the Restaurant.
Dohos remains responsible for errors caused by its own software, AI output, routing, confirmation, payment integration, public statement, support, or other conduct.
21Delivery
The activated transaction must identify whether delivery is performed by:
- the Restaurant
- a separately identified delivery Provider
- another person
- not offered
Dohos is not the delivery provider under the target launch model. That statement must be removed or revised if actual conduct, control, branding, fees, routing, support, insurance, or contracts indicate a different role.
Delivery timing, location, contact, age/identity, unattended handoff, loss/damage, safety, fees, tips, cancellation, and proof rules require a separate approved flow and Restaurant/Provider evidence.
22Accessibility and language
Order review, correction, confirmation, payment, receipt, cancellation, refund, dispute, and support must be usable through the approved accessible methods.
If a person cannot use the primary route, the activated notice should provide an alternative that preserves substantially equivalent information, privacy, security, price, timing, and control where required and reasonably available.
No universal device, language, assistive-technology, ADA, WCAG, or certification claim is made. The activated notice must identify tested scope and support. See the Accessibility Statement for the assistance route once one is approved.
23Fraud and misuse
Do not knowingly:
- use another person's payment method without authority
- place a fictitious order or payment
- submit false refund or dispute evidence
- create duplicate charge/refund operations
- abuse test cards, Provider objects, promotion codes, tips, or credits
- manipulate AI, support, Restaurant, or Provider systems to state a false status
- access another person's or Restaurant's transaction evidence
Protective action must be proportionate and must not block a lawful dispute, privacy request, accessibility request, emergency route, or regulator contact.
24Contact and escalation
The activated notice will identify:
- the Restaurant contact for order, food, fulfillment, and Restaurant-policy issues
- the Dohos contact for technology, AI, Account, privacy, accessibility, security, and Dohos support issues
- the Payment Provider or financial-institution route where appropriate
- any required regulator or emergency information
25Changes
Dohos must update this notice before a material change to seller/merchant identity, Payment Provider, charge type, funds flow, fees, tips, taxes, authorization/capture, order acceptance, refunds, disputes, delivery, support, or law becomes active.
The activated notice must state its version, effective date, covered Restaurants/capabilities/jurisdictions, and contacts. Prior versions and transaction evidence must be preserved. A later notice cannot retroactively authorize an earlier charge or cure a misleading transaction. Superseded versions, once any exist, will be preserved at the version archive.