ACP vs UCP: The Agentic Commerce Protocols Explained

ACP and UCP are open protocols that help AI agents interact with merchants and complete shopping tasks. ACP, developed by OpenAI and Stripe, focuses on purchases inside conversational AI experiences. UCP, co-developed by Google, Shopify and other commerce and payment companies, sets out a broader way for AI experiences to discover a merchant’s capabilities and support shopping from product discovery through checkout.

For merchants, ACP vs UCP is not a decision to make by guessing which protocol will win. The practical first step is to make product, price, availability and checkout information clear and reliable, then check what your commerce platform and payment provider support. That work is useful for e-commerce brands improving their AI search visibility whether or not a customer buys through an AI interface.

ACP vs UCP: the short answer

The simplest distinction is where each protocol starts. ACP is designed around an AI platform helping a person complete a purchase in a conversation. UCP is designed to let a merchant describe its commerce capabilities in a standard way, so participating AI experiences can discover and use them.

Both aim to connect AI shopping experiences with merchant systems. Both can support a purchase without making the AI platform the seller. But they take different routes and are associated with different ecosystems. ACP is associated with OpenAI and Stripe. UCP is associated with Google and a wider group of retailers, commerce platforms and payment companies.

Think of them as shared instruction sets, not shopping apps. They define how software can exchange commerce information and actions. They do not, on their own, create accurate product data, guarantee that an AI assistant will recommend a product, or make every checkout available in every AI tool.

The descriptions above summarise the protocols’ stated direction. Actual features and availability depend on the specific platform, merchant setup and implementation. The ACP specification and the UCP documentation are the best places to check protocol details as they evolve.

What agentic commerce means

Agentic commerce is shopping in which an AI system can do more than recommend an item. It may help a person find a product, check details, assemble a cart and, where the service and merchant support it, help complete a transaction.

An agent is software that can interpret a request and take steps using connected tools. For example, a shopper might ask, “Find a waterproof daypack under $150 that fits a 15-inch laptop and can arrive this week.” An AI agent could identify products that match, compare their details and offer a way to purchase one.

That does not mean the agent has unrestricted control of a person’s money. Commerce protocols and payment systems need to define what information is shared, what actions are permitted and how the buyer authorises payment. In many flows, the person reviews the selection and approves the payment rather than giving an agent permission to buy anything at any time.

A few terms help make the rest of this guide easier to follow:

• Protocol: A shared set of rules for how software exchanges information and requests actions.
• API: An application programming interface, or a defined way for one software system to request information or actions from another.
• Agent: AI software that can use information and connected tools to carry out a task.
• Merchant: The business that sells the product or service.
• Merchant of record: The seller responsible for the transaction, including obligations such as taking payment and handling the order. The exact responsibilities depend on the arrangement and applicable law.
• Checkout: The process of confirming a basket, delivery details, applicable costs and payment.
• Payment authorisation: Permission from the buyer and payment system for a transaction to proceed.

Agentic shopping is a new interface to commerce, not a replacement for the underlying store. Merchants still need dependable product information, inventory, fulfilment, customer service and payment processing. The agent is another route into those systems.

Who backs ACP and UCP?

ACP is an open specification developed by OpenAI and Stripe. Its purpose is to support commerce actions in AI experiences, including conversational shopping. The ACP documentation describes the protocol and its implementation concepts. In the partnership, OpenAI brings the AI interface and Stripe brings payment and commerce infrastructure expertise.

UCP was announced by Google with co-development and support from companies including Shopify, Walmart, Target, Etsy, Stripe, Visa and Mastercard. Google describes its aim as a common way for AI platforms and merchants to connect commerce capabilities. Developers can review the protocol design via the Google Merchant UCP documentation to see how the architecture links platforms and stores.

The backing matters because a protocol is useful only when the organisations on both sides adopt it. AI platforms need to be able to discover and use merchant capabilities. Merchants need a workable way to expose those capabilities through their current systems. Payment providers and commerce platforms can help bridge the two.

However, a list of supporters is not proof that every feature is live everywhere. A protocol’s specification, a platform’s product announcement and a merchant’s ability to use a feature are different things. Before changing a store, ask your platform or provider what is supported now, in which markets and under what requirements.

How ACP works

ACP is oriented around a purchase happening through a conversational AI experience. A shopper asks for a recommendation, compares options and signals that they want to buy. The AI experience can then use a supported commerce connection to pass product or checkout details to the merchant’s systems and help the shopper complete the transaction.

A simplified example:

1. A shopper asks an AI assistant to find a particular product.
2. The assistant presents a merchant’s product and relevant details.
3. The shopper chooses the item and asks to purchase it.
4. The supported flow shares the necessary checkout information and requests payment authorisation.
5. The merchant processes the order, sends confirmation and fulfils it.

The real sequence depends on the AI product, merchant integration and payment method. The point is that ACP gives the participating systems a shared commerce-specific way to handle parts of the transaction. It is not a guarantee that every chat assistant can buy from every store.

ACP is sometimes described as platform-first or agent-first. That means the shopper’s request begins in the AI interface, and the AI platform is a central part of the purchase journey. The merchant must still provide the product and order capabilities required to fulfil the sale.

The protocol’s payment and checkout concepts are important because a chat interface should not simply pass a customer’s raw payment details around. The protocol documentation describes approaches for securely handling payment information and checkout handoffs. Merchants should confirm exactly how their gateway implements authorisation, what data is shared, and what the buyer sees before approval.

Stripe’s overview of agentic commerce protocols and UCP is useful for understanding how payment providers fit into these flows. A payment provider can support the payment step, but it does not replace the merchant’s responsibilities for accurate product data, taxes, delivery promises, refunds or customer support.

How UCP works

UCP is designed to provide a common way for AI experiences and merchants to communicate commerce capabilities. A merchant can publish information about supported capabilities so a compatible platform can understand how to interact with its commerce systems.

The UCP specification describes a merchant-hosted manifest at a well-known address, /.well-known/ucp. A manifest is a machine-readable file that tells software what a website supports and where relevant services can be found. The pattern is similar in spirit to other standard website files that help software understand a site, but UCP’s manifest describes commerce capabilities rather than crawler preferences.

In a simplified UCP journey, an AI experience discovers that a merchant supports particular shopping functions. It can then request relevant information, such as product availability or checkout options, using the supported interfaces. Depending on the implementation, the journey can involve cart creation, identity linking and a handoff to payment.

The UCP documentation covers a wider commerce lifecycle than a simple payment handoff. That includes how systems express capabilities and interact around shopping tasks. Resources such as the Google Merchant UCP reference cover the exact supported objects and technical requirements.

A UCP manifest is not the same thing as a product feed. The manifest describes what a merchant’s system can do. Product feeds and product data describe what the merchant sells, along with details such as price and availability. Both kinds of information matter, and one does not make the other unnecessary.

UCP is often described as merchant-first or open-web-oriented because the merchant can declare capabilities from its own domain, rather than relying only on a platform-specific connector. That is an architectural direction, not a promise that every AI platform will read the manifest or that every merchant must build one by hand. A commerce platform may provide or manage the implementation for its customers.

ACP vs UCP: what is different in practice?

The protocols overlap in purpose. Both aim to make commerce actions easier for AI systems to carry out. Their differences are mainly about how an AI platform finds the merchant’s capabilities and how the shopping experience is organised.

The contrast is not “ACP does checkout, UCP does everything”. ACP and UCP are both evolving, and their capabilities can overlap. Different platforms may support different parts of each specification. Check current documentation instead of treating a summary table as a complete implementation guide.

Nor is this simply a contest between OpenAI and Google. Merchants sell through different platforms and serve customers using many AI experiences. Commerce platforms and payment providers may support multiple approaches so businesses do not have to maintain a separate store for each AI assistant. For context on how these pieces relate, see the commercetools guide to MCP, ACP and UCP.

ACP, UCP and MCP are not the same thing

MCP stands for Model Context Protocol. It is a standard for connecting AI models with external tools and information. ACP and UCP are commerce-specific protocols: they address shopping actions and the information needed around them, such as carts, checkout and payment authorisation.

A plain example makes the distinction clearer. An MCP connection might let an AI system call a tool or retrieve information from a service. A commerce protocol defines the shopping-specific meaning of actions and information: which product is being purchased, what is in the cart and how checkout should be handled. For teams connecting multiple business tools to agent workflows, platforms like Hoook provide hosted MCP servers and authentication across apps.

They can fit into the same technical environment, but they are not interchangeable. Supporting MCP does not automatically mean a store supports ACP or UCP. Similarly, publishing a UCP manifest does not automatically give an AI model every tool or permission it needs. The commercetools explanation of MCP, ACP and UCP discusses the distinction in more detail.

What happens to the merchant and the customer relationship?

A common concern is that the customer will buy inside an AI interface and the merchant will lose the relationship. There is a real trade-off to consider: fewer people may visit a product page before purchasing, which can reduce opportunities to tell the brand story or introduce related products. The exact effect depends on how each AI shopping experience is designed and how customers use it.

At the same time, an AI-mediated purchase does not automatically make the AI company the seller. The protocol descriptions place the merchant in the role of seller, with the merchant responsible for processing and fulfilling its order. Merchants should confirm the contractual and operational details of each specific channel rather than assuming all flows have the same arrangement.

Identity linking is one way a supported experience can connect a shopper’s account to a merchant account. OAuth 2.0 is a standard method for authorising one service to access a defined set of information or actions on a user’s behalf, without sharing the user’s password with that service. In a commerce context, a shopper might sign in or authorise an account connection so that the purchase can use an eligible loyalty benefit or recognise an existing customer.

That does not mean every customer will link an account, or that a merchant can collect any data it wants. Consent, data minimisation, privacy law, platform rules and the details of the integration still matter. Ask what data is passed, for what purpose, how the customer authorises it, and where order and consent records are stored.

A sensible merchant goal is to keep the customer experience useful even when the buyer does not visit the storefront. Make order confirmation, delivery updates, returns information and support easy to access. Where a supported integration offers account linking, explain the value and ask for permission clearly.

What merchants should do now

Most businesses do not need to build a custom protocol integration as their first step. Start with the foundations that make your catalogue and checkout dependable for both people and software.

1. Make product information complete and consistent

For every product and variant, check that your store has a clear title, description, price, currency, images, identifiers, options and availability. A variant is a specific version of a product, such as a particular size or colour. If the shopper asks for a blue medium, the agent needs to distinguish that option from a blue large or a red medium.

Keep the same facts aligned across your product pages, structured data, product feeds and commerce platform. Structured data is a standardised way to label information on a web page so software can interpret it. Schema.org vocabulary such as Product and Offer can help describe product and offer details, but correct markup does not compensate for incorrect information in the underlying store.

Review policies too. Returns, shipping, warranty and availability information should be easy to find and expressed in plain language. If a delivery date depends on postcode or stock location, avoid presenting a generic promise as if it applied to every shopper.

For a practical view of the content side, SearchFIT’s guide to content strategies for AI search visibility covers how clear, useful information can support discovery. Product data still needs its own technical checks.

2. Treat price and inventory as live business data

A product page can be accurate when it is published and wrong an hour later. Keep prices, stock status and variant availability connected to the system that controls them. Where possible, make sure the AI commerce integration queries current information rather than relying on a stale copy.

Test less obvious cases: a product that has one size out of stock, an item available only for collection, or a price that changes by market. Confirm that the customer sees the right currency, delivery conditions and any required fees before approving an order.

Do not let an agent’s response become the source of truth for inventory. Your commerce platform should remain the source of record, and the integration should communicate its current state. Decide what happens if stock changes between the agent checking availability and the buyer completing checkout.

3. Review checkout, payment and order handling

Map the existing checkout process from cart to confirmation. Identify where shipping costs, tax, discount codes and payment approval are calculated. Then ask your commerce platform and payment provider which parts can be used by ACP or UCP, and which require a conventional handoff to your website.

Ask specific questions:

• Which protocol or protocol features are supported today?
• Which AI platforms and markets can use the integration?
• Does checkout happen in the AI interface, on the merchant’s site, or through a mixture of both?
• How does the buyer approve payment, and what information is shared?
• How are cancelled, failed, refunded or disputed orders handled?
• Where can staff see the order, and how does it enter fulfilment and customer support systems?

A successful demo is not enough. Test a normal purchase, an out-of-stock product, a failed payment and a cancellation. Check that your team can find and resolve the resulting orders.

4. Check your platform before building an endpoint

If you use Shopify, WooCommerce or another commerce platform, start with its official documentation and roadmap. Ask whether support is native, supplied by an app or plugin, or requires custom development. “Supported” can mean different things, so confirm the specific features, costs, limits and ongoing maintenance involved. For retailers on Shopify, preparing your store with the AI agent skills Shopify stores need in 2026 provides a solid foundation for automated commerce workflows.

If you operate a custom commerce stack, involve engineering, security, payments and customer service early. A custom endpoint is not just a web development task. It may affect authentication, rate limits, order state, fraud controls, consent, support workflows and how changes to the protocol are maintained.

The UCP manifest at /.well-known/ucp is part of the specification, but whether you should create one manually depends on the integration and the current instructions from your platform. Follow official documentation rather than copying an example without understanding the required fields and security model.

5. Protect consent, privacy and security

Before exposing customer or order information to an AI experience, decide what data is necessary and who can access it. Use the integration’s documented authorisation process, restrict permissions to what the task requires, and make the consent request understandable to a shopper.

Check how credentials and payment authorisations are protected. Keep secrets out of public code and logs. Define how access can be revoked and what happens when a customer disconnects an account. Have the right people review privacy notices and contractual terms for each channel.

These controls are not protocol-specific extras. They are part of operating any connected commerce system responsibly.

6. Measure shopping quality, not just traffic

If a purchase can happen without a visit to your website, website sessions alone will not describe the full customer journey. Where platform reporting permits, monitor product impressions, clicks, assisted purchases, completed orders, conversion, average order value, returns and support contacts. Treat data from different AI platforms as separate until you know the reporting definitions match.

Also track whether product facts are represented correctly. Sample prompts that matter to your business and see whether AI experiences describe the product, price, availability and policies accurately. Compare what the AI says with the source data in your store. Record problems such as a mismatched variant or an old delivery promise, then trace them to their source.

For a broader programme, SearchFIT’s resources for AI search and marketing can help teams organise visibility and content work. Protocol readiness is only one part of being easy to find and understand in AI search.

How much implementation work is involved?

The work varies. A store using a platform that provides a supported integration may have a simpler path than a retailer running a heavily customised catalogue, checkout and fulfilment stack. The harder work is often not writing the protocol connection. It is aligning product data, inventory, identity, payment, privacy and operations so the connection behaves correctly.

One estimate in Topic Intelligence Research, published in March 2026, put custom protocol integration for enterprise stacks at $20,000 to $50,000, while noting that platform integrations may use plugins or abstracted layers. Treat this as a reported estimate, not a universal quote or budget. Scope, existing infrastructure, security review and ongoing support can change the cost considerably. Ask vendors for a written scope that separates setup, platform fees, payment costs and maintenance.

Do not invest in custom infrastructure just because a protocol is receiving attention. First confirm that your buyers use the relevant channel, the integration is available to your business, and the expected benefit can be measured. If a platform already handles the protocol connection, your effort may be better spent on product data, stock accuracy and customer experience.

What does consumer interest tell merchants?

Interest in AI-assisted product research is not the same as willingness to let an AI complete a purchase. Akeneo’s May 2026 Digital Commerce Study reports that 37% of consumers surveyed initiate product searches directly in large language models, and 58% use AI for product research. The same study reports that 17% trust an AI agent to execute transactions fully autonomously without human sign-off. See Akeneo’s discussion of ACP and UCP for its account of the findings.

These figures are from one study and should not be treated as universal behaviour across every country, audience or product category. They do point to an important distinction for planning: shoppers may welcome AI for comparing options while still wanting to review a cart and approve payment themselves.

Build for that level of control. Show the product, final price, delivery details and return terms clearly. Make it easy for the shopper to correct an item or stop the transaction. Trust is part of the checkout experience, not just a feature of the protocol.

Will ACP or UCP win?

There is no sound reason for most merchants to assume one will make the other obsolete soon. The protocols have different sponsors and approaches, but the commerce industry includes multiple AI platforms, storefront systems and payment providers. A merchant may need to serve several discovery and transaction routes over time.

That does not mean you should build every integration immediately. A better approach is to keep the underlying commerce capabilities clean and portable: structured product data, accurate inventory, robust APIs, well-defined checkout rules and clear customer permissions. Those foundations can make it easier to adopt a supported protocol later.

Payment standards and integrations may also help connect different experiences. As Spreedly's analysis of ACP and UCP notes, relying entirely on a single protocol or payment flow can create unnecessary lock-in across different shopping platforms. Confirm what your own providers support and test the full purchase path.

What ACP and UCP mean for SEO and AEO

SEO helps a website appear in search results. AEO, or Answer Engine Optimization, is the practice of making information easy for answer engines to interpret and use in responses. Agentic commerce adds another requirement: information must not only explain a product, it may also need to support an action such as checking availability or starting checkout.

That makes accurate product entities and useful supporting content important. A product page should answer basic buyer questions in plain language: what the item is, who it suits, how it differs from alternatives, what it costs and what the important conditions are. Structured data can make some of these facts easier for software to identify. A commerce integration can provide live transactional information.

Neither protocol guarantees a recommendation or a citation. An AI system can choose what to show based on its own product, platform and ranking logic. Nor does a protocol endpoint replace content that helps a shopper make a decision. Keep improving both: the machine-readable information agents may need to act, and the helpful product information people need to trust the choice.

A practical readiness checklist

Use this checklist to turn the ACP vs UCP discussion into manageable work:

• Product titles, descriptions, identifiers, variants and prices are complete and consistent.
• Inventory and delivery information come from a system that can provide current values.
• Product pages explain shipping, returns, warranties and important limitations clearly.
• Structured product data is checked against the information shown to shoppers.
• Your platform and payment provider have confirmed which protocol capabilities they support.
• Your team understands where checkout happens and how orders enter fulfilment.
• Payment approval, account linking and data sharing are clear to the shopper.
• Support staff can find, change, cancel and refund orders made through connected channels.
• You have a way to test product accuracy and monitor the results of AI-assisted shopping.

The order matters. Fix inaccurate data and broken operations before building a custom protocol layer. A sophisticated connection can only transmit the information and business rules your systems provide.

The takeaway for merchants

ACP and UCP are two ways of making AI-assisted shopping work with merchant systems. ACP puts the conversational AI experience at the centre of a supported purchase flow. UCP offers a standard way for merchants to describe commerce capabilities that compatible AI experiences can discover and use. Both aim to support transactions while leaving the merchant responsible for selling and fulfilling its products.

You do not need to predict a protocol winner to prepare. Make product data dependable, ensure inventory and checkout rules are clear, understand your platform’s support, and protect customer consent and payment security. Then test integrations when they are available and relevant to your customers.

For a next step, review how SearchFIT can support ongoing AI search and content work on our pricing page.