Agentic Commerce

UCP vs. ACP vs. MPP: Which Agentic Commerce Standard Does Your Business Need?

Compare UCP, ACP, and MPP by the job each protocol performs, then choose a commerce path without confusing support with journey success.

Published 2026-08-30.

Try a useful free toolRead the blog

UCP, ACP, and MPP are often grouped under the label agentic commerce, but they do not answer one interchangeable technical question. A retailer trying to appear in an AI shopping surface, a merchant enabling checkout through an assistant, and an API publisher charging an agent for a machine-readable resource have different discovery, authorization, payment, fulfillment, and evidence needs. Choosing a protocol by acronym alone can produce an integration that is technically present yet commercially incomplete. This guide separates what the mapped official sources say from LaunchBuddy recommendations as of August 30, 2026. It does not report a live merchant implementation or claim that any protocol guarantees sales. Instead, it provides a decision framework, a safe test contract, and the evidence a business should require before calling a customer journey agent-ready.

Research context: 2026-08-30. Consolidated on LaunchBuddy on 2026-11-04. Product availability and standards can change; use the linked primary documentation for current setup. The workflows below distinguish proposed tests from observed results.

1. Start with the commercial job, not the protocol acronym

The first distinction is where the customer journey begins and ends. A shopping assistant may need to discover a product, compare variants, learn current price and availability, assemble a cart, obtain the buyer's approval, present a payment credential, create an order, and return a receipt. A software agent purchasing an API response may instead know the exact endpoint already and need a machine-native way to authorize a small payment before receiving the resource. Those are both commercial actions, but their catalogs, interfaces, risk controls, and proof of completion are different. LaunchBuddy recommends writing the goal as a task card before selecting a standard: starting surface, intended item or resource, buyer identity, allowed spend, prohibited substitutions, approval point, expected provider or merchant receipt, and recovery route. AW6 AW7 AW8 AW18 AR7

The second distinction is evidence. A product feed can make an offer discoverable without proving that checkout accepts the delegated credential. A successful payment authorization can exist while the order remains pending, duplicated, incorrectly configured, or impossible to fulfill. A protocol handshake can pass while an agent selects the wrong plan because the site's visible facts are ambiguous. Official protocol documentation should define the supported contract; the merchant must still verify product truth, authorization, server-side totals, idempotency, fulfillment state, cancellation or refund paths, and a durable outcome. LaunchBuddy therefore treats protocol presence as one evidence layer rather than a universal readiness badge. AW6 AW7 AW8 AW18 AR5 AR6 AR7

  1. **Name the buyer journey** State whether an agent must discover a product, complete a hosted or embedded checkout, or purchase a machine resource at an API, HTTP, or MCP endpoint.
  2. **Define the consequence boundary** Record the exact amount, currency, merchant, item or resource, human approval requirement, and action that a test must stop before unless it uses an authorized sandbox.
  3. **Choose the authoritative receipt** Decide whether success requires an order identifier, payment state, entitlement, reservation, resource response, fulfillment record, or another system-of-record readback.

2. UCP is a commerce interoperability path, not a generic payment button

Google's official UCP material describes an open commerce protocol intended to connect consumer agents and businesses across the shopping journey. The current v2026-08-25 specification organizes the contract around versioned capabilities and extensions; its release adds structural changes, expanded multi-vertical support, 3DS2 payment handling, request constraints, and grocery-commerce support. The relevant business question is broader than whether a card field can be filled. A merchant needs accurate product and merchant information, capabilities the participating surface can negotiate, a checkout contract, and payment handling compatible with that environment. UCP is most directly relevant to businesses that want their catalog and commerce capabilities represented in agent-driven shopping experiences. Adding a single file or label does not make every product current or every checkout safe. Eligibility, platform availability, onboarding, and implementation requirements remain deployment-specific. AW7 AW26 AW31 AR5 AR6

For an implementation review, LaunchBuddy recommends testing the full data-to-order chain. Select a product with variants, inventory, shipping constraints, tax context, and a visible return policy. Compare the information supplied to the agent surface with the merchant's current system of record. Ask the agent to reach the final review state and verify that item, variant, quantity, destination, total, merchant identity, and approval language remain consistent. In an authorized sandbox, continue to the order and reconcile the returned receipt with the merchant backend. A UCP-aligned integration that exposes stale inventory or loses the buyer's selected variant is conformant-looking but not a successful customer journey. AW7 AW26 AW6 AR5 AR7 AR8

  1. **Audit catalog freshness** Compare agent-visible title, variant, price, currency, availability, merchant, and policy facts with the current authoritative catalog.
  2. **Exercise the review state** Confirm that the agent can present the exact intended purchase and full known consequence before any credential is used or order is created.
  3. **Reconcile after action** In a sandbox, read the merchant order and payment state independently instead of accepting the agent's narrative as proof.

3. ACP centers an agent-mediated merchant checkout contract

The official ACP project describes an Apache-2.0 open standard, designed with the community, through which any compatible agent can initiate a purchase with an implementing business or payment provider. ChatGPT is identified as the first adopting AI platform, but ACP itself is not limited to OpenAI surfaces; platform participation and merchant onboarding are separate from protocol compatibility. At the decision level, ACP is relevant when a merchant wants an agent surface to discover or transact with its offers through a defined commerce integration. That is distinct from giving a browser agent a virtual card and asking it to imitate the existing website, and from charging for a single API response. Businesses should avoid claiming ACP readiness from a feed alone or from a conventional Stripe integration that has not been connected to an applicable ACP flow. AW27 AW8 AW5 AW6 AR6

The operational test is similar to UCP in shape but must follow ACP's own current contract and the merchant's chosen payment path. Verify product representation, cart and total calculation, buyer approval, token or credential scope, order creation, webhook or status handling, fulfillment ownership, refunds, and customer support. Preserve the merchant-of-record and customer-relationship facts exactly as the official integration defines them; do not infer them from the word instant. LaunchBuddy recommends testing delayed provider responses and retries as well as the happy path. If the agent receives an uncertain response, a robust implementation should reconcile state before attempting a second charge or order. AW27 AW8 AW6 AR7 AR8

  1. **Follow the current ACP source** Pin the documentation version and platform scope used by the implementation; do not copy an older preview contract into production.
  2. **Test authorization scope** Verify that the approved buyer, merchant, amount, currency, and order context cannot silently change after approval.
  3. **Test uncertain outcomes** Delay or interrupt a sandbox response, then confirm that retries reconcile the existing order rather than creating a duplicate.

4. MPP addresses machine-native paid resources

Stripe's March 18, 2026 announcement and the current MPP project describe the Machine Payments Protocol as an open, internet-native protocol co-authored by Tempo and Stripe for agents to pay businesses and other agents. The sources place MPP around machine payments at API, HTTP, and MCP-style resource boundaries, including patterns that do not resemble a human retail checkout. That makes it relevant to publishers of metered data, software operations, model or agent services, and other programmatic resources where the requesting agent can encounter a payment requirement and satisfy it through a machine contract. Implementers should use the current MPP specification rather than relying on this comparison for field, transport, asset, or lifecycle details. AW18 AW28 AR6 AR7

MPP does not remove the need to describe the resource or protect the caller. An agent still needs to know what it will receive, price and currency, usage or recurring terms, refund or failure behavior, authentication requirements, rate limits, and whether the operation has side effects beyond payment. A service should return an unambiguous paid or unpaid state and make retries safe. LaunchBuddy recommends testing a harmless, low-value sandbox resource with an exact expected response, then validating both the payment record and delivered entitlement or payload. A successful payment with a missing resource is failure; a delivered resource with an unverified or duplicate charge is also failure. AW18 AW28 AR6 AR7 AR8

  1. **Describe the paid resource** Publish the operation, price context, authentication, side effects, response contract, rate limits, and failure or refund behavior an agent needs before purchase.
  2. **Use a bounded fixture** Test a sandbox or harmless low-value resource with a known response and an explicit maximum spend.
  3. **Verify both halves** Reconcile payment state and resource delivery independently, including duplicate, timeout, and already-paid retry cases.

5. Choose by interface, distribution goal, and operating model

A merchant selling products through participating consumer-agent shopping surfaces should investigate UCP and ACP according to the channels it intends to support, its commerce platform, its payments provider, geography, and current onboarding availability. An API or MCP publisher charging for machine resources should investigate MPP rather than treating a retail catalog protocol as a universal payment layer. Some businesses may legitimately need more than one: a travel company could expose consumer offers through agent shopping surfaces and separately charge partners for an API resource. Multiple protocols are not inherently better, however. Every additional contract creates versioning, security, support, reconciliation, and monitoring obligations. AW6 AW7 AW8 AW18 AW26 AW27 AW28 AR6 AR7

A conventional website path also remains relevant. Stripe's Link wallet for agents can provide an approved one-time-use card or Shared Payment Token, depending on the flow described by Stripe. A one-time card may let an agent approach an ordinary card checkout, but it does not solve product discovery, ambiguous variants, CAPTCHAs, account creation, inaccessible controls, total calculation, or receipt verification. The companion Stripe Link wallet guide focuses on the payer credential, while this comparison focuses on commerce protocols. Read WebMCP website tools for structured website operations and safe post-login testing for authenticated journeys. AW5 AW6 AR3 AR4 AR7

  1. **Map channels** List the agent surfaces, customer segments, countries, commerce platforms, and machine endpoints the business actually intends to support.
  2. **Map systems of record** Identify the authoritative catalog, cart, payment, order, entitlement, fulfillment, refund, and support state for each path.
  3. **Adopt the smallest complete set** Choose the protocol or protocols that serve a real distribution path and that the team can test, reconcile, secure, and maintain.

6. Protocol support is the start of a journey test, not the result

LaunchBuddy recommends a shared outcome rubric across all three standards: discover, understand, authorize, transact, prove, and recover. Discovery asks whether the agent can find the current offer or resource. Understanding checks product, merchant, price, terms, and side effects. Authorization verifies the buyer, scope, target, and fresh approval. Transaction checks the intended payment and order or resource operation. Proof requires an authoritative receipt. Recovery covers timeouts, duplicates, cancellation, refund, fulfillment failure, and support. Each layer should expose pass, partial, fail, not applicable, or unobservable rather than collapsing unknown evidence into zero. AW12 AR6 AR7 AR8

Public comparative evidence should preserve consent and methodology. The Agentic Customer Journey Index shows fixed public safe-stop observations; leaderboard cohorts are bounded, opt-in methodology rather than a universal declaration of commercial quality. A merchant can compare the broader framework in readiness score vs. journey success, then inspect deterministic browser checks in Lighthouse Agentic Browsing. Named end-to-end payment results should use provider sandboxes or explicit owner authorization. No article, scan, or protocol file should trigger a real purchase merely to create marketing proof. AR7 AR8 AR9

  1. **Publish the fixture** Record goal, environment, protocol and version, product or resource, approval boundary, prohibited consequence, expected receipt, and attempt count.
  2. **Report the first causal failure** Prefer a concrete catalog, authorization, checkout, payment, order, delivery, or recovery failure over one unexplained readiness score.
  3. **Rerun after repair** Use the same fixture and authoritative readback to distinguish a verified improvement from a different path or favorable one-off run.

7. Adjacent tools should turn this decision into executable evidence

The useful adjacent tool is not an acronym quiz. A proposed Agentic Commerce Path Mapper should accept a business model, current commerce platform, provider, target agent surfaces, countries, product or resource type, and consequence level. It should return source-linked candidate paths, explicit unknowns, and the test fixtures required before adoption. It must not claim enrollment, compatibility, or availability that it cannot inspect. The currently available LaunchBuddy public scan can establish website discovery, semantics, commerce facts, and safe-action signals, but it cannot certify a live UCP, ACP, or MPP transaction. AW6 AW7 AW8 AW18 AW26 AW27 AW28 AR6

A second proposed tool is an Agentic Checkout Sandbox Runner that executes a merchant-approved fixture to the review boundary and, only in test mode, through payment and backend receipt reconciliation. Results should keep catalog, browser, protocol, credential, payment, order, and fulfillment evidence separate. Those outputs could later feed responsibly bounded comparisons in the Agentic Customer Journey Index and opt-in leaderboard cohorts. Until those tools exist, this article remains source-backed analysis and a test design, not a claim that LaunchBuddy has observed these protocols across live merchants. AR7 AR8 AR9

  1. **Run the public baseline** Use the available LaunchBuddy scan to find discovery, product-fact, policy, semantics, and safe-action gaps before integrating a commerce protocol.
  2. **Create a protocol test plan** Use the proposed mapper to turn official documentation and business context into explicit implementation and evidence requirements.
  3. **Require sandbox proof** Do not publish transaction success until a test run reconciles the approved target, payment, order or resource, receipt, and recovery state.

Your next step

UCP, ACP, and MPP belong to the same agentic-commerce landscape, but they serve different distribution and transaction paths. UCP and ACP define open approaches to agent-mediated consumer commerce, while MPP addresses machine-native payment for programmatic resources. A business should begin with the customer or agent job, select the smallest supported protocol set, and test the entire chain from current facts to authorization, payment, authoritative outcome, and recovery. Protocol support is useful evidence. It is not proof that an agent chose correctly, paid safely, received what it bought, or can recover when the network is uncertain.

Use a relevant LaunchBuddy tool, find a practical resource, or run a free launch scan. Choose the next step that matches the problem you are working on.

Sources and review context

Related LaunchBuddy resources

Stripe Link Wallet for Agents: Can an AI Agent Pay on Your Website?WebMCP Explained: Should Your Website Expose Tools to AI Agents?Google Added Agentic Browsing to Lighthouse: What It Measures—and What It MissesHow to Test an AI Agent After Login Without Exposing Customer Data
UCP vs. ACP vs. MPP: Which Agentic Commerce Standard Does Your Business Need?