Before you expose catalog, inventory, and checkout to an agent, test the six contracts that make one order trustworthy.
“Find me a black jacket with no real fur, deliver it by Saturday, and ask before the final total exceeds my limit.”
The shopper expects a finished order. They do not want eight tabs, three nearly identical products, and a promo code that fails at the last step.
For an AI shopping agent, this is a route: interpret the request, find a product, verify stock, calculate delivery, obtain permission to pay, place the order, and report what happens next. For the retailer, it is a live test of the entire commerce stack. Catalog, ERP or WMS, pricing, checkout, payment, and order management all have to agree.
Hi, I’m Anton Fokin, CEO of Qtim. Here is how we assess whether an e-commerce system is ready for an agentic sales channel, and why choosing the model comes later than getting one order path under control.
Five numbers decide whether the channel is worth keeping
A working API proves that an order can pass through the integration. It says little about whether the channel pays for itself.
We would track five lines during a pilot:
- Channel cost. Record the platform fee, payment processing, and any channel-specific service cost for the exact checkout model.
- Checkout conversion. Use all orders handed to checkout as the denominator, including failures and abandoned attempts.
- Contribution margin. Subtract channel costs, payment fees, returns, and support. More orders can still produce less profit.
- Average order value and attachment rate. An agent controls which products and accessories appear together, so compare both order value and the share of baskets with add-on items.
- Reachable customer share. Confirm what attribution and contact data the platform passes, and what the retailer may lawfully use in CRM or loyalty programs.
The five lines belong together. A clean transaction log is a technical result. Channel economics depend on the full set.
Attributes become the shelf
A person can open a product page and infer that graphite looks close enough to black. They can notice that size M is gone while size L is available at a nearby store. An agent needs explicit entities: product, purchasable variant, color, size, material, price, location, and fulfillment options.
The UCP catalog specification separates a product from the variant that can actually be bought. Each variant carries its own identifier, price, and availability; checkout refers to that same identifier. This prevents a familiar class of errors: the agent recommends one jacket and adds a namesake in a different size.
Marketing copy and images still shape demand. Inside an agentic flow, however, visibility depends heavily on fields that software can compare. “A deep, refined shade for confident looks” may help a person imagine the item. An agent needs a color code, material, fur policy, available sizes, and delivery constraints.
The practical rule is simple: let the language model interpret intent, then bind the final choice to stable IDs and explicit rules.
Available: true expires at delivery lookup
Inventory is rarely one number. There is physical stock, sellable stock after reservations, display units, returns awaiting inspection, and items sitting in other carts. Delivery adds another condition: the item may exist in one warehouse and still miss Saturday in the shopper’s region.
The agent needs more than available: true. It needs the exact variant, fulfillment area, delivery method, promised window, and the moment when that answer expires.
A catalog response helps the agent find a candidate. Checkout must recalculate availability and return the state the retailer is prepared to honor. Any reservation needs a time to live, a release reason, and a link to the checkout session.
Without that, two agents can buy the last pair of shoes. The warehouse has one box; the software has made two promises.
One price service, or four versions of the truth
The agent sees a catalog price. The shopper then adds an address, selects delivery, applies a promo code, and signs into a loyalty account. Region, tax, shipping, discounts, basket composition, and campaign timing can all change the total.
The stack needs one authoritative pricing service that returns each component and the final amount. Currency should be explicit, and monetary values should use integer minor units so 179.90 never becomes 17,990 through an imaginative reading of amount.
Checkout must return an updated state after every change. When the total crosses the shopper’s approved limit, the agent stops and asks. When inventory disappears, it offers an allowed substitute or cancels the session. Any new total requires fresh confirmation.
Parallel calculators are especially risky. The website uses one discount service, the mobile app uses another, a marketplace receives a nightly export, and the new agent gets a fourth formula. The agentic channel will expose every disagreement. Give it the same pricing source that supports your primary checkout.
Payment authority needs a limit
“Let the agent pay” sounds convenient until the merchant asks who authorized this amount for this seller.
Agentic payment mechanisms replace broad access to card details with scoped authority. Stripe’s Shared Payment Tokens, currently documented as a private-preview capability, can limit a token to a seller, amount, currency, and expiry window without exposing the original credentials.
The merchant must also recognize the agent. Visa’s Trusted Agent Protocol describes signed data that can help a seller verify an approved agent, its relationship to the consumer, and the payment container. This is how the retailer separates an authorized shopping agent from ordinary automated traffic.
We treat autonomous payment as a late-stage capability. First define the seller, category, amount, expiry, substitution rules, and events that return control to the shopper. A first transaction, changed price, high-value order, or non-refundable item may require explicit confirmation. Store the mandate and applied rules with the order so the authorization remains auditable.
A retry must return the first order, not create a second
Agents retry requests. The network drops after payment, the response arrives late, or the client cannot tell whether the order exists. For a programmatic customer, this is normal behavior.
Operations with consequences need idempotency. The agent sends a unique key; a repeated call returns the original result instead of charging the buyer again and creating another order. The current ACP checkout specification requires an idempotency key for creating, updating, completing, and cancelling a checkout session.
We also model checkout as a state machine: collecting information, waiting for input, ready to complete, awaiting confirmation, completed, or cancelled. The server validates transitions. The agent cannot jump from product selection to payment while the address is invalid or the final amount is unconfirmed.
Logs need to connect the user, agent, mandate, checkout session, order, and payment. Then “I approved 180; why was I charged 214?” becomes a traceable event chain instead of a long meeting.
The order survives checkout
A successful payment is the middle of the customer journey. The order may split across warehouses, fail inspection, move to a pickup point, arrive by courier, or enter a return flow. The shopper will ask the same agent, “Where is it?” and later, “How do I return this size?”
The retailer needs an order-lifecycle API with a stable ID, line items, statuses, tracking, documents, and cancellation and return rules. Events can arrive asynchronously, but the current state must always be retrievable. The agent can explain a status in natural language; the source of truth remains the order, warehouse, payment, or carrier system.
Support stays in the merchant’s operating model too. The contract should say what the agent may cancel, when it must ask for confirmation, and when it hands the conversation to a person with the full context attached.
Six backend contracts turn readiness into a test
When we scope a pilot, we walk through one order and test six boundaries:
- Catalog. Stable IDs for products and purchasable variants, structured attributes, restrictions, and links to sales policies.
- Availability. Checks by variant, location, region, and fulfillment method, plus a fresh validation and time-limited reservation.
- Pricing. One calculation for items, discounts, delivery, and tax, with an authoritative total after every change.
- Authority and payment. Agent recognition, customer consent, and a scoped payment instrument that never exposes the original credentials.
- Order. Idempotent requests, explicit checkout and order states, and an auditable trail for every consequential action.
- Aftercare. Status, permitted cancellation or return, and a handoff to a person with the relevant context.
The large language model sits on top of these contracts. It should not become a substitute source for stock, price, permission, or order status.
Top comments (0)