Agentic commerce / How it works

Test environments only

Agentic commerce lets you buy inside a chat

Instead of visiting a shop's website, you describe what you want to an AI assistant, it finds the product, and you pay in the conversation. Try it here first, then read how it works underneath.

Everything in this shop, three items

What changes for the shop

Almost nothing about the sale itself. The shop remains the merchant of record, keeps the customer relationship, and handles fulfilment, refunds and disputes as before. What changes is the shop window. Instead of a buyer arriving on a product page, the product is described to them by an assistant that read the shop's catalogue.

That has one consequence worth sitting with. If a product's description, images or stock levels are wrong in the catalogue, there is no page for the buyer to correct their impression on. The catalogue is the entire shop front.

How agentic commerce works with Stripe

Four parties are involved: the buyer, the AI assistant, Stripe sitting between the assistant and the shop, and the shop itself. The sequence below is how Stripe's Agentic Commerce Suite arranges it, which is what this site runs on. Another provider does the same job with different calls in a different order.

Buyer AI assistant (ChatGPT, Copilot) Stripe Shop Before anyone shops 1. Upload the product catalogue product feed 2. Catalogue import result imports.succeeded 3. Products reach the assistant Someone goes shopping 4. Asks for a navy t-shirt in medium 5. Look up the product 6. Check price and stock product_price_availability 7. Current price and stock 8. Shows the product and the price Buying inside the conversation 9. Confirms the purchase 10. Open a checkout 11. Ask for shipping and tax customize_checkout 12. Delivery options in the buyer's currency 13. Ask the shop to approve the order finalize_checkout 14. Approved, or declined with a reason 15. Charges the card 16. Confirms the order After the sale 17. Payment succeeded checkout.session.completed 18. Fulfil the order A request, answered within four seconds. A notification. No reply needed.

This is how it works on Stripe. Other payment providers arrange the same job differently, so treat the shape as a guide rather than a standard.

Before anyone shops

  1. The shop uploads its catalogue. A file listing everything it sells, with prices, stock levels and shipping destinations. It is an upload rather than a live connection, so it goes again whenever something changes.
  2. The provider reports back. If some rows had problems the valid ones still go live and the rejected ones come back as a separate list, which is worth checking because a partly loaded catalogue looks fine from the outside.
  3. The products reach the assistant. The catalogue goes to whichever assistants the shop agreed to sell through. From here its products can appear in conversations.

Someone goes shopping

  1. A buyer asks for something, describing it the way they would to a person rather than typing a search query.
  2. The assistant searches the catalogues it has access to and pulls out what fits.
  3. The provider checks with the shop. Before anything is shown it asks whether price and stock are still accurate, catching whatever changed since the last upload.
  4. The shop replies with current numbers. What it says here takes precedence over the catalogue.
  5. The buyer sees the product in the conversation, with image, price and delivery estimate.

Buying inside the conversation

  1. The buyer confirms. Everything after this happens without them leaving the chat.
  2. The assistant opens a checkout for that item.
  3. The provider asks about shipping and tax, giving the shop the chance to calculate both with its own logic rather than the values in the catalogue.
  4. The shop returns delivery options, priced in whatever currency the buyer is paying in.
  5. The provider asks the shop to approve. It sees the full basket, the delivery address and the card details, and has four seconds. No response is a refusal.
  6. The shop approves or declines. A decline carries a reason, and the reason reaches the buyer.
  7. The card is charged.
  8. The buyer gets a confirmation in the chat, where the whole thing started.

After the sale

  1. The shop is told the payment went through. Approving an order and the money arriving are two separate events, and the shop needs the second before acting on the first.
  2. The shop fulfils the order through whatever system already handles picking, packing and shipping. That part does not change.

What a shop has to provide

Two things are required and three are optional, and the split matters more than it looks.

Required: a catalogue, and pages that resolve

The catalogue is a file with a fixed set of columns. Some are obvious, like title, price and image. Others catch people out. Every product needs a link to a page that actually loads, even when the buyer never visits it, because the assistant links to it and may send people who want to look before deciding. Shipping destinations are listed one country at a time, and an address outside that list does not appear as a missing delivery option, it stops the checkout.

Products with variants, like a shirt in three sizes, are one row per size sharing a group id. The assistant presents them as one product with a size choice.

Optional: three endpoints that answer during a checkout

  • Live price and stock. Called before a product is shown, and proactively when stock is low. Its answer overrides the catalogue.
  • Shipping and tax. Called during checkout so the shop can calculate both with its own logic.
  • Order approval. Called last, with the full basket and the card details, so the shop can accept or refuse the sale.
The endpoints are not a replacement for good catalogue data. They sit on top of it. If one is switched off, times out or fails, the checkout continues using the catalogue, so a shop with thin catalogue data and clever endpoints has no floor under it.

The failure behaviour differs by endpoint, deliberately. If the price and stock endpoint does not answer in time, the checkout carries on with catalogue data. If the approval endpoint does not answer in time, the payment is declined. One fails towards completing the sale, the other away from it.

What the requests look like

These are the last calls this site received during real checkouts. Nothing here is composed for the page. Each one arrived while a buyer was waiting, and each got an answer inside four seconds. Open a row to read what was sent and what went back.

Worth being clear about where they come from: only a purchase made inside an AI assistant produces these. Buying through the panel at the top of this page is an ordinary Stripe Checkout session, so it goes straight through without Stripe ever asking this server anything.

Loading most recent first
Loading recent requests.

What it did to the stock

Stripe does not hold your stock, so nothing it does changes the number. A shop has to decrement on its own and tell Stripe the new level, through the feed and through the live availability request. Every movement below is one of those, written when the payment confirmation arrived rather than when the sale was approved, since those are two different events.

Loading
Loading stock movements.
Something the documentation does not mention. With both switched on, the shipping and tax request arrives a few seconds before the approval request, every time. It makes sense once you see it: the approval step is shown the shipping and tax totals, and those only exist once the earlier step has answered. This log is where that ordering became visible.

Common questions

Does the buyer visit the shop's website?

Not if the shop allows checkout inside the assistant. The product page still has to exist and be reachable, because the assistant links to it and may send buyers who want to look before deciding, but the purchase itself happens in the conversation. A shop can also choose the opposite, where the assistant surfaces the product and sends every buyer to the shop's own site to pay.

Who is the merchant of record?

The shop. The assistant is an intermediary that presents the product and collects payment details, but the sale, the customer relationship, the fulfilment and any refunds or disputes stay with the shop.

What happens if the shop's endpoint does not respond?

It depends which one. A timeout on the approval endpoint declines the payment, so a shop that cannot answer sells nothing. A timeout on the price and availability endpoint falls back to the catalogue and the checkout continues. The window is four seconds in both cases.

How is this different from a shopping feed for search?

A search feed exists to get someone to click through to a page. This one has to carry enough for a decision to be made without a page at all, and it has to be right at the moment of purchase rather than roughly right. That is why the live price and stock endpoint exists, and why stale stock levels are a checkout failure here rather than a mild annoyance.

Can a shop control which assistants sell its products?

Yes. The shop requests a connection to a specific assistant, the assistant has to accept, and either side can end it. Products do not appear anywhere the shop has not agreed to.

Questions, feedback, or just want to talk payments?

I'm always happy to hear from fellow payments people.

Connect on LinkedIn