UCP readiness audit
in four phases.

What the mapping phase actually looks for

The grid is not arbitrary. It follows what the UCP specification asks a merchant to publish. A readiness audit is the exercise of holding your current setup against those requirements, one by one.

The profile and capability negotiation

UCP works by negotiation: a business publishes a profile describing its capabilities and services, and the platform discovers dynamically what it can do with that business. So the audit asks less "do you have an API" than "what are you declaring you can do, and is it true". Capabilities are named using reverse-domain notation, which lets any player add an extension under its own namespace with no central approval committee. Decentralized governance, then, but it assumes you know what you are declaring. Established

Transports

The specification defines services in REST and JSON-RPC, and supports several transport layers for interoperability. The audit question is not "which should we pick" but "which can our stack expose without a rewrite". That is usually where the gap between a three-week project and a six-month one is decided.

Checkout and its breaking points

A checkout session exposes a status that drives the agent, through incomplete, requires_escalation, ready_for_complete, complete_in_progress, completed and canceled. Errors are graded by severity: recoverable, requires buyer input, requires review, or unrecoverable.

Here the audit maps your real breaking conditions, the ones your teams know and nobody wrote down: age verification, signature thresholds, delivery zones, prescription-only products, pricing exceptions. Each has to find its place inside requires_escalation rather than break the journey. It is the most useful output of phase I, and the one merchants most consistently underestimate.

Payment: instruments and handlers

UCP separates payment instruments from the handlers that execute them. That separation is what lets a merchant change provider without renegotiating its agentic integration. The audit checks whether your current chain supports that distinction, or what it would take. Established

Two framing points save months of pointless committee debate. The Merchant of Record does not change: you remain the seller. And the Checkout capability introduces no PCI DSS compliance obligation for card payments. The question "do we lose control of the transaction" has a written answer, and it is no.

Eligibility and the autonomy dial

UCP provides for eligibility verification: claims must be resolved before a transaction completes. That is the mechanism behind contract pricing, geographic restrictions and customer-specific terms. The audit inventories what you condition today, and whether it is expressible.

Finally, the autonomy dial sits in exactly one place: an order must be finalized manually by the user through a trusted UI, unless the AP2 Mandates extension is supported. A merchant targeting automatic replenishment needs AP2 mandates. A merchant targeting assisted discovery does not. That call, made in phase III, changes the cost of the project threefold. Established

Sources: UCP specification overview and Checkout capability, version 2026-04-08. For implementation, see the implementation guide and the use cases by business type.