| Takeaway | Detail |
|---|---|
| Commission does not reconcile an order. | On a $40 order, DoorDash can take $6 to $12 depending on the restaurant plan, before food, labor, or packaging. |
| A confirmation is not a capture receipt. | For the same $40 checkout, match authorization, capture, discounts, fees, and tip to one transaction. |
| Refunds must close the financial loop. | For a $40 test order, trace any refund from its captured amount through the reversal and adjusted merchant remittance. |
| Merchant and Dasher settlement must agree. | A 15% Basic commission and a 30% Premier commission frame merchant fees but do not prove Dasher payout accuracy. |
DoorDash's reported $13.7 billion in 2025 revenue is less useful as a launch test than one $40 order. On that order, the restaurant commission can be $6 to $12, depending on the plan, before food, labor, or packaging. That spread is the first surprise: a fluent bot can produce a tidy checkout narrative while leaving the financial ledger unresolved.
The second gate is capture. Reconcile the exact checkout total, authorized amount, captured amount, discounts, fees, and tip on the same order. A DoorDash order confirmation shows what the system intended; it is not, by itself, a capture receipt. The launch criterion should be one documented cash trail, not a persuasive conversation or a plausible total.
The third gate is downstream settlement: refund the order if needed, then tie the merchant remittance and Dasher payout to the same transaction. A 15% Basic commission and a 30% Premier commission can describe merchant economics, but neither proves money moved correctly. I would reject an agent with excellent conversational accuracy unless it can reconcile one order across checkout, capture, refund, merchant remittance, and Dasher payout.
One DoorDash Order ID, Three Gates
DoorDash’s 2026 text-order announcement clears the consumer interface, not the launch test. According to iPhone in Canada’s “DoorDash Unveils Text Ordering, Drone Delivery and New AI Tools,” text ordering was unveiled in Canada; 9to5Mac reports that DoorDash lets customers order by text within Apple Messages. Neither source proves that an SMS intent can create a cart through an approved server integration. Verification remains failed until DoorDash’s own 2026 Checkout or commerce-integration documentation identifies the cart-session API, authentication, market eligibility, and signed order and payment events. DoorDash Drive establishes delivery operations only—not consumer-ordering or payment access.
| Required arrow | Owning system | Control evidence |
|---|---|---|
| SMS → intent parser | SMS provider and order-orchestration server | Signed inbound message and parser audit |
| Intent parser → approved DoorDash-hosted cart | Server-side commerce adapter and DoorDash Checkout | Official API and session contract; no browser automation |
| Hosted cart → DoorDash order record | DoorDash order service | Canonical order ID and frozen confirmation |
| Order record → payment authorization/capture | DoorDash payment service and payment processor | Authorization ID, capture ID, and one signed final outcome |
| Processor → DoorDash settlement | Processor and DoorDash settlement service | Matching settlement ID and captured amount |
| Settlement → merchant remittance | DoorDash merchant-financials system | Remittance ID tied to the order; gross, fees, and net reconcile |
| Order/capture → Dasher payout line | DoorDash delivery-payout ledger and Dasher app | Payout line ID tied to the order; payable amount reconciles |
An undocumented browser hop breaks checkout provenance; a manual spreadsheet breaks payout provenance. Either fails its gate. An “order placed” message proves neither capture nor correct remittance.
Create the immutable canonical DoorDash order ID at final checkout. Append—never overwrite—an order-level identity map to the processor authorization ID, capture ID, refund ID, DoorDash settlement ID, merchant remittance ID, and Dasher payout line ID. If an upstream record omits DoorDash’s order ID, require a deterministic, documented, auditable crosswalk before treating that cash leg as reconciled.
Run one server state machine: CREATED → CHECKOUT_SENT → AUTHORIZED → CAPTURED → FULFILLED → SETTLED, with DECLINED, CANCELLED, REFUNDED, and DISPUTED exceptions. Only signed DoorDash or processor server events may advance it. An unknown timeout triggers a status lookup using the existing canonical ID; it never authorizes another order or capture.
Freeze the authoritative checkout snapshot: restaurant, fulfillment mode, every item, modifier, and quantity, address, subtotal, tax, service and delivery fees, tip, total, cancellation terms, timestamp, and pricing version. Any later change requires a revised total and explicit customer reconfirmation before capture.
Place the credential boundary at PCI DSS v4.0.1 Requirement 3.4.2: the primary account number must be unreadable after authorization. DoorDash’s hosted checkout and its compliant processor collect payment directly. The agent may relay a hosted-checkout URL and opaque status, but may not receive, log, or store a primary account number, CVV, or one-time code.
Go only when checkout, processor capture, and DoorDash settlement reconcile to that one DoorDash order ID. Otherwise, ship a handoff-only assistant or do not launch.
Five Public Numbers
The launch signal is not “Your DoorDash order is placed.” It is a source-to-ledger tie-out: public pricing, tip, distance, and remedy clocks must agree with checkout and payout records under one canonical DoorDash order ID. In treasury accounting, these are control fields, not copy for the agent. Raw card, CVV, and one-time-code data must remain outside the agent boundary.
| Public authority | Published rule | Required reconciliation control |
|---|---|---|
| DoorDash, “Fees on DoorDash” | Customers pay delivery fees, a service fee roughly 10–15% of the subtotal, small-order fees, and suggested tips. The supplied results do not provide a text-ordering-specific fee schedule. | Replace any local fee constant with the authoritative checkout amount. A checkout response that cannot be tied to the canonical order is a stop condition. |
| DoorDash, “Dasher Pay” | DoorDash calculates its own suggested tip amount when an order is placed and automatically selects the suggested tip during checkout. The supplied sources do not establish a text-order-specific Dasher Pay schedule. | Store separate quoted-tip and paid-tip fields. Any difference between the quote and payment must be reconciled to documented records. |
| DoorDash’s standard Dasher Pay schedule | The supplied results do not provide a standard distance-based Dasher Pay schedule for the Apple Messages pilot. | Make documented payout components required payout-leg attributes. The same basket can produce different Dasher amounts, so basket value alone cannot explain a payout variance. |
| Regulation E | For covered unauthorized electronic fund transfers, consumer notice is generally due within 60 days; provisional credit within 10 business days; investigation results within 45 days; and the generally applicable outer limit is 90 days. | Capture each remedy-clock event, but do not misstate these consumer remedy periods as merchant payout SLAs. |
| Regulation Z | For credit-card billing errors, written notice is generally due within 60 days, acknowledgment within 30 days, and resolution within two billing cycles or 90 days, whichever is shorter. | Retain itemized receipts and authorization, posting, reversal, dispute, acknowledgment, and resolution timestamps. These duties support evidence retention, not a promised platform-refund deadline. |
The published fee descriptions are especially useful as a checkout-drift test. A local calculation that merely resembles DoorDash’s reported fee range is not evidence that the approved DoorDash-hosted checkout supplied the amount actually authorized and presented to the customer. Likewise, tip and distance belong on distinct payout records: comparing only the basket total with the Dasher payment conceals whether the variance came from the tip treatment or the delivery leg.
The two federal clocks answer a different question. Regulation E governs consumer remedies after an unauthorized electronic fund transfer; Regulation Z governs credit-card billing errors. Neither timing rule proves that DoorDash captured one payment or settled the restaurant and Dasher legs correctly. They tell treasury teams which evidence to retain, not when a marketplace payout must become final.
My launch close is therefore mechanical: go only when the approved DoorDash-hosted checkout, one server-verified processor capture, and DoorDash settlement reconcile to one canonical order ID. Any missing authoritative amount, tip-field exception, distance attribute, or payout-leg mismatch blocks launch. If those records cannot agree, ship as a handoff-only assistant or do not launch. The ability to send a successful SMS proves neither a single charge nor a correct payout.
Supported Checkout vs. Browser Automation
The non-obvious answer is that the safest agent is the component that never sees payment credentials. DoorDash’s Checkout documentation describes both a hosted checkout page and an embedded checkout integration. The approved hosted handoff is the only candidate capable of clearing all three gates because DoorDash owns cart state while the agent receives only an authenticated server result. Gadget Review’s report of DoorDash’s Apple Messages pilot establishes an interface, not account-wide permission to create SMS orders or export settlement evidence.
Price fidelity is an audit issue, not cosmetics. According to Sauce’s restaurant-plan explainer, DoorDash takes $6 to $12 on a $40 order, depending on the restaurant’s plan, before food, labor, or packaging. That documented spread is why a scraped cart or agent-computed total cannot serve as the authoritative amount.
Before choosing an architecture, require four artifacts: the current DoorDash Checkout or commerce terms; integration and order-event documentation; the signed Merchant Agreement and payout-report specification; and a security/support escalation path. DoorDash Help Center categories—Payments, Promotions, Troubleshooting, and Your DoorDash Order—can route an incident, but they are not an integration contract. Neither the word “embedded” nor a product page substitutes for permission covering the specific account and SMS flow.
Then test capability by account, not marketing language. Can the flow create or edit a cart from SMS, return the authoritative total and DoorDash order ID, emit signed payment and refund events, and join merchant and Dasher payout rows? Score checkout, payment, and payout separately as 0 or 1; require 3/3. Put order-ID continuity inside every score: an otherwise valid payment event earns no payment point without the same DoorDash order ID, and a payout row earns no payout point without that tie.
Browser automation substitutes mutable presentation and credential exposure for authoritative records. An agent-owned card API also fails the commerce test: a separate payment cart can succeed without proving DoorDash accepted the order, while tokenization, 3DS, retries, and liability remain detached from merchant and Dasher settlement. If the supported integration produces only a checkout link or intent, choose handoff-only operation. Never add browser control, agent-held credentials, or a fabricated confirmation. “Your DoorDash order is placed” is not proof of one capture or correct payout; launch only when checkout, processor capture, and DoorDash settlement reconcile to one canonical order ID.
| Build route | Checkout test | Payment test | Payout test | Verdict |
|---|---|---|---|---|
| Approved DoorDash-hosted Checkout handoff | DoorDash renders the cart, final amount, and order ID. | The hosted flow returns server-side status; the agent receives no PAN, CVV, or one-time code. | A documented crosswalk joins merchant and Dasher records under the same order ID. | Conditional WINNER if this year’s account permits the SMS flow; eligible for 3/3. |
| Consumer-site browser automation | DOM changes can silently corrupt items, promotions, fees, or addresses. | A browser state can misclassify pending, declined, and captured payments and may expose credentials. | No supported settlement-data or dispute trail. | Reject; the payout gate fails. |
| Agent-owned card or payment API | A separate payment cart cannot prove DoorDash accepted the order. | The agent owns tokenization, 3DS, retries, and liability without a DoorDash order link. | No native merchant or Dasher settlement mapping. | Reject; checkout/payment linkage and payout mapping fail. |
What the Data Doesn't Tell You
The non-obvious launch risk is not the absence of a success path; it is confidence built from evidence that sees only part of the control. DoorDash’s public Checkout documentation establishes an approved integration path, and its text-order announcement establishes the intended experience. Neither is an audited population of completed SMS orders across payment states, payout events, and agent-access logs. Capability evidence is not operating-control evidence.
The central limitation is linkage. A documentation example, announcement, dashboard screenshot, or happy-path transcript cannot show that an approved DoorDash-hosted checkout, one server-verified payment outcome, and order-level payout reconciliation all resolve to the same canonical DoorDash order ID. Nor can functional success prove that raw card, CVV, or one-time-code data stayed outside the agent’s prompts, tool arguments, state, logs, and traces. What the available data omits is exactly what a launch control must prove.
Variance appears when timing or state changes. A client timeout can follow server acceptance; a retry can introduce a competing payment event; cancellation can precede or follow capture; and a refund, dispute, or payout adjustment can change the final ledger position after the customer-facing status appears. Test those branches separately rather than treating repeated happy-path orders as independent proof. Use exception replay and declare an observation cutoff: an unresolved state is unknown, not successful.
A message saying “Your DoorDash order is placed” proves only that the interface emitted a status. It does not prove one capture, a final payment state, or correct restaurant and Dasher payouts. The message is therefore a conversational receipt, not evidence of financial reconciliation.
The canonical rule breaks whenever checkout, processor capture, and DoorDash settlement cannot be tied to one canonical order ID, whenever more than one final payment outcome remains plausible, or whenever order-level payout attribution is incomplete. Sensitive-data exposure is a separate failure even if the money reconciles: if the agent can receive raw card, CVV, or one-time-code data anywhere in its execution path, the launch premise fails. Ambiguity in any of these conditions requires a handoff-only assistant or no launch.
| Evidence artifact | Strongest warranted conclusion | What it does not prove |
|---|---|---|
| DoorDash Checkout documentation | A supported checkout path exists | Every SMS order completed the financial control |
| DoorDash text-order announcement | The intended ordering experience exists | Production outcomes are uniformly correct |
| Agent transcript | A customer-facing status was emitted | Payment or payout finality |
| Processor record | A payment event was recorded | One final outcome or correct order-level allocation |
| Settlement report | A payout event is present | Complete checkout, payment, and order-level tie-out |
| Access and redaction logs | Boundary behavior in the sampled path | Absence of sensitive data across every agent surface |
Concrete next action: make launch sign-off a reconciliation packet, not a demonstration. Index it by canonical order ID and attach the hosted-checkout record, final server payment evidence, order-level settlement evidence, and agent-surface redaction checks. A missing, conflicting, or still-pending attachment is a nonpass and keeps deployment at handoff-only.
Why a Clean Pilot Still Is Not Proof
A DoorDash pilot can repeat the same basket through controlled transactions, record no observed failures, and still leave launch readiness unproved. A clean selected run is compatible with an unobserved, uncommon failure mechanism. A green pilot therefore shows only that the selected run did not expose the mechanism; it does not establish that tail risk is negligible.
Case mix is the second defect. One basket design does not cover tax jurisdictions, promotions, gift cards, wallets, substitutions, partial cancellations, refunds, chargebacks, delivery distance, or failed handoffs. Repeating that basket improves consistency, not coverage. Even aggregate total equality can conceal incorrect line-level allocation: an order can gross to the right amount while tax, promotion funding, item credits, or the merchant and Dasher legs are assigned incorrectly.
Source authority sets the third limit. A DoorDash Help Center article is guidance, and a public fee page is published disclosure; neither is the signed Merchant Agreement or a merchant-specific payout statement. DoorDash Help Center and Gadget Review materials do not supply a text-order merchant payout schedule, payout timing, reserve percentage, payout method, or settlement delay, and the supplied fee estimates are not specific to the Apple Messages ordering pilot. Label every rate as published, contractual, or assumed. Published establishes provenance, contractual governs the model, and assumed remains a scenario until supported.
Timing makes a passing response especially weak evidence. DoorDash acceptance can precede authorization or capture, while capture can precede cancellation, refund, reserve adjustment, or dispute. Therefore, PLACED, CAPTURED, SETTLED, and PAYABLE are distinct control states, not synonyms. A status history tied to the canonical order ID must preserve transitions and reversals; the message “Your DoorDash order is placed” cannot prove a single charge or a correct restaurant and Dasher payout.
Data access can prevent that history from being assembled. The processor may expose authorization and capture but not DoorDash payout; DoorDash may expose settlement but not processor authorization. A one-sided report is not a reconciliation. A two-party export or documented crosswalk must link both records to the same canonical order ID; absent that link, the payout gate is unknown, not green. Those exports should be minimized so raw card, CVV, and one-time-code data never enters the agent context.
| Evidence reviewed | What it establishes | Launch treatment |
|---|---|---|
| No observed failures in the controlled transactions | No failure within the selected case mix | Insufficient evidence that tail risk is negligible |
| Narrow basket coverage | Only the exercised ordering path | Test omitted tax, payment, adjustment, and handoff paths |
| Published fee or help material | Public guidance, not merchant-specific economics | Replace assumptions with executed contractual terms |
| One-sided processor or DoorDash export | Only one side of the cash chain is visible | Obtain a two-party export or documented crosswalk |
| Order, line, or payout mismatch | The canonical reconciliation fails | Use handoff-only operations or do not launch |
Go only when the approved DoorDash-hosted checkout, one server-verified processor capture, and order-level DoorDash settlement reconcile to one canonical order ID. If any gate lacks evidence, ship as a handoff-only assistant or do not launch.
Plus-Plan Commission, Capture, and Merchant-Leg Reconciliation
I would build a controlled Plus-plan fixture in DoorDash’s sandbox. DoorDash’s restaurant-plan explainer uses a $40 order and reports $6 to $12 in platform commissions depending on the restaurant plan, before food costs, labor, or packaging. Those are published delivery-order examples, not a live customer quote or evidence of the Apple Messages pilot’s terms.
DoorDash’s published tiers are Basic at 15%, Plus at 25%, and Premier at 30% per delivery order. The supplied results provide no text-order-specific commission rate and do not establish that the standard delivery-order range applies to the Apple Messages pilot. The applicable signed agreement must define the percentage base and any separate payment-processing fee.
For the fixture, record the authoritative checkout total, commission, merchant proceeds, Dasher payout, taxes, delivery charges, discounts, and tips as separate sourced lines. Any amount not established by the applicable pilot terms remains unknown rather than being filled with an assumed value.
| Ledger line | Fixture calculation | Expected amount | Control |
|---|---|---|---|
| Order value | Published delivery-order example | $40 | Example only; not a pilot quote |
| DoorDash Plus commission | Published tier rate | 25% | Do not assume pilot applicability |
| Merchant food proceeds | Documented amount after commission and deductions | Not stated in supplied results | Tie to merchant reference |
| Dasher payout | Pilot payout | Not stated in supplied results | Tie to Dasher reference |
| Customer checkout | Authoritative DoorDash checkout total | Not stated for the pilot | Compare with processor records |
| Authorization | Processor authorization | Must match authoritative checkout | Distinct processor reference |
| Capture | Processor capture | Must match authoritative checkout | Must equal checkout |
Mark the case PASS only when checkout equals capture and every cash leg reconciles without a plug. If tax, a discount, a refund, or distance changes any line, mark settlement PENDING and reprice from the executed agreement rather than forcing the sample allocation. Go live only when checkout, processor capture, and DoorDash settlement reconcile under that one canonical order ID; otherwise remain a handoff-only assistant or do not launch.
Five stop rules operationalize DoorDash’s three launch gates: checkout, payment, and payout. The non-obvious control is not the SMS saying that an order was placed. It is the operator’s ability to prove, for every order, that the approved checkout, the server-verified capture, and DoorDash settlement resolve to the same canonical DoorDash order ID. Any failure makes the agent handoff-only rather than merely “not yet proven.”
The checkout edge case is documentation drift. A hosted cart available only on ordinary DoorDash checkout does not establish that the SMS agent can create or edit it under current contracts. The launch file should identify the approved API or product surface, applicable market, cart revision, authoritative total, and returned DoorDash order ID. Browser automation is not a control; it bypasses the contractual boundary the gate exists to test.
Five
Frequently Asked Questions
On a $40 DoorDash order, how much can the restaurant commission be before food, labor, or packaging?
DoorDash can take $6 to $12, depending on the restaurant plan, before food, labor, or packaging.
Does a DoorDash order confirmation prove that the customer's payment was captured?
No; a confirmation shows what the system intended, so the exact checkout total, authorization, capture, discounts, fees, and tip still must be reconciled on the same order.
What has to be documented before an SMS intent can create a cart through an approved integration?
DoorDash's own 2026 Checkout or commerce-integration documentation must identify the cart-session API, authentication, market eligibility, and signed order and payment events.
What identifiers must connect checkout, capture, refunds, and both payout legs?
An append-only order-level identity map tied to the canonical DoorDash order ID must link the processor authorization ID, capture ID, refund ID, DoorDash settlement ID, merchant remittance ID, and Dasher payout line ID.
What should the order system do after an unknown timeout?
It should look up status using the existing canonical order ID and must not authorize another order or capture.
What payment information may a text-ordering agent relay or store?
The agent may relay a DoorDash-hosted checkout URL and opaque status, but it may not receive, log, or store a primary account number, CVV, or one-time code.
Quick answers
| What must DoorDash documentation identify before an SMS intent can create a cart? | Verification remains failed until DoorDash’s own 2026 Checkout or commerce-integration documentation identifies the cart-session API, authentication, market eligibility, and signed order and payment events. |
| How must the parser connect an SMS intent to an approved DoorDash cart? | Use a server-side commerce adapter and DoorDash Checkout with an official API and session contract, without browser automation. |
| What must be reconciled during the capture gate? | Reconcile the exact checkout total, authorized amount, captured amount, discounts, fees, and tip on the same order. |
| What must be verified during the downstream-settlement gate? | Refund the order if needed, then tie the merchant remittance and Dasher payout to the same transaction. |
| What is the launch criterion for DoorDash text ordering? | Checkout, processor capture, and DoorDash settlement must reconcile to one canonical DoorDash order ID. |
Also worth reading: DSO in 2026: Same-Day ACH, Rail Routing, and Benchmarks: DSO in 2026: Same-Day ACH, · RTP vs Same-Day ACH: Fees, Routing, and the 24/7 Clock: RTP vs Same-Day ACH: Fees, · $5M Weekly Payouts: $30 Wire Cost, Limits and Reach: $5M Weekly Payouts: $30 Wire