Agentic Commerce Protocol (ACP): what it is and how it works

AI shopping is moving beyond recommendations. An agent can find a product, compare it with alternatives, and now complete the purchase as well. Instead of sending the customer to a retailer's website to check out, it can request the latest price and availability, get permission to use the customer's preferred payment method and place the order directly.

OpenAI and Stripe launched the Agentic Commerce Protocol (ACP) in September 2025 alongside Instant Checkout for selected US Etsy purchases. The protocol has since had four released revisions, most recently in April 2026, expanding beyond checkout to product feeds, carts, authentication and order updates. OpenAI’s current approach is discovery-first, although some eligible products and merchants may still offer Instant Checkout.

That raises a practical question: what does an agent need to move from recommending a product to placing a valid order? It needs accurate commercial information, a secure way to use the customer’s payment method and clear responsibility for fulfilment, returns and support. ACP defines how the agent, seller and payment provider handle those parts of the transaction while the seller remains merchant of record.

What is the Agentic Commerce Protocol?

The Agentic Commerce Protocol is an open standard that gives AI agents, sellers and payment providers a shared way to exchange the information required for a purchase. Instead of every agent needing a different checkout integration, ACP defines common objects, operations and status changes that participating systems can understand.

It has two core parts. Agentic Checkout handles the interaction between the agent and the retailer, allowing a checkout session to be created, updated and completed. Delegate Payment handles the payment side, allowing payment credentials to be tokenised and used within specific limits, such as the merchant, amount and period for which they are valid.

The specification has expanded since then. The April 2026 release added or formalised support for product feeds, carts, public discovery documents, delegated authentication, more detailed order updates and a Model Context Protocol (MCP) binding. It is open source under the Apache 2.0 licence and is still marked as beta in the official repository.

For a customer, most of this happens in the background. As the conversation progresses, the agent checks in with the retailer's systems to confirm what's actually in stock, see the delivery options and gather anything still needed to complete the order. The payment provider then handles the payment within the permissions the customer has given.

The retailer remains the merchant of record and continues to control the catalogue, stock, pricing, tax and fulfilment. The agent manages the conversation and helps move the purchase forward, and the payment provider stays responsible for protecting and processing the payment itself.

Why does agentic commerce need a protocol?

Without a shared protocol, a retailer would have to connect to every AI shopping agent separately. Each agent could ask for prices, stock, checkout and payment details in a different way, which means building and maintaining a new integration each time. It can also lead to errors. If an order request fails and is sent again, for example, the retailer needs a way to catch the duplicate before it's placed as a second order.

ACP gives retailers and AI agents a common way to handle these steps. The retailer remains in control of the price, stock and tax, while the agent uses the information the retailer provides. Payment access can also be limited to a specific purchase, amount and period of time, and repeated requests can be recognised and matched to the original.

Retailers still need their own product, checkout, payment and order systems. The difference is that they can connect those systems to AI agents through one common standard, rather than building a separate integration for every agent.

Who participates in an ACP transaction?

An ACP transaction has four participants, and the buyer holds the most authority at the start. Deciding what to buy, agreeing to the terms and authorising the payment are all the buyer's calls. The agent, the seller and the payment provider each act within limits the buyer or the retailer sets.

The price and delivery date the agent shows come directly from the seller. If either changes mid-conversation, the seller sends the update, and the agent passes it on to the buyer. Before the purchase can go through, the buyer has to approve the final details, and if the seller requires extra authentication, such as 3-D Secure, the buyer completes that step directly rather than the agent doing it on their behalf.

How does ACP work?

Say a customer asks an AI agent to find a pair of running shoes under £120 that JD Sports can deliver by Friday. Here's what actually happens between that request and the order arriving at the customer's door.

Finding the product and checking what's supported

The agent starts by searching JD Sports' catalogue data, made available specifically for this kind of discovery. Before going any further, it checks JD Sports' public discovery document, which lists which payment methods, authentication types and extras like discount codes the retailer actually supports. That check applies across the whole retailer, not just this one purchase.

Creating a checkout session

Once a pair is selected, the agent opens a checkout session with JD Sports. This time the negotiation happens at the session level. The agent states what it can handle, and JD Sports confirms which payment handlers and authentication methods will actually work for this order.

Getting the real price, stock and delivery details

JD Sports responds with the details that count: confirmed stock, the real price with any promotion applied, delivery options and their costs, and whatever information is still missing, such as a delivery address. If the customer changes the delivery method or adds a second pair, JD Sports recalculates the order instead of the agent estimating the difference.

Buyer review and payment authorisation

With everything confirmed, the buyer reviews the final total, the delivery terms and the return conditions, then authorises the purchase. The payment provider responds by creating payment tokens scoped tightly to this transaction, this merchant, this amount, this currency, and an expiry date, rather than open-ended access to the customer's card.

Completing the order

JD Sports validates the payment handler, processes the payment through its own provider, and accepts or declines the order accordingly. It stays the retailer of record either way, responsible for the order from that point on. Confirmation, dispatch, delivery updates and any later return continue to reach the customer through the same channel.

The checkout session states

A checkout session moves through a small, defined set of states from start to finish. It begins as “not_ready_for_payment”, becomes “ready_for_payment” once price, stock and delivery are all confirmed, and shifts to “in_progress” the moment the buyer authorises it. From there it settles as “completed” or “canceled”. Every request in this flow also carries an idempotency key, which means a network hiccup or a retried request still resolves to a single order.

What parts of commerce can ACP cover?

The walkthrough above covers one transaction end to end. This table breaks out the six layers ACP now covers, up from the two it launched with.

The practical question is which of these to prioritise first. If getting noticed in an AI agent's search results is the immediate goal, discovery and product feeds come first, and our guide on preparing product data for AI discovery goes into that in more depth. Checkout, negotiation and payment take priority once the goal shifts to letting an agent complete the purchase itself.

How do ACP payments and security work?

The payment token covers one layer of security. A few other controls sit around it to protect the request itself and handle things going wrong mid-purchase.

Protecting the request itself

Every request runs over HTTPS with bearer-token authentication, and carries a signature and a timestamp so it can't be captured and replayed later. Idempotency keys apply to payment requests too, so a retried authorisation resolves to a single charge rather than two.

When the price changes mid-purchase

If a price changes between when an agent last checked and when the buyer authorises the purchase, the seller returns the new figure and the buyer has to approve it again. The original payment authority stays capped at the amount it was issued for.

When extra authentication is required

If a seller requires extra authentication, such as 3-D Secure, for a particular payment, the checkout pauses and the buyer completes that step directly, rather than the agent attempting it on the buyer's behalf.

What implementation still has to get right

ACP defines these patterns as part of the specification. Whether they actually protect a transaction in practice depends on how the agent, the seller and the payment provider each implement and monitor them.

ACP vs UCP, AP2 and MCP

ACP is one of a few standards being developed around agentic commerce, and it is easy to mix up what each one is for.

• ACP covers discovery, checkout and payment for an AI-led purchase.

• UCP covers similar ground and is backed by Google, Shopify and a wider group of retailers and payment providers.

• AP2 provides cryptographic proof of what a buyer has authorised an agent to do, rather than covering the full purchase journey.

• MCP gives AI systems a standard way to connect to tools and data, rather than being built specifically for commerce.

Retailers do not have to pick one and build around it. Product, checkout, payment and order systems can be built to work with different protocols, giving them the flexibility to support more than one as adoption grows.

Benefits and limitations of ACP

Benefits

• Retailers can use one ACP integration with any agent that supports the protocol, instead of building a separate one for each agent.

• Payment permission can be limited to a single purchase.

• The seller stays in control of price, stock and tax.

• Built-in checks help prevent duplicate orders and make failed transactions easier to manage.

• Compatibility issues can be picked up before the customer gets to payment.

Limitations

• ACP is still new and has changed several times since it launched, so the specification is likely to keep evolving.

• It limits what an agent can do with a payment, but retailers still need their own checks for fraud, account takeover and authentication.

• It cannot fix poor product or inventory data. If the information in a retailer's systems is wrong, ACP will not fix it.

• Retailers still need to decide who handles customer service after an order is placed.

• ACP is not the only standard being developed. UCP, AP2 and other protocols are also in the market, and it is still unclear which ones will be widely adopted.

It is also too early to say how much ACP affects conversion or return rates, especially in the UK. Those results depend on several other factors, including the products being sold, how the agent works and how well ACP has been implemented.

What should UK retailers prepare for ACP?

Product data

• Give each product and variant a fixed ID that never changes.

• Keep price, stock and promotions accurate and updated often enough to match what checkout actually shows.

• Make delivery areas, restrictions and returns information available to agents.

• Pick one system as the source of truth for when different channels disagree.

Checkout and order systems

• Build checkout as separate operations, create, update, complete and cancel, so each can be called independently rather than as one rigid sequence.

• Recalculate automatically the moment stock, price or delivery details change.

• Give every request a unique ID and every order a stable one, so retries don't duplicate anything.

• Sign webhooks and protect them against replay.

Payment and authentication

• Use a payment provider that can issue and check limited, single-use payment tokens.

• Decide upfront which payment methods and authentication steps, like 3-D Secure, apply to which orders.

• Test what happens when a payment is declined, a token expires or a price changes mid-checkout, not just when everything goes smoothly.

Customer service and safeguards

• Show the customer a clear review step before they authorise a purchase.

• Give customers a way to fix or cancel an order placed through an agent.

• Keep a human support option that doesn't require going back through the agent.

• Decide in advance who handles cancellations, returns, refunds and complaints.

Staying flexible as standards settle

• Build product, checkout, payment and order systems as separate, modular pieces rather than tying them to one protocol.

• Watch ACP's own changelog directly, since it has changed four times in seven months.

• Track order accuracy, authentication failures and return rates, not just how many agents connect.

Where should retailers start?

ACP only works as well as the systems behind the agent. The agent is still relying on the retailer for the right price, current stock and tax, and on the payment provider to handle the payment securely. The customer remains the one who approves the purchase.

This makes accurate product and inventory data just as important as the ACP integration itself, along with checkout and payment systems that can connect to different protocols. ACP has already been revised four times since launch, and with UCP, AP2 and card-network protocols also taking shape, it is too early to know where adoption will settle. Building some flexibility into those systems means retailers can support more than one as the market develops. It is also worth deciding early how orders placed by agents will be handled afterwards, from customer queries to cancellations and refunds.

Fynd's platform brings product data, commerce APIs and AI-led shopping tools together under one roof, the kind of foundation this readiness actually needs.

Explore Fynd's Agentic Commerce Solutions