About5 min read
What Is Agentic Commerce?
AI agents are starting to buy things on behalf of people. The Agentic Commerce Protocol is the open standard Stripe, OpenAI and Meta published for how that works. Here is what it actually specifies, and what it means if you run a store.
By Juan Molina

On this page
For as long as online stores have existed, the buyer has been a person with a browser. They land on a product page, they read it, they click a button, they type a card number. Every part of a storefront assumes that: the layout, the photography, the reviews, the upsell after the add to cart.
Agentic commerce is what happens when the buyer is a person but the thing doing the buying is software acting for them. You tell an assistant what you want. It finds it, puts it in a cart, and completes the purchase without you ever seeing the product page.
That sounds like a small change. It is not. If the shopper never renders your site, then your site is no longer the thing selling. Your data is.
A working definition
Agentic commerce is a transaction where an AI agent carries out the purchase on behalf of a buyer, and the merchant is dealing with the agent rather than with a browser session.
The important word is carries out. An assistant that recommends a kettle and then hands you a link is not agentic commerce. It is search with better manners. It becomes agentic commerce at the point the agent can select the item, apply the fulfilment options, present a payment credential and get back an order.
Which raises the obvious question. If an agent is going to do all of that, against thousands of different stores, what exactly is it talking to?
The Agentic Commerce Protocol
That question is what the Agentic Commerce Protocol exists to answer. ACP is an open standard for programmatic commerce flows between buyers, AI agents and businesses. It was created by Stripe, OpenAI and Meta, and it is released under the Apache 2.0 licence, so it is not a proprietary channel anybody has to be admitted to.
The specification is public. There is an open repository with OpenAPI specs and JSON Schema definitions, and Stripe keeps its own documentation of how the pieces fit. If you want the authoritative version of anything in this post, those are the two places to read.
ACP supports both REST and MCP integration patterns, and covers physical goods, digital goods, subscriptions and asynchronous purchases. Stripe was the first compatible payment service provider, through what it calls a Shared Payment Token, and ChatGPT was the first AI platform to implement the protocol.
What the protocol actually specifies
ACP is not one endpoint. It is a set of composable building blocks, and a merchant does not have to adopt all of them at once.
- Cart and feed. How an agent browses your catalog and builds a cart before any checkout exists.
- Agentic checkout. Creating, updating and completing a checkout session, including cart management, fulfilment options and payment.
- Delegate payment. Passing a payment credential securely between the buyer, the agent and the business, so the agent never handles a raw card number.
- Delegate authentication. OAuth 2.0 authorisation that lets an agent act on a buyer's behalf with a specific business.
- Orders and webhooks. Lifecycle updates back out: confirmation, shipping, delivery and refunds.
Read that list again and notice what it is. It is a headless storefront. Not a new kind of one, the same kind: a catalog you can query, a checkout you can drive from outside, a payment step that does not require a rendered form, and webhooks that tell you what happened. The agent is simply a client you did not write.
Why this favours stores that already have an API
Here is the practical consequence, and it is the reason this is worth paying attention to now rather than in two years.
A store whose product data only exists as rendered HTML has nothing to offer an agent. Everything it knows about its own catalog is tangled up with how that catalog is displayed. To participate it has to first separate the two, which is the expensive half of a replatform.
A store that already runs on an API has done that work. The catalog is already queryable, the checkout is already something code can drive, and the order lifecycle already emits events. Whether or not you adopt ACP specifically, that separation is the thing that determines how much work any of this is.
This is the same argument as one backend behind many storefronts. An agent is, from the backend's point of view, just another storefront. If adding a second front end to your business is currently a project rather than a key, adding an agent will be too.
What we do and do not support today
Being exact about this matters more than sounding ready.
dashfordevs does not implement ACP today. There is no agentic checkout endpoint in the API, and nothing on this site should be read as saying otherwise. If that changes it will show up in the documentation and on the roadmap before it shows up in a blog post.
What does exist is the substrate the protocol assumes. The catalog, orders, customers and payments sit behind one typed API with a documented REST surface underneath it. Checkout is something your code drives rather than a page we render for you, which is what makes state restrictions and payment routing decisions you control. Order lifecycle events are already available as webhooks.
None of that is ACP support. It is the difference between a store that would need rebuilding to participate and one that would need an adapter.
What to actually do about it
Nothing urgent, and be suspicious of anybody telling you otherwise. Agentic commerce is early, the spec is versioned and moving, and the number of buyers currently completing purchases this way is small.
Three things are worth doing anyway, because they are worth doing regardless of whether agents ever become a meaningful channel.
- Get your product data out of your templates. If the only complete description of a product is the page that displays it, that is a problem today for search, for feeds and for your own reporting.
- Know which of your systems can be driven by code. Not which have an integration, which have an API you could call yourself.
- Read the spec rather than the coverage. It is open, it is short enough to read in an afternoon, and most of what is written about it is written by people who have not.
The stores that will find this easy are not the ones that move first. They are the ones whose catalog and checkout were already separable, for reasons that had nothing to do with agents.














