GEO-099·Issue 09·Technical Foundation·99 / 132
What AI Checkout Needs: Price, Stock, Shipping, Returns
An agent drops the cart when its quote, hold, and confirmation disagree. Four data families, an exception dictionary, and a five-step contract to test.
Issue focusReady to Transact: Agentic Commerce and Product Feeds
At 10 p.m. an outdoor-furniture brand’s ops channel catches a failed order. A buyer in rural Montana asked an assistant to order a folding camp table. The quote said in stock, two-day delivery; confirmation returned a generic error. The cause: that ZIP carries a remote-delivery surcharge the quote never priced, and the only sellable unit was a floor sample. The buyer did not retry; the assistant had already offered a competitor.
AI checkout is not handing your cart to an agent. It is a forty-second interrogation — what this costs to this address, whether you can hold the unit, when it lands, how it comes back — and one hedged answer ends it.
Checkout is three exchanges, not one page load
An agent never opens your checkout page and clicks through it. It makes three calls — quote, hold, confirm — seconds apart, or again after a timeout. Each must stand alone.
Quote answers what this address and quantity cost now. Hold answers whether you can reserve this unit. Confirm answers whether the order exists and what you promised. A call that answers with a range invalidates the earlier calls; a retry multiplies the ambiguity.
A page lets a person guess: shipping at step three, arrival in three to seven days. The agent reports only what it can compute; protocol and payment sit in agentic commerce readiness.
Four families, four ways to fail
These look like page elements; to an agent they are four questions, four failure modes.
| Family | The agent asks | The response needs | Without it |
|---|---|---|---|
| Price | What is the landed total here? | Unit price, currency, tax, shipping, discounts, validity | Appends “check the retailer’s site” |
| Stock | Can you hold this unit now? | Sellable quantity, state, reservation window | Reports “may be unavailable” and quits |
| Delivery | Which day, and can you reach this address? | Reachability, service level, arrival window | Says “standard shipping,” gives no date |
| Returns | What if I don’t want it? | Window, return freight, opened-box terms, final-sale flag | Calls the policy unclear, pushes risk to the buyer |
Price and stock are transaction fields; the page, structured data, feed, and quote must move together. Delivery and returns are decision fields: the agent needs a comparable condition, not a disclaimer.
Validity is the fifth variable: a hold lasts as long as you can reserve, a quote as long as you can honor.
Exceptions decide the order
A successful order proves little; what an agent learns is how you fail.
Three patterns do the damage. Silent substitution: the price moved, so you book the new price; stock ran short, so you ship the next model up. Opaque failure: one code for every cause, so the agent cannot tell a bad address from an empty shelf; it replays or quits. Fake success: nothing sellable sits behind the SKU, the endpoint answers 200, the storefront stays buyable, and the buyer cancels four weeks later.
Each exception returns a stable code plus one executable alternative: split the shipment, convert to preorder with a date, switch carrier, offer a pickup point, declare the item unsellable. An agent handed an alternative can rescue the order; a 500 sends it to another brand. Returns work the same way — window and conditions must be machine-readable, as argued in shipping and returns policies.
Five steps to a testable contract
| Step | Action | Owner | Passes when |
|---|---|---|---|
| 1 Map the exchange | What each call returns, who depends on whom | Product, engineering | Every field points at one system |
| 2 One source, stated TTL | Four families answer from one service; validity in the contract | Engineering | A price change shows on the next request |
| 3 Exception dictionary | Code, meaning, allowed actions, fallback owner | Engineering, support | Every code has copy and an alternative |
| 4 Sandbox rehearsal | Twenty SKUs against remote ZIPs, last units, expired discounts | Engineering, growth | Failures reproduce from a script |
| 5 Monitor by cause | Conversion and refunds grouped by failure reason | Growth | You can name the most expensive failure |
Step 3 makes the project converge: the dictionary is not a code list but a promise about what happens next. Step 4 is the only step falsifiable before launch — quote, hold, confirm, then change stock mid-flight or wait out the quote’s validity. If the script cannot produce a failure, it is too polite, not the system stable. Track causes beside your AI visibility baseline.
Example: one folding table, four calls
Example — hypothetical brand; products, prices, and ZIP codes are invented.
09:14, the quote returns $129, in stock, two-day arrival. 09:15, the hold returns “reserved” — catalog stock, not sellable stock. 09:16, confirmation hits the remote ZIP: a $38 surcharge the quote never carried, and a generic error. 09:17, two retries, same error. The agent gives up and buys a competitor.
Post-mortem: the quote did not price the destination; the hold locked an accounting number; the error had no code and no alternative.
Fixes: price shipping by postal code and state the quote’s validity; return sellable quantity and a hold window, and say so when you cannot hold; split exceptions into unreachable address, price changed, insufficient quantity, each with one action; return a human checkout link on failure.
Acceptance is the same SKU batch before and after, not one successful order: did “generic error” collapse into named categories, did refunds fall.
Where this breaks
First, if agent orders are still a minority, fix the product page and feed, and amortize interface work against volume.
Second, when sales concentrate in a marketplace, the platform owns the interface; you control stock, fulfillment, and return settings.
Third, custom and wholesale products have no fixed price. Use request, human confirmation, validity window — not an instant quote repeated back to you.
Fourth, payment, installments, and warranty belong to the trust layer in transaction trust signals, and return terms are legal’s call — withdrawal rights, final-sale rules, cross-border return cost. Report both honestly; do not decide them in code.
Fifth, flash sales can make validity meaningless: say “price fluctuates” instead of false precision.
This month, run quote, hold, confirm against ten live SKUs. Mark the family you cannot answer, give the most frequent exception a code and an alternative, wire it to monitoring. The rest of the data layer is on the technical foundation hub.