In short
Agentic Commerce Protocol (ACP) is an open standard that lets AI agents such as ChatGPT find a merchant's products, put them in the basket and pay on the user's behalf. It was developed by OpenAI and Stripe and presented on 29 September 2025 together with the "Instant Checkout" feature in ChatGPT.
The specification is licensed under Apache 2.0 and published at agenticcommerce.dev.
At the core of the protocol is a clear division of roles: the agent conducts the conversation with the buyer, while the merchant remains the seller, contracting party and merchant of record. The payment service provider hands over a delegated means of payment without card details ending up with the agent. This entry explains the three sub-specifications, shows how the protocol has developed since its launch and positions it against the competing standard UCP. It belongs to the topic of agentic commerce.
Why agent shopping needs a protocol
A language model can recommend products today, but it cannot simply complete a purchase. To do so, it would have to know which variants a merchant carries, whether they are available, how shipping and taxes are calculated and how payment works. Every shop solves this differently. Without a common language, the agent would have to learn a separate connection for every merchant, and the merchant would have to trust every agent that triggers orders.
ACP answers both problems with a fixed contract between the parties. The merchant describes its range in a product feed, provides a small REST API for checkout sessions and accepts payments via a delegated token. The agent knows this schema and can therefore work in the same way with every connected merchant. The model is deliberately kept lean so that existing shop systems can implement it without rebuilding their checkout.
The roles involved
- Buyer: the user who describes in the chat what they are looking for and confirms the purchase.
- Agent: the AI application, such as ChatGPT, that shows products, opens a checkout session with the merchant and initiates payment.
- Merchant: the shop that provides the feed and checkout endpoints, fulfils the order and, as merchant of record, bears responsibility for the contract, shipping and returns.
- Payment service provider: the payment service provider that holds the buyer's means of payment and hands the merchant a single-use token.
The three sub-specifications of ACP
ACP is not a monolithic standard but a bundle of three specifications that can be read and implemented independently of each other. The first describes data, the second processes, the third payments. Anyone who only wants to be visible in the chat needs only the first. Anyone who wants to handle purchases directly via the agent needs all three.
Product Feed Spec: the range for agents
The product feed is a single file in which each line describes one product. Only the product id and a variants array, whose entries each carry an id and a title, are mandatory. Everything else, including price and availability, is optional. That sounds sparse, but there is a reason for it: the feed is meant to secure findability first. The more fields a merchant fills in, the better the agent can recommend, compare and correctly reflect availability.
For Shopware merchants there is already a tool for this. The Shopware extension "Agentic Commerce" generates the OpenAI product feed as a JSONL file directly from the shop. It is available free of charge as a beta; version 1.4.0 dates from 2 October 2026 and supports Shopware 6.5.8 to 6.7.15. This removes the need to build an exporter yourself, and changes to prices or stock reach the agent via the regular feed run.
Agentic Checkout Spec: five endpoints for the purchase
The checkout is a REST interface with API version 2025-09-12 that the merchant provides and the agent calls. The full reference is in OpenAI's checkout specification. The model follows a checkout session that is opened, updated, completed or cancelled.
| Method and path | Purpose |
|---|---|
POST /checkout_sessions | Opens a session with the desired items; the merchant responds with prices, shipping options and status. |
POST /checkout_sessions/{id} | Updates the session, for example after a change of address, quantity or shipping method. |
POST /checkout_sessions/{id}/complete | Completes the purchase with the delegated means of payment; the merchant creates the order. |
POST /checkout_sessions/{id}/cancel | Cancels the session. |
GET /checkout_sessions/{id} | Reads the current state of the session. |
Every request carries a fixed set of HTTP headers: Authorization for authentication, Idempotency-Key so that repeated calls do not create duplicate orders, Request-Id for tracing, and Signature and Timestamp in RFC 3339 format, with which the merchant checks the origin and freshness of the request. After completion, the merchant reports status changes back to the agent via the webhooks order.created and order.updated.
Important in practice: the merchant remains the merchant of record. The order is created in its system, with its terms and conditions, its invoice and its customer service. Technically, the agent is just another channel, like a marketplace connector or an app, except that the purchase dialogue takes place in natural language.
Delegated Payment Spec: paying without card data at the agent
The third specification solves the trickiest problem. The buyer has stored their payment details with the agent, but the merchant is to receive the money without the agent acting as payee. For this, the payment service provider generates a delegated token; at Stripe it is called a shared payment token. It is bound to the amount, merchant and transaction and is passed in the call to /complete. The merchant charges it via its existing PSP connection.
Stripe was co-author and first implementer, but the spec is not limited to Stripe. Other payment service providers can implement it; OpenAI names Adyen and Braintree, among others. For merchants, this means that in the long term they do not have to switch their existing PSP, provided the provider implements the specification.
Practical example: Instant Checkout in ChatGPT
The first and best-known product based on ACP is "Instant Checkout", which OpenAI presented on 29 September 2025 under the title "Buy it in ChatGPT". At launch, US users of ChatGPT could buy products from Etsy sellers directly in the chat. The agent opened the checkout session with the merchant, the user confirmed address and payment, and the order was completed via Stripe. The launch was explicitly limited to the USA.
On 28 October 2025, PayPal followed as a payment partner. This meant that a second major provider stood behind the delegated payment model alongside Stripe. More merchants were added in the following months; the basic principle remained the same: discovery in the chat, purchase in the chat, fulfilment at the merchant.
The change of course in March 2026
In March 2026, OpenAI changed direction. On the merchant page chatgpt.com/merchants, as of October 2026, it says literally: "We're moving away from a standalone Instant Checkout experience in ChatGPT and prioritizing better shopping discovery and merchant-owned checkout experiences." The standalone purchase in the chat is thus taking a back seat; the focus is on findability and a checkout that the merchant controls itself.
This can be seen in the Shopify integration, which has been running since March 2026: the user finds the product in ChatGPT, while the purchase itself takes place in the merchant's shop. The merchant page names further key points: no fees are charged on purchases that start in ChatGPT. Product feeds are the basis for visibility. Apps are optional and aimed at larger merchants. Shopping in ChatGPT is still only live for US users.
For the assessment of ACP this means: the feed specification is the part with the greatest reach today. The checkout and payment specs remain part of the open standard, but whether a purchase is completed in the chat or in the shop is currently decided by the agent operator and not by the protocol alone.
What ACP means for merchants and shop operators
The obvious question is whether a connection is worthwhile when shopping in ChatGPT is only available in the USA. The answer depends on which level you mean. The product feed is cheap to get, with Shopware even via a free extension, and it is the same data basis that other agents and search systems also evaluate. A clean feed with complete variants, prices and availability is therefore sensible preparation regardless of the current market launch.
The checkout connection is more complex. It requires a dedicated API layer in front of the shop, signature verification, idempotency and webhook processing. For a merchant on Shopware, this usually means a plugin that maps checkout sessions to baskets and creates a regular order on completion. Anyone who operates internationally and has US customers can use this today. For the DACH market it is an option for later, but its specification can already be read now.
Checklist for preparation
- Check product data: every variant needs a stable ID and a meaningful title. Prices and stock levels should be in the feed, even though they are optional.
- Generate the feed: with Shopware via the "Agentic Commerce" extension, otherwise via an export that delivers a JSONL file with one product per line.
- Create a merchant account: register the feed via chatgpt.com/merchants; only consider apps if the range or the processes justify it.
- Clarify the PSP: check whether your own payment service provider implements or plans to implement the Delegated Payment Spec.
- Prepare the checkout API: model the five endpoints and headers against your own basket and plan idempotency and signature verification early.
ACP, UCP and MCP: who does what?
Several abbreviations circulate around the topic that are easy to confuse. The Model Context Protocol (MCP) is a general standard through which language models address tools and data sources. It says nothing about baskets or payments. ACP sits one level higher and describes specifically how a purchase between agent, merchant and PSP takes place. A merchant can theoretically make its ACP endpoints reachable via MCP, but does not have to.
The direct competitor is the Universal Commerce Protocol (UCP), which Google and Shopify presented on 11 January 2026. UCP pursues a similar goal but takes a different approach to findability: merchants publish a manifest at /.well-known/ucp through which agents discover the shop's capabilities. ACP has no such manifest but works with registered feeds and directly configured endpoints.
| Feature | ACP | UCP | MCP |
|---|---|---|---|
| Initiators | OpenAI, Stripe | Google, Shopify | Anthropic (open standard) |
| Presented | 29.09.2025 | 11.01.2026 | 2024 |
| Purpose | Purchasing by agents: feed, checkout, delegated payment | Purchasing by agents with a discovery manifest | Tool and data access for models |
| Discovery | Product feed, merchant registration | Manifest at /.well-known/ucp | Server declaration of tools |
| Licence | Apache 2.0 | open | open |
For merchants, the competition between standards is inconvenient but not new. With product feeds for price comparison sites and marketplaces, several formats have also coexisted. The lesson from this: anyone who maintains their product data cleanly and completely can serve any target format with manageable effort. The feed is the common basis, regardless of whether ACP or UCP ends up being more widespread.
Limits and open questions
A protocol regulates technology, not business. It remains open how agents select products, whether and when advertising or preferred placements come into play and how merchants keep their brand visible in the chat. With the change of course in March 2026, OpenAI has also shown that the product side rotates faster than the specification. Anyone building should therefore rely on the spec and not on a single feature.
Legally, ACP changes little, because the merchant remains the merchant of record. Information obligations, withdrawal and invoicing continue to run via the shop. It will be interesting to see how an agent reflects these obligations in the dialogue when the purchase takes place entirely in the chat. For the European market, this question only arises once shopping in ChatGPT is enabled outside the USA.
Technically, the design is solid: signed requests, idempotency keys and tokenised payments correspond to what you would expect from a modern payment API. The separation into three specifications makes it possible to start with the feed and add the checkout later. This order is exactly what OpenAI prioritises after the change of course.
Frequently asked questions
What is the difference between ACP and Instant Checkout?
ACP is the open standard; Instant Checkout was the first feature in ChatGPT built on it. Since March 2026, OpenAI has been moving away from standalone Instant Checkout and focusing on discovery plus checkout in the merchant's shop. The specification continues unchanged.
Do I have to use Stripe to use ACP?
No. Stripe co-developed the Delegated Payment Spec and implemented it as the shared payment token, but other payment service providers can also implement the specification. OpenAI names Adyen and Braintree, among others. PayPal has supported agent checkout since 28 October 2025.
Can customers from Germany buy from me via ChatGPT?
Not at present. According to the merchant page, shopping in ChatGPT is only live for US users. Merchants from Europe can still prepare and register their product feed so that they are ready for a later launch.
What does connecting to ChatGPT cost?
According to chatgpt.com/merchants, no fees are charged on purchases that start in ChatGPT. Costs arise from your own implementation: feed generation, possibly a checkout API and the usual fees of the payment service provider. For Shopware, the feed extension is free of charge.
How does ACP relate to UCP?
Both standards aim to enable agents to shop. ACP comes from OpenAI and Stripe, UCP from Google and Shopify. UCP uses a manifest at /.well-known/ucp for discovery, ACP registered product feeds and direct endpoints. Well-maintained product data is the common basis for both.