Ask a shop owner what agentic commerce means and you will usually get one of two answers. Either it is a wave of robot shoppers about to arrive, or it is a phrase invented to sell conference tickets. Both answers skip the only part that matters, which is that two large groups of companies have spent the last two years writing down, in public and in some detail, how a purchase is supposed to work when the buyer is a piece of software.
Those documents are readable. They also disagree about very little, which makes the shape of the thing unusually easy to see well before it arrives at your door.
- Agentic commerce is not one company's feature. It is two open specifications, one maintained by OpenAI and Stripe, one led by Google, both published and both readable today.
- The merchant side of the work is smaller than the phrase suggests. It is a structured product feed, a checkout an agent can call, and webhooks that report what happened.
- The genuinely new idea is cryptographic proof of consent. A signed record says what the shopper asked for and what they approved, which is the answer to the question every disputed order eventually asks.
- Nothing in either specification moves fulfilment, refunds or liability away from you. Agents change how the order arrives, not who owns it afterwards.
- Product data quality stops being a marketing concern and becomes the thing that decides whether you are eligible to be bought from at all.
- The cheapest preparation is work you already owe your human customers, which is why it is worth doing before the traffic justifies it.
What is agentic commerce, exactly?
It is a set of rules for letting software complete a purchase on a person's behalf, with enough structure that the merchant can tell what was authorised. The word covers a shopper telling an assistant to reorder coffee, and it covers a procurement agent buying parts against a budget, and the mechanics underneath are the same in both cases.
The clearest statement of the merchant side sits in Stripe's documentation for the Agentic Commerce Protocol, which describes ACP as an open standard created by Stripe, OpenAI and Meta defining how AI agents interact with businesses to complete purchases for buyers. The specification itself is maintained by OpenAI and Stripe, published in a public repository under the Apache 2.0 licence, with the current stable version dated 17 April 2026 and marked beta.
What that specification actually standardises is worth listing, because it is far more mundane than the marketing around it. Agentic checkout, meaning sessions you can create, update and complete with cart management and fulfilment options. Cart and feed, so an agent can read your catalogue before it buys. Delegated payment, passing a token securely between buyer, agent and business. Delegated authentication over OAuth 2.0. Orders and webhooks for confirmation, shipping, delivery and refunds.
Read that list again as a shop owner and the shape becomes obvious. Four of those five are things you already have in some form. The one that is genuinely new is delegation, and delegation is where all the interesting questions live.
Who agreed to what, and how is that proved?
By a signed record created before the money moves, and this is the part of agentic commerce that is genuinely new rather than a rearrangement of existing plumbing. It exists because the old proof of consent stops working the moment a human is not the one clicking.
Google's protocol is built around that gap. Its announcement of the Agent Payments Protocol, dated 16 September 2025 and made with more than sixty collaborating organisations including Mastercard, PayPal, American Express, Adyen, Worldpay and Etsy, names the three questions the protocol sets out to answer. Authorisation: proving the user gave the agent authority for this particular purchase. Authenticity: letting a merchant be sure the agent's request reflects what the user actually wanted. Accountability: deciding who is answerable when a transaction turns out to be wrong or fraudulent.
Its mechanism is what the announcement calls mandates, described as tamper proof, cryptographically signed digital contracts that act as verifiable proof of a user's instructions, signed by verifiable credentials. The Intent Mandate captures the original request and, for a delegated task, the rules of engagement including price limits and timing. The Cart Mandate comes later, once the agent has assembled specific items, and creates an unchangeable record of the exact items and price.
You will see this described in a lot of coverage as three mandates, with a payment mandate as the third. Google's own announcement centres on the intent and cart records, with the payment step binding to the contents of the cart mandate. If you are writing an integration against this, read the specification rather than the summaries, because the count varies with who is doing the summarising.
The practical value of a signed cart is easy to underrate until you have argued one. A shopper who says the agent bought the wrong thing is making a claim that a cart mandate either supports or refutes, in a record neither of you can edit after the fact. That is a better position than any merchant currently occupies in a disputed phone order.
Two protocols, one problem
They are not competing for the same slot, which is the most common misreading. One describes the shopfront and the checkout. The other describes the consent and the payment authorisation. A purchase can involve both, though the in chat purchase step was withdrawn in March 2026 and the assistants now compete on discovery rather than checkout.
| Agentic Commerce Protocol | Agent Payments Protocol | |
|---|---|---|
| Maintained by | OpenAI and Stripe, created with Meta | Google, with more than sixty collaborating organisations |
| What it standardises | Feed, cart, checkout session, delegated payment, orders and webhooks | Signed mandates proving what the user authorised |
| The question it answers | How does an agent transact with this business | Who agreed to this, and can it be proved later |
| Published form | Apache 2.0 repository, spec dated 17 April 2026, beta | Announced 16 September 2025, verifiable credential based |
| Where a merchant meets it | Directly, in the feed and the checkout endpoints | Mostly through the payment provider |
The asymmetry in the last row is the one to plan around. ACP asks you to expose things. AP2 mostly asks your payment provider to support things. For a one person business that difference decides how much of this is your work at all, and the honest answer is that most of the cryptography is somebody else's problem.
What actually has to change on your side?
Your product data, first and by a wide margin, and it is the part with a return whether or not a single agent ever calls. Everything else on the list is plumbing that a platform or a payment provider will eventually hand you.
An agent cannot infer what you did not write down. A human shopper looking at a photograph can see that a jacket is waxed cotton and guess the fit from a model shot. An agent reading a feed sees the fields you filled in and nothing else. Missing dimensions, absent materials, no compatibility field, a size guide that lives only in an image: each of these is invisible to a buyer that reads structured data, and the result is not a worse ranking but exclusion from consideration.
This is the same finding that turned up when we looked at how AI shoppers convert better while product pages lag behind them. The work that makes a page legible to a machine is the work that makes it honest for a person, which is why it is the one item here worth doing this quarter regardless of your view on agents.
The second change is a checkout an agent can call without a browser. If you are on a hosted platform this will arrive as a setting rather than a project. If you built your own, it is an API surface that creates a session, accepts updates and completes against a delegated token. Merchants who run a store whose code and endpoints they control outright have the simpler path here, because exposing a second checkout route is a decision rather than a support request.
The third is webhooks that tell the truth about order state, including refunds. Agent driven orders produce a customer who is not watching your emails, so the order lifecycle has to be readable programmatically or the agent has no way to report back.
What does an agent actually see when it reads your shop?
A list of fields, and nothing you did not put in one. That sentence sounds obvious and it is the single most expensive misunderstanding in this subject, because almost every shop believes its product pages say more than they do.
Take a real example. A shop sells a cast iron skillet. The page carries a good photograph, a paragraph of warm copy about seasoning, a price and a buy button. A human reads that page and knows almost everything: they can see the shape, judge the size against the hand in the photo, and infer that cast iron works on induction because they know what cast iron is.
An agent asked to find an induction compatible skillet under sixty pounds with a handle shorter than twenty centimetres reads the feed instead. If the feed carries title, price, image and description, the agent knows the price. It does not know the diameter, the handle length, the weight or the induction compatibility, because none of those is a field. The skillet is not ranked poorly against its competitors. It is not a candidate.
This is why the preparation work is worth doing on the merits rather than on the forecast. The same missing fields already cost you filtered searches on marketplaces, comparison placements, and the ability to answer a customer question without opening the supplier's PDF. Agents do not create the gap. They just make it decisive, because a machine cannot squint at a photograph and guess.
There is a second thing an agent sees that merchants rarely think about, which is inconsistency. If the description says the pan is thirty centimetres and the dimensions field says twenty eight, a person notices neither and an agent has to pick one. Feeds that disagree with page copy produce orders that disagree with expectations, and the resulting return is filed against you rather than against the discrepancy. Reconciling the two is unglamorous work that pays for itself the first time it prevents a wrong size shipping.
The practical test costs nothing. Take your three best selling products and write down the five questions a careful buyer asks before purchase. Then open your own feed export and check whether each answer exists as a field. Most shops find that two or three of the five live only in prose, in an image, or in the owner's head. Those are the fields to fill, in that order, and the exercise is finished long before you have touched the rest of the catalogue.
Who eats the chargeback?
You do, and no part of either specification changes that. This is the single most important sentence for a small seller in this entire subject, and it is consistently lost in coverage that treats agentic commerce as a transfer of responsibility.
Read what the protocols actually do. ACP standardises how an order is placed and how its lifecycle is reported. AP2 standardises proof of what was authorised. Neither takes on fulfilment. Neither takes on returns. Neither becomes the merchant of record in your place, and neither absorbs a dispute. You are still the seller, with the same obligations to the same consumer protection rules you had last year.
What does change, and change in your favour, is the quality of the evidence. A disputed agent order can carry a signed intent record with a price limit and a signed cart with exact contents. Compare that to the evidence in an ordinary card dispute today and the improvement is substantial. The protocols do not move the liability. They give you a much better hand when you have to defend against it.
There is a legal thread running alongside this that is worth following, since the question of whether an agent may transact on a site at all has already reached a court. We covered that decision in our piece on what it means when a court says an agent can shop on your site, and the direction of travel there is consistent with the direction here.
How much of this is real today?
Very little of your revenue, and that is the correct baseline to plan from rather than a reason to ignore it. Anyone quoting you a large share of agent driven sales today is describing a projection rather than a measurement.
We looked at the measured side of this separately, and the finding was that agentic shopping accounted for under one percent of one large marketplace's traffic. That is the honest current picture: a real channel, growing, and nowhere near a material line in a small shop's accounts.
The reason to prepare anyway is the shape of the cost. Almost everything on the preparation list is work with an independent payoff. Structured product data helps human search, ordinary conversion and your own internal reporting. A clean order lifecycle helps support. Better dispute evidence helps you today. There is very little in the list that only pays off if agents arrive, which is an unusual property for a technology bet and the reason this one is worth taking early.
What would justify moving faster is a change in where your customers start. If a meaningful share of your enquiries already begin inside an assistant rather than a search engine, the feed work stops being preparation and becomes current business. That threshold is measurable in your own analytics and it is the number worth watching, rather than any industry projection.
What should you do now, and what can wait?
Three things now, and everything else later. The order matters because the first item is the prerequisite for all the rest and the only one nobody can do for you.
Now: complete the fields that decide eligibility. For your top selling products, fill in every attribute a buyer might filter or compare on. Dimensions, materials, compatibility, power requirements, allergens, delivery windows. Not prose describing them, actual fields. If you can only do one thing from this article, do this one, and do it for your best sellers rather than your whole catalogue.
Now: make your order states machine readable. Confirmed, shipped, delivered, refunded, each with a timestamp and each reachable without a person reading an inbox. Most platforms already do this and most shops have never checked whether theirs is accurate.
Now: ask your payment provider one question. Whether they support delegated payment tokens and signed mandates, and on what timetable. The answer tells you how much of the second half of this is already handled, and it is a five minute email.
Later: the checkout endpoints themselves. Unless you are large enough to be approached directly, this will arrive through your platform. Building it speculatively against a beta specification is the definition of premature work.
Later: anything involving your own agent. Buying agents and selling agents are different problems, and the security questions that come with letting software act on your account deserve their own treatment. We started that in our look at what happened when an agent was told to book a class and cancelled a stranger.
What this actually is
Strip the vocabulary away and agentic commerce is a machine readable shopfront plus a signed receipt for consent. The shopfront half is catalogue hygiene you already owed somebody. The consent half is a genuine improvement on the evidence you currently hold, delivered mostly by your payment provider rather than by you.
What it is not is a change in who is responsible for the order. That stays exactly where it was, which is with the person whose name is on the shop. Any account of this subject that leaves you with a different impression is worth re-reading with that question in mind, because it is the question every dispute, refund and complaint will eventually come back to.