A recommendation becomes commerce when an order can be completed
AI shopping agents for ecommerce interact with several different kinds of interface. An assistant may read a public product page, open the merchant's checkout, or call a documented commerce API. The appearance of a product in an answer tells you that some discovery happened. It does not establish that the customer approved a purchase or that money changed hands.
Take a fictional buyer, Sam, who wants a downloadable industry report. Sam asks an assistant to find the current edition and spend no more than $35. A useful recommendation names the edition and seller. A purchase requires the assistant to obtain the merchant's actual terms, stay within Sam's authority and receive an order result that can be checked. The illustrative report costs $29 before any applicable additions; the merchant's checkout determines the final amount.
An AI support widget answering a question about downloads has a different role. It may reduce uncertainty, but it has not necessarily created a checkout or acquired permission to pay. Keep support usage, shopping referrals and authorized purchases separate in your reporting. Otherwise a popular chat feature can make an unsuccessful buying route look healthy.
What the agent reads and what it changes
During discovery, the agent needs enough product data to avoid selecting a similarly named but unsuitable item. For the report, that includes the edition, format, license and any delivery restrictions. Product identifiers matter because titles can be shortened or rewritten by an interface. The merchant should preserve a stable identity from the displayed offer into checkout.
At checkout, the merchant supplies current costs and terms. OpenAI's checkout specification defines a session lifecycle in which the merchant returns calculated line items, totals and messages as the session changes. Treat the official schema as the contract for that integration, rather than asking the model to infer the price from a description. [1]
The buyer's permission must apply to the purchase being completed. In our example, a $35 cap does not permit an unrelated subscription merely because its first payment is $29. A clear approval describes the seller, report edition, total and one-time nature of the order. If an important term changes, return to the approval or policy check before proceeding.
A purchase through the agent’s eyes
- Read the offer
Match the report edition, license and seller to the customer request.
- Request a checkout
Obtain the merchant-calculated total and delivery terms.
- Check authority
Confirm that this purchase fits the buyer’s approval and spending scope.
- Complete payment
Submit through the supported route and retrieve the result if uncertain.
- Receive the order
Use the order and fulfilment result to obtain the purchased report.
Evidence shows where the journey stopped
Suppose the agent finds the report and receives a quote, then loses its connection after requesting completion. The merchant might already have created the order. Sending another payment immediately could create an avoidable duplicate. The agent should retrieve the authoritative checkout or order status and resolve the existing attempt first.
A payment record is also insufficient evidence of delivery. The merchant needs a fulfilment result, such as a valid entitlement that gives the buyer access to the purchased report. Keep sensitive download credentials out of public logs. Store enough reference information for support to locate the entitlement without exposing the product to someone who only knows an order number.
If the download service fails, the buyer should see the paid order and a meaningful pending state. The merchant can then retry delivery or apply its disclosed refund policy. Asking the agent to buy the same report again hides the original failure and makes the customer's account harder to reconcile.
Evidence at each boundary
Scroll the table to compare all columns.
| Stage | Useful evidence | What it does not prove |
|---|---|---|
| Discovery | Stable report identifier and offer response | That the buyer consented |
| Checkout | Current session and final total | That a payment succeeded |
| Payment | Verified provider result tied to the order | That the report was delivered |
| Fulfilment | Entitlement or delivery receipt for the purchased edition | That every later support issue is resolved |
The merchant controls the parts that make the offer real
You control the product description, the authoritative price, the inventory or access rules and the delivery promise. A shopping surface may control how it displays recommendations and gathers a customer's actions. Your payment provider controls its processing contract. Write down those boundaries so an integration error has an owner.
Channel behavior also differs. Shopify currently describes a ChatGPT journey that ends at the merchant's checkout, while other eligible channels can use Shopify-powered direct checkout. That distinction changes what an agent can do inside the conversation and which interface the customer sees before paying. It should change your test plan as well. [2]
For your first test, use a product with a clear fulfilment outcome and avoid combining several new workflows. Check one success, one changed price, one declined payment and one delivery failure. Record the expected result before each test. These scenarios are a recommended evaluation method, not a claim that a named platform has passed your store's checks.
Choose the next guide by the missing capability
Read the authentication guide if you cannot explain who approved a purchase and what that approval covers. Use the checkout API guide when the agent needs a reliable current total and a status it can retrieve. Use order management when payment and delivery diverge. The ACP guide covers the merchant-facing checkout contract; other standards have different jobs.
AP2 is a payment authorization framework with linked checkout and payment mandates and explicit verification roles. It does not replace a merchant's catalog or every commerce API. That separation is useful even when your chosen route uses different technology: the system describing a purchase and the system authorizing its payment need a dependable connection. [3]
The practical outcome is a traceable customer journey. A merchant should be able to say which report was selected, which terms the buyer accepted, which payment attempt funded it and whether the buyer received access. When one of those answers is missing, fix that boundary before treating more discovery traffic as proof of a working sales channel.