Agentic commerce protocol: comparing ACP, UCP and AP2

Key takeaways

ACP, UCP and AP2 promise agent checkout, and merchants have to decide which protocol to support before agents start buying. AI assistants now answer the question before anyone clicks a result, so the protocol is only useful if agents can find your offer and complete the sale.

• ACP centers on checkout: its beta specification covers checkout sessions and delegated payment across API or MCP paths.
• UCP describes a broader journey: Google presents discovery, buying and post-purchase as parts of an open commerce standard.
• AP2 focuses on payment authorization: it addresses user authority, request authenticity and accountability for agent payments.
• A protocol name is not an implementation: verify the merchant's actual endpoints and transaction behavior.
• Detection has a defined scope: Qomvia's E-commerce add-on lists AP2, but its documented detection paths do not include an AP2 endpoint.

What is an agentic commerce protocol?

An agentic commerce protocol is a set of technical conventions for how software agents and businesses exchange information or carry out parts of a purchase. The term covers different stages, from finding an offer to creating a checkout session or authorizing payment. Comparing protocols requires attention to scope, control and implementation, not just shared language about AI shopping.

A merchant may encounter ACP, UCP and AP2 in the same discussion, but they do not describe the same job. ACP focuses on commerce checkout interactions; UCP frames a broader journey; AP2 addresses agent-payment authorization. A protocol can be open and still require a merchant, platform or payment provider to implement it before a shopper can use it.

This guide compares scope and verification, not the full business strategy for AI shopping. For product data, discovery and merchant operations, see the agentic commerce guide. For the Qomvia product boundary, explore the E-commerce add-on and Qomvia Market.

What does the Agentic Commerce Protocol cover?

Checkout sessions and delegated payment

The Agentic Commerce Protocol is an open standard maintained by OpenAI and Stripe and described by its project as Apache 2.0 licensed and in beta. Stripe's documentation describes ACP as created by Stripe, OpenAI and Meta; attribute that wording to Stripe rather than flattening the two descriptions into one. The versioned specification uses OpenAPI and JSON Schema.

ACP covers checkout sessions that can be created, updated and completed, along with delegated payment. Its project material describes both API and MCP approaches. A business can accept or decline an agent or transaction, keeping a merchant-side decision in the flow. These properties identify the protocol's scope; they do not prove that any particular store has deployed a compatible checkout.

OpenAI describes itself as the first AI platform to implement ACP, and Stripe identifies itself as the first compatible payment service provider using a Shared Payment Token. Keep those claims attributed to their respective project documentation. The merchant still needs to confirm which integration, payment path and order operations apply to its own storefront.

For implementation review, trace the session lifecycle. Determine which system creates the session, how a change to quantity or shipping is represented, when a transaction can be completed and which party handles payment and order status. The specification gives a shared vocabulary, while the merchant must still test the integration, confirmation steps and failure handling that customers will experience.

Review every transition a customer would care about: product identity, selected quantity, delivery choice, final price, payment authorization and confirmation. Confirm which values are authoritative in the merchant's system and which arrive from an agent or platform. A successful request to create a session does not prove that the final order is accurate, so compare the completed transaction with the customer's confirmed choice.

Define failure behavior before enabling a new checkout path. What happens if inventory changes, a shipping option is unavailable or the payment request is declined? The shopper needs a clear explanation and a way to finish or abandon the task. An integration review should include these exception paths, not only a clean demonstration using a simple product and a successful payment.

What does Universal Commerce Protocol cover?

Google announced UCP in January 2026 as an open standard for agentic commerce across discovery, buying and post-purchase interactions. Google said it was co-developed with Shopify, Etsy, Wayfair, Target and Walmart, and that other organizations endorsed it. It is compatible with A2A, AP2 and MCP. Those are attributes of the announced standard, not proof that every compatible integration is available in every market.

The breadth of UCP makes it different from a checkout-session protocol. Its stated scope follows a broader journey, including how a product is discovered and what happens after an order. A merchant evaluating the protocol should ask which part of that journey its implementation actually supports, what data it exposes and how a customer can confirm the resulting purchase.

Google said UCP would power a checkout feature on eligible product listings in AI Mode and the Gemini app for eligible U.S. retailers, using Google Pay. Treat this as the announced plan for eligible retailers. Check the current provider documentation and merchant onboarding before describing a specific merchant as active.

A business should map its catalog, availability, identity and order status to the protocol's intended role. If a product is present in a feed but cannot be purchased through the relevant flow, do not label the whole commerce journey integrated. Record what has been tested, what remains an announcement and which party owns the order after checkout.

Translate a broad journey into merchant-owned operations. Identify how an item is matched to the catalog, where current availability comes from, which checkout terms the buyer sees and how changes are handled after the order. A protocol description can organize the conversation, but it does not remove the need to reconcile product identifiers, fulfillment state and customer service responsibilities across the systems involved.

Ask whether each step is available to the merchant's actual platform and market before planning work around it. An announced feature, an eligible listing and a completed integration are different states. Keep those states visible in a delivery plan. If the feature is not currently available to the merchant, continue improving the product data and ordinary checkout experience without representing the future path as live.

What does Agent Payments Protocol address?

AP2 is an open protocol for agent payments, announced in September 2025. Its documentation describes it as an extension for A2A and UCP. Its concerns include authorization, meaning the user gave the agent authority; authenticity, meaning the request reflects user intent; and accountability, meaning the payment action can be understood and audited.

This scope differs from a product feed or checkout-session exchange. A payment protocol addresses the authority and provenance of an agent's payment action. It does not by itself describe the merchant's catalog quality, product discovery or every step in fulfillment. If a team says it “supports AP2,” ask what implementation, agent, payment provider and transaction path it has actually tested.

The AP2 site lists a version 0.2 release. Treat that as the version shown by the project's documentation when reviewing a specification, not as evidence of broad adoption or merchant readiness. A protocol's maturity, an implementation's conformance and a completed production transaction are three separate facts.

For a payment-authority review, ask how a user grants permission, how the transaction stays tied to that instruction and what evidence is retained for later review. Define what an agent may do without returning for confirmation and what requires a new user decision. Do not infer that a payment protocol determines the merchant's refund policy, shipping terms or fulfillment process.

Treat the payment handoff as a trust boundary. The merchant needs to know which party authenticated the user, which party authorized the payment and which party can answer a dispute. A protocol's vocabulary can make those responsibilities easier to discuss, but the implementation contract and operational runbook must still name accountable owners.

Before an agent can initiate a payment, the merchant should define the amount, order state, cancellation path and point at which the buyer must approve. Include an exception path for a changed total or unavailable item. These decisions belong in the merchant's operational rules, not in a broad claim that a payment protocol makes a transaction safe by itself.

Document the handoff between the assistant, commerce service, payment provider and merchant. Name who communicates a decline, who can reverse or refund a completed order and what evidence support staff can see. The protocol may standardize messages at an interface, but each organization still needs an accountable owner for customer-facing resolution.

How do ACP, UCP and AP2 compare?

Compare scopes rather than protocol labels

The simplest comparison is by the object each protocol coordinates. ACP describes checkout sessions and delegated payment. UCP describes a broader commerce journey. AP2 describes authorization and accountability for agent payments. Their scopes can intersect in a transaction, but they are not interchangeable labels for a single integration.

The matrix is a scope guide, not a preference ranking. A retailer can need one protocol for an immediate checkout integration and another for a wider journey or payment authorization. The decision depends on the agent, platform, payment provider, merchant system and supported transaction. A protocol with a broader mission is not automatically the right first implementation.

Compare the system boundary as well as the protocol label. Ask where catalog data is maintained, which participant can alter a cart, who confirms the final terms and where the order record lives. A merchant that already has a reliable checkout may need only a defined exchange at one boundary; another may first need to repair inventory or product identity data.

Separate specification review from conformance testing and business acceptance. A team can read a specification without implementing it, deploy an endpoint without supporting every operation or complete a technical flow that still fails customer expectations. Write an acceptance test for the exact journey the merchant intends to support and have the appropriate commerce, security and finance owners review it.

Treat the protocol comparison as a buyer journey map, not a scorecard. Mark which participant owns product discovery, offer truth, checkout state, payment authorization and post-purchase service. A missing step may be an operational gap even if the selected protocol's message exchange is complete.

Write evidence requirements into the acceptance test. Capture the request, response, user confirmation, final amount, order record and failure path that the merchant actually supports. Have security and finance review evidence retention and the dispute process before describing a technical demonstration as ready for a customer.

What does Qomvia's E-commerce add-on detect?

Qomvia's feature inventory says the E-commerce add-on detects ACP through /.well-known/acp.json or agentic-commerce.json, and UCP through /.well-known/ucp or ucp.json. It also detects x402 and MPP payment signals and a Qomvia Market connection through /.well-known/qomvia.json. These are specific public checks, not a conformance certification for every transaction.

AP2 appears in the add-on's protocol inventory, but the feature documentation does not describe an AP2 detection path. Do not tell a customer that the scan verifies AP2 conformance or payment authorization. A product inventory entry and a concrete automated check are different levels of support.

A detection result can indicate whether a known endpoint or signal is present. It cannot establish that an agent can complete every order, that a payment will be authorized or that the merchant has adopted a separate provider's full protocol. Pair public checks with an implementation review and a test purchase under the merchant's actual terms.

When interpreting a scan, check the exact URL and signal that was detected, then verify the endpoint contents and live transaction separately. A file can exist while describing an incomplete integration, and a flow can use custom implementation that does not rely on the listed discovery signal. Use the result as a starting point for technical review, not as a certification badge.

Before scoring a public signal, agree what each status means. “Present” can mean the endpoint returned, while “usable” requires checking that its contents are current and refer to the intended merchant. Keep “not tested” separate from “not present,” especially when access needs credentials or consent. These labels make an audit reproducible and prevent uncertainty about a private flow from being reported as a public implementation failure.

Preserve the response, fetch time and exact endpoint with the review. Ask the integration owner to confirm that the observed file corresponds to the deployed checkout and the merchant's current terms. Repeat the check after a catalog, payment or platform change, and record what evidence changed. A historic response can explain a prior review, but it should not stand in for a fresh transaction test.

How should a merchant choose a protocol path?

Describe the buyer journey before choosing an implementation. Which participant provides product data, who controls the cart, where does the buyer review the final price and which system stores the order? A diagram of these boundaries often reveals that the immediate blocker is inaccurate catalog data or unclear responsibility rather than the absence of a new protocol.

Ask potential implementation partners to identify the exact operations supported and provide a testable description of the end-to-end flow. Confirm how failed, cancelled and partially completed orders are handled. Avoid treating a roadmap statement, a discovery endpoint or a sandbox demonstration as evidence that a merchant's live checkout is ready for customers.

Start with the customer task and merchant system. Does the agent need to find products, compare current offers, create a checkout session, authorize a payment or handle post-purchase changes? Write down the step where the current experience breaks. Then identify which protocol's documented scope corresponds to that step.

Ask each integration partner for the exact version, supported operations, payment responsibilities and failure behavior. Confirm who remains merchant of record, which system stores order state and how the customer can review or cancel an action. Do not infer compatibility from an acronym on a landing page. Test the flow with the actual catalog and merchant backend before broadening the claim.

Keep protocol adoption separate from readiness fundamentals. Accurate product identities, current offers, accessible pages and clear seller terms help people and software even when no protocol integration is active. The broader agentic commerce guide covers those merchant inputs; this comparison is about standards and implementation boundaries.

Create a decision record that names the customer task, required participants, target operations, current implementation status, dependencies and unresolved risks. Include the exact protocol version or announcement relied upon and the date it was reviewed. This prevents a roadmap slide from turning a standards discussion into an accidental claim that the store is already able to transact through an agent.

Revisit the decision when the merchant platform, payment provider or customer journey changes. A protocol that was out of scope for a product catalog may become relevant when checkout moves to a partner, while a broad integration can become unnecessary if the transaction path changes. Keep product data quality and ordinary customer safeguards in the plan regardless of which protocol is selected. For merchant-facing product data, see the ChatGPT shopping guide.

Communicate readiness with precise verbs. “We detected a public endpoint” describes a scan. “We implemented the documented checkout operation” describes code. “We tested an order through this path” describes an observed transaction. Avoid using “supports” without clarifying which state applies; buyers need to know whether detection, implementation or a tested transaction is available.

How Qomvia connects your store to agent commerce

Qomvia's score detects ACP, UCP and payment signals on your site, and Qomvia Market gives agents signed offers and your own checkout today.

The free scan runs all 26 checks of the agent-readiness score in about a minute and lists every failing check with a copy-paste fix; the free Site monitor re-scans weekly, no signup for the score. The AI monitor then asks your buyers' questions to ChatGPT, Gemini and Grok every day and shows whether you are named, which rival is named instead and which sources the models used. Qomvia Market and the MCP server take it one step further, letting agents act on the recommendation. Sign up free or see plans and pricing.

Sources and further reading

• Agentic Commerce Protocol
• Agentic Commerce Protocol repository
• Stripe: Agentic Commerce Protocol
• Google: Universal Commerce Protocol announcement
• Google Developers: Universal Commerce Protocol
• Agent Payments Protocol
• Qomvia E-commerce add-on

Questions

What is the difference between ACP and UCP?

ACP focuses on checkout sessions and delegated payment, while UCP describes a broader commerce journey from discovery to post-purchase. Verify the implementation rather than assuming the scopes are interchangeable.

What does AP2 do in agentic commerce?

AP2 addresses authorization, authenticity and accountability for agent payment actions. Its scope is distinct from a product feed or full commerce journey.

Is ACP live for every merchant?

No such claim is established here. The project describes the standard as in beta, and each merchant must verify its own integration and supported transaction path.

Is UCP checkout available to all retailers?

Google's announcement described a planned feature for eligible product listings and eligible U.S. retailers. It should not be read as confirmation that any specific merchant is live.

Does Qomvia detect AP2?

AP2 is listed in the E-commerce add-on's protocol inventory, but the feature documentation does not specify an AP2 detection path.

How should merchants choose an agentic commerce protocol?

Map the customer task and system boundary first, then compare the protocol's documented operations, payment roles and implementation requirements with that need.