Agentic commerce

What is agentic commerce?

Agentic commerce is buying and selling where an agent does the buying for a customer. Someone tells an assistant "reorder the same floor cleaner as last month, but only if it is still under forty euro", and the assistant finds the product, checks the price and places the order. You get a sale and you never speak to the person paying for it.

Two neighbouring entries cover what sits around this one. The agentic web entry is about your site and the machine visitors arriving on it. Generative engine optimisation is about being named inside an AI answer. This entry starts one step later, where money has to move, and stays on the commerce and payment mechanics.

Most of it is early. The specifications are real, published and mostly open source, the card networks have programmes running, and the live consumer checkout flows are nearly all American. A merchant in Belgium can read every specification today and still find that the payment leg is a preview feature.

The three things that have to work before an agent can buy

The agent has to see the product, the price and the availability without a human browser session. The facts have to be retrievable as text, through a feed, or through an API. A price that appears only after a click, or availability drawn as a coloured icon, is invisible to the thing holding your customer's money.

You have to be able to tell that this agent acts for a real, identifiable customer who authorised this purchase. Two questions hide in that sentence. Which agent is this, and is it what it claims to be. And on whose authority is it acting, for what, up to how much. A signature answers the first, a mandate the second. Delegated authorisation for agents covers mandates in general; here they decide whether you ship the goods.

The payment has to clear under rules written for a person standing at a checkout. In Europe that is strong customer authentication under PSD2: two independent factors, in practice a notification the customer approves in their banking app. An agent cannot receive that notification, and you would not want a system where it could.

Every protocol below is an attempt at one, two or all three. Read them that way and the differences get clearer than a feature table makes them.

The protocols, and what each one specifies

The Agentic Commerce Protocol (ACP), from OpenAI and Stripe on 29 September 2025 under the Apache 2.0 licence, covers the checkout and the payment handover. A merchant implements five REST endpoints to create, update, complete, cancel and read a session, calculates tax and shipping itself, and publishes order webhooks. You stay merchant of record with your own payment provider. Its delegated payment is single use, carrying a maximum amount, a currency, an expiry and the merchant it is meant for, and it goes to your payment provider rather than to you.

The Agent Payments Protocol (AP2), from Google on 16 September 2025, answers the authorisation question instead. It carries signed verifiable credentials, called mandates, which record what the customer approved. The naming has moved with the specification, from an intent mandate plus a cart mandate at first release to checkout mandates and payment mandates now, and the idea underneath has not: a signed record you can hold up against what the agent actually asked you for. Standardisation moved into the FIDO Alliance's working groups on agentic authentication and payments.

The Universal Commerce Protocol (UCP) is the broadest and newest. Google announced it on 11 January 2026, co-developed with Shopify, Etsy, Wayfair, Target and Walmart and endorsed by more than twenty others including Adyen, Mastercard, Stripe, Visa and Zalando. It defines cart, checkout, order and identity linking over OAuth 2.0, moves payment credentials as opaque tokens, and treats AP2 as an optional extension where you want proof of what the customer approved.

The card networks answer the identity question at your front door. Visa's Trusted Agent Protocol and Mastercard's Agent Pay let an agent sign its requests, so your server fetches its public key from a directory the network hosts and checks the signature. Visa's version flags whether a request intends to browse or to pay. Underneath is Web Bot Auth, the signing scheme described in the agentic web entry, pointed at a payment.

Adoption is the part that gets left off the slide. ACP launched with Etsy sellers in the United States. UCP checkout went live for eligible United States retailers inside Google's AI Mode, with global expansion promised rather than dated. Stripe's shared payment tokens, the mechanism that carries a scoped card credential, do reach European countries including Belgium, but under preview terms and a preview version of the API.

What Europe's payment rules say when an agent presses the button

No European regulator has published guidance written for agentic payments. What exists is the ordinary rulebook and lawyers reading it. The firm Osborne Clarke wrote in March 2026 that agent-based payment models stay subject to PSD2 and its authentication standards with no separate regime, and that three questions are open: who is actually providing the payment service, who controls the customer's funds, and what counts as valid authorisation when the work is handed to an agent.

The mechanism that already exists, and that agent purchases lean on, is the merchant-initiated transaction. Stripe's documentation for the EEA is plain about it: payments on a saved card where the customer is not present in the checkout may qualify as merchant-initiated transactions, and those technically fall outside the scope of strong customer authentication. You authenticate the card once, when it is being saved, and you need the customer's agreement, a mandate, to charge it later. Then comes the sentence that matters commercially. Neither a customer challenge nor a liability shift occurs. Whether an agent's purchase counts as merchant-initiated in the first place is one of the questions nobody has ruled on.

The rewrite under way does not change that shape. PSD3 and the Payment Services Regulation reached provisional political agreement on 27 November 2025, but in September 2026 the texts were still waiting on publication in the Official Journal, and the rules apply more than a year after that. As the agreed text stands, authentication remains two independent factors, merchant-initiated transactions keep theirs at mandate setup rather than per payment, and authentication carried out by another party counts as outsourcing with the payment provider still liable. Nothing in it names an AI agent.

An agent buying on a stored authorisation versus a person confirming a payment

Compare them on one dimension: who proves the purchase was wanted. When a person pays, the proof arrives with the payment. The challenge lands in their banking app, they approve it, and if the payment turns out to be fraudulent the liability generally moves to the card issuer.

When an agent pays on a stored authorisation, the proof was produced once, earlier, when the card was saved and the mandate agreed. At the moment of purchase there is no challenge and no liability shift, so a disputed charge lands on you. The customer's evidence is a mandate from weeks ago; yours is whatever you wrote down about what the agent asked for and what you quoted back. That is why AP2 defines mandate formats at all.

An agent buying from a Belgian webshop, step by step

A webshop near Antwerp sells cleaning supplies to small businesses, with prices and stock as text, a product feed and a payment provider that supports agent-initiated payments. A customer's assistant is told to reorder ten litres of floor cleaner if it is still under forty euro. Here is where each step breaks.

1. Reading the catalogue. The feed says 38 euro and the page says 42, because the feed is rebuilt overnight and the price moved this morning. The agent commits to the stale number.

2. Identifying itself. It signs the request, and you cannot check the signature because nobody connected the network's key directory. Unsigned, it is just another scraper to your bot protection.

3. Opening a checkout session. You return the correct line price, but the customer's mandate was capped at forty euro and shipping plus VAT push the total over it. Both sides are right and there is no sale.

4. Presenting the payment credential. The token is scoped to one merchant, one amount and one expiry, and the basket was built twenty minutes ago. An expired grant and a revoked one both get refused, and your error handling has to say which.

5. Submitting the payment. The issuer asks for authentication anyway. The ACP checkout specification has an error code for exactly this, requires_3ds, and no guidance on what happens next. The workable answer is a link back to the human, so build that path first.

6. Confirming and, later, complaining. The confirmation goes to an address the agent created, and six weeks on the customer says the agent ordered the wrong concentration. You have a mandate, an order and no conversation to point at.

Only step five is a rule you must obey. The rest are decisions about your data quality, your error handling and what you write down.

What to watch out for with agentic commerce

A dispute arrives with no conversation behind it. No browsing you can see, no call with your sales desk, no moment where the customer clicked to confirm. The ordinary evidence a returns discussion rests on is simply not there, and a mandate agreed weeks ago is what has to replace it.

Comparison runs at machine speed. A person checks two competitors, an agent checks forty every time and notices a price change within the hour. If part of your margin rests on customers not bothering to look, agent traffic removes it.

Agent orders and promotions are a decision, not a default. A welcome discount buys a relationship, and a first order placed by an assistant may not create one. If the assistant remembers the supplier and reorders, that relationship lives in its memory rather than on your mailing list, so accurate stock and delivery dates you keep gain commercial weight and your newsletter loses some.

What to do now, in order

1. Make your product data machine-readable and, above all, correct. Price with the VAT treatment spelled out, stock, delivery time, minimum order quantity and return window, as text on the page and identical in any feed you publish. Those last three rarely make it into structured data, and they are exactly what an agent otherwise has to guess.

2. Decide deliberately whether agents may buy from you. Browsing and buying are separate permissions, and Visa's protocol carries a flag precisely so you can treat them separately. Decide per product group and per order value, then put the answer in your terms, because a customer whose agent was refused at checkout will ask you why.

3. Ask your platform and your payment provider two questions in writing. Which agent protocols do you support today in Belgium, and what happens to my liability on an agent-initiated payment. The second one gets a vague answer, which is itself information.

4. Decide now what you keep when an agent orders. The mandate or token reference, the price you quoted back, the exact basket, and the moment the agent accepted it. Who is arriving on your site is a separate question, covered in the agentic web entry. This is the commercial record that decides who pays for a returned pallet.

The same question from your buying side

An agent that reorders your own supplies is this problem seen from the other end, and it is where most small companies meet it first, because you hold both the decision and the budget. The three questions turn around neatly. Can it read your supplier's prices, or is it guessing from an old quote. Does it act under an identity of its own with a spending limit and an end date, or does it use somebody's login. And when an invoice arrives for something nobody wanted, can you show what the agent was told to do. Start with one dull category, put a cap on it, and read every order for a month.