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

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. AgentReady 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.^{1, 2, 3, 4, 5}

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. AgentReady therefore treats protocol presence as one evidence layer rather than a universal readiness badge.^{1, 2, 3, 4, 6, 7, 5}

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.^{2, 8, 9, 6, 7}

For an implementation review, AgentReady 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.^{2, 8, 1, 6, 5, 10}

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.^{11, 3, 12, 1, 7}

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. AgentReady 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.^{11, 3, 1, 5, 10}

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.^{4, 13, 7, 5}

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. AgentReady 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.^{4, 13, 7, 5, 10}

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.^{1, 2, 3, 4, 8, 11, 13, 7, 5}

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.^{12, 1, 14, 15, 5}

AgentReady 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.^{16, 7, 5, 10}

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.^{5, 10, 17}

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 AgentReady public scan can establish website discovery, semantics, commerce facts, and safe-action signals, but it cannot certify a live UCP, ACP, or MPP transaction.^{1, 2, 3, 4, 8, 11, 13, 7}

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 AgentReady has observed these protocols across live merchants.^{5, 10, 17}