Compare one purchase instead of two marketing narratives
Use the same product, buyer constraints and fulfilment outcome on both sides. Our fictional merchant Cedar sells a current research report with a personal-use license for an illustrative $29. Sam authorizes one purchase up to $35. The comparison asks how each route preserves the item, current total, authority, payment and report access.
The question is not which protocol sounds more universal. The merchant needs a supported route to the intended shopping surface and a manageable connection to existing services. The right choice can depend on channel requirements, product behavior, supported payment mechanisms and the capabilities your store already exposes.
Read the matrix as a scope comparison checked against current documentation on October 8, 2026. It avoids guessed field equivalence. A checkout session in one contract should not be mechanically renamed into another without examining its validation, version and extension rules.
One illustrative cart through two routes
Scroll the table to compare all columns.
| Business step | ACP merchant contract | UCP architecture |
|---|---|---|
| Same synthetic cart | One personal report $29 + illustrative addition $2 = USD $31 | The identical report, license and USD $31 total |
| Identify the report | Use the selected channel/catalog route and item identifiers | Use supported discovery and catalog/capability route |
| Obtain current terms | Create or update the documented checkout session | Use the negotiated checkout capability and relevant extensions |
| Authorize the purchase | Use the applicable buyer authority and payment route | Use applicable authority and supported payment handler/mandate route |
| Complete | Follow documented completion and order response | Follow the supported negotiated checkout contract |
| Deliver and recover | Join order events to merchant fulfilment | Join order capability and merchant fulfilment services |
ACP’s merchant route starts with checkout sessions
OpenAI's Agentic Checkout specification documents create, update, complete, cancel and retrieve operations. The merchant returns current calculated session information, and the documented completion route produces order information. Merchant order notifications keep the buyer's view synchronized with the authoritative order. [1]
For Cedar, the adapter resolves the report identifier, calculates the current terms and reports missing customer input through the published contract. When completion is requested, the merchant uses its supported payment integration and commits the result under controlled business rules. The external session and the internal payment and delivery records remain distinct.
The documentation defines exact fields, status values, headers and event behavior. Implement those actual details rather than copying a simplified educational diagram into an API schema. Channel onboarding and the customer experience remain separate requirements from the ability to parse the contract.
UCP begins with discoverable capabilities
UCP describes a broader modular commerce architecture with business profiles, services, capabilities and payment handlers. The current technical overview places the business discovery profile at /.well-known/ucp and defines version and capability negotiation. Participants advertise the actual contract they can support rather than assuming a single unversioned interface. [3]
The current UCP overview includes catalog, cart, checkout, identity linking and order management capabilities. That breadth can help structure an integration beyond one checkout interaction. It does not imply that every deployed channel supports every capability or that the merchant must implement all possible extensions. [2]
For Cedar, the practical task is to advertise only the supported report-purchase operations, negotiate a compatible contract and connect them to the same authoritative pricing and order services. A profile that advertises more than the backing services can deliver would create a misleading route even if the document is syntactically valid.
Compare discovery and checkout ownership
ACP's checkout specification is a merchant transaction contract; do not assume it alone specifies every catalog distribution or search-ranking behavior. Your chosen channel and catalog route still determine how the product reaches the buyer. A valid checkout endpoint cannot make an unsuitable product automatically discoverable.
UCP includes discovery-oriented architecture and catalog-related capabilities, but discovery metadata still needs to be accurate and current. The merchant owns the product identity and commercial rules. A standardized interface does not repair a wrong edition, misleading license or stale availability value.
On both routes, the checkout should calculate the payable total using merchant services. If the report's product amount is $29 and a synthetic applicable addition is $2, the current total is $31. If a later total becomes $36, Sam's $35 authority needs a new decision. The arithmetic is illustrative and does not describe any provider fee or tax rate.
Compare authority and credential handling separately
The commerce contract and the customer's permission are related but distinct. A session with valid fields does not establish that the buyer approved the purchase. A recognized agent identity does not permit an unlimited charge. Preserve the connection between the final purchase terms, applicable authority and supported payment credential.
UCP's architecture includes payment handlers and compatible AP2 authorization. AP2 v0.2 defines linked checkout and payment mandates and verification duties. If your route uses that layer, implement the real mandate and verification contract. Do not present an informal consent record as an official cryptographic mandate. [3] [4]
For ACP, follow the documented payment_data and provider integration used by your supported route. Avoid inferring that every provider or token product has identical merchant, amount or expiry scope. Inspect the exact current contract and keep credentials within the protected handling boundary.
Compare the field and extension model honestly
The side-by-side table identifies documentation areas, not one-to-one field mappings. ACP's session fields and UCP's profile/capability structures answer different parts of the integration. A merchant implementing both should preserve a shared business model while maintaining protocol-specific adapters.
Do not publish a guessed conversion dictionary that silently loses important terms. If one route carries a supported fulfilment extension or required authority context, the other route needs its own valid representation or a clear unsupported outcome. A matching product identifier does not prove that the complete purchase contract was preserved.
Versioning needs the same care. Pin the ACP contract and UCP profile/capability versions used in your implementation. The dates shown in a documentation example are not a universal declaration that every participant supports that exact version. Use actual advertised and configured compatibility evidence.
Contract areas to compare
Scroll the table to compare all columns.
| Area | ACP reference point | UCP reference point |
|---|---|---|
| Discovery | Separate chosen catalog/channel integration | Business profile and supported catalog capabilities |
| Session terms | Checkout session schema and operations | Checkout capability and active extensions |
| Status | Documented session enum | Negotiated capability contract |
| Payment | Documented payment_data and provider route | Payment handlers and applicable authorization layer |
| Order updates | Merchant order webhook contract | Order capabilities and relevant integration contract |
| Version compatibility | Implemented API contract and version handling | Profile, protocol and capability negotiation |
| Extensions | Inspect the actual supported merchant contract | Explicit capability/extension architecture |
| Eligibility | Channel and platform onboarding | Channel and platform onboarding, separate from open spec |
| Documentation revision | Live checkout reference checked October 8, 2026; pin the implemented API version separately | Live technical overview checked October 8, 2026; pin advertised profile/capability versions separately |
Keep order and delivery semantics intact
The merchant must connect the financial result to a durable order and delivery record on either route. An assistant losing the final response should retrieve or resolve the existing purchase. It should not create another order solely because the conversation lacks a success message.
Paid-but-undelivered is a useful conceptual state in the merchant system, even when the external protocol uses different terms. Preserve the original order and recover fulfilment or apply the disclosed resolution policy. A protocol adapter should communicate the supported current state without inventing an external enum.
Keep outbound merchant order events distinct from inbound payment-provider events. Each event has a direction, schema and verification mechanism. A merchant statement to a channel is not independent proof that funds arrived; the appropriate financial system supplies that evidence. Use references to connect the records.
Separate Google and ChatGPT access from protocol support
Google's UCP merchant guide describes Native and Embedded paths and onboarding through a waitlist. Those commercial surface requirements are an additional layer to the open protocol. A merchant implementation can be technically compatible while still needing channel-specific access and product eligibility. [5]
ChatGPT shopping also has route-specific behavior. OpenAI describes conditional Instant Checkout, while Shopify currently documents its own ChatGPT referral path to the store checkout. That difference shows why channel and platform scope must accompany every availability claim. Do not use ACP support as shorthand for universal in-chat checkout. [6] [7]
Write down the actual merchant, country, product, currency and channel configuration for the comparison. Mark unanswered eligibility questions unknown. Do not infer worldwide access from the word universal or from a payment provider's general country coverage.
Decide whether one adapter or two are justified
Choose the route required by the first supported customer experience. If your priority channel requires a particular contract, that is a concrete reason to implement it. If you have a second channel with materially different requirements, a second adapter may be useful. Avoid implementing both merely to collect protocol logos.
Keep authoritative catalog, pricing, authority checks, payment operations and order services shared where the semantics truly match. Let each adapter enforce its own external schema and version. This boundary can make maintenance clearer than duplicating the entire purchase system for each protocol.
Estimate the ongoing work as well as the initial build. Each adapter needs compatibility checks, changed-term handling, retry behavior, event verification and operational support. A short prototype demonstration is not the full cost of maintaining a reliable merchant route.
- Which customer surface actually requires this contract, and is the merchant eligible?
- Which catalog, checkout, authority and payment capabilities does the product need?
- Can the adapter preserve the same item, license and current total without guessing a field conversion?
- Who owns retries, order events, delivery and support for each selected route?
Run the same acceptance cases through both routes
For Cedar, verify the same selected report, final terms, permitted action, financial outcome and entitlement. Then test changed total, unsupported item, incompatible contract, repeated completion, lost response and delivery failure. Record expected outcomes under each actual contract before running the tests.
A comparison can then state which requirements were documented, which were observed in the merchant configuration and which remain unknown. These recommended scenarios are not tests performed by this guide. Do not assign a performance or conversion advantage without actual comparable evidence.
ACP versus UCP becomes a useful merchant decision when it ends with a supported channel route and clear operating responsibilities. The protocols organize communication; the merchant still needs accurate terms, valid authority, consistent money records and delivery that can be explained after the purchase.