Audit catalogue truth, checkout, identity, payment, fulfilment and control readiness before committing an ecommerce store to UCP or ACP agentic checkout.
Short answer: A store is ready for agentic checkout only when an agent can discover accurate products, create a deterministic cart, quote the full payable amount, complete an authorised payment, and receive reliable post-purchase status without bypassing human consent or merchant controls. Audit those capabilities separately for UCP and ACP; a working web checkout alone does not establish protocol readiness.
Agentic checkout changes the integration boundary. Instead of guiding a person through every page, a merchant exposes structured catalogue and transaction capabilities that another system may call on the shopper’s behalf. The commercial promise is a shorter path to purchase; the operational risk is that stale inventory, ambiguous totals or weak authorisation can now travel through an automated path at greater speed.
Readiness is therefore not a single “yes” from engineering. It is a set of independently testable capabilities owned by catalogue, identity, checkout, payments, fraud, tax, fulfilment, support and security teams. CDM’s audit deliberately avoids a universal score. A store may be ready for cart hand-off but not native checkout, or ready for one protocol’s current surface without supporting another.
What the official evidence establishes
Google’s current UCP implementation overview describes two different paths: native checkout on Google surfaces and cart transfer back to the merchant. It also says UCP is evolving and that not every specification capability is available on Google surfaces. That distinction means a team must record both protocol capability and surface availability instead of treating “UCP support” as one binary field.
OpenAI’s ACP documentation describes an open connective layer for structured catalogue ingestion and contextual product discovery in ChatGPT. The documentation is the source for current ACP requirements; it is not evidence that every merchant, country, payment method or product category is live.
Both sources make structured product and transaction data central, but their activation paths, supported features and approvals can differ. CDM inference: the reusable investment is a governed commerce capability layer—clean objects, explicit states, authenticated actions and observable events—rather than protocol-specific branching scattered across the storefront.
The CDM UCP–ACP Capability Crosswalk
Score evidence, not confidence. Use “verified”, “partial”, “not verified” or “not applicable” for each row, attach the test artefact, and name the owner who can remediate it. Keep protocol requirements and merchant-policy decisions in separate columns.
| Capability | Evidence to test | Readiness failure | Accountable owner |
|---|---|---|---|
| Product truth | Stable IDs, variant relations, market price, availability and policy fields | The agent presents a valid-looking but unavailable or mismatched item | Catalogue / feed operations |
| Cart and quote | Deterministic line items, discounts, tax, shipping, currency and expiry | The payable total changes without an explained state transition | Checkout engineering |
| Identity and consent | Guest/account path, scopes, re-authentication and confirmation | An agent acts for the wrong customer or beyond the approved scope | Identity and security |
| Payment | Supported handler, token flow, fraud checks, failure recovery and idempotency | Duplicate charge, unsafe retry or unsupported method | Payments / risk |
| Order lifecycle | Order ID, acknowledgement, status, cancellation, return and support hand-off | Purchase succeeds but no dependable after-sale state exists | Order management / support |
| Observability | Correlation ID, consent record, input/output log and alerting | The team cannot reconstruct who requested what and which system acted | Platform operations |
How to run the UCP–ACP Capability Crosswalk
1. Choose the transaction boundary
State whether the intended experience is product discovery only, cart transfer, native checkout, or post-purchase servicing. Do not audit the broad phrase “agentic commerce”. A cart-transfer launch has different payment, identity and liability exposure from a native transaction, and the acceptance tests must follow that narrower boundary.
2. Freeze a protocol snapshot
Record the specification page, version or last-updated date, supported surface, market and merchant eligibility used for the audit. Specifications and product availability move independently. A dated snapshot prevents a later feature announcement from being mistaken for a capability that existed when the decision was made.
3. Trace one product through every object
Select a product with variants, limited inventory, a promotion and a non-trivial shipping rule. Follow its merchant SKU, feed identifier, protocol object, cart line and order line. Reconcile title, image, price, currency, variant, stock and return policy at each boundary. A happy-path item with one price is not a sufficient test.
4. Exercise state changes and failures
Change inventory after discovery, expire a promotion, decline the payment, retry a request, interrupt fulfilment and cancel an order. Verify that stale states fail safely and that repeated calls do not create duplicate economic events. Store the request, response, timestamp and resulting merchant record for every scenario.
5. Test human authority
Mark which actions may occur silently, which require confirmation and which must return the shopper to the merchant. Confirm that the user sees the item, final total, merchant identity and material terms before commitment. Test account switching and revoked permissions, not only a cooperative authenticated session.
6. Approve a limited release
Launch only the verified capability set, eligible products and supported markets. Define stop conditions for inventory mismatch, quote variance, duplicate orders, unexplained declines and missing lifecycle events. Assign protocol monitoring to an operational owner rather than leaving it as a one-time integration project.
Decision rules
The audit should turn evidence into a bounded go, hold or hand-off decision. A strong catalogue does not compensate for an unsafe transaction path, and a technically valid checkout does not compensate for unowned fulfilment failures.
| Signal | Decision | Evidence to retain |
|---|---|---|
| Price or availability differs across page, feed and protocol object | Hold the product; repair product truth before testing payment | Timestamped snapshots and identifier mapping |
| Cart can be created but full landed cost cannot be quoted | Allow cart hand-off only; do not enable native commitment | Quote tests by destination and payment path |
| A retry can create a second order or charge | Stop; implement and verify idempotency | Repeated-request test and economic-event log |
| Consent or account scope cannot be reconstructed | Hold authenticated actions | Consent artefact, identity event and correlation ID |
| Order acknowledgement works but cancellation or support routing does not | Limit pilot scope and disclose the servicing path | Lifecycle test, support runbook and named owner |
Build the evidence record before launch
Keep one evidence pack for the launch candidate. It should allow a reviewer to reproduce the decision without relying on a demonstration or a vendor slide.
- Protocol and surface snapshot, merchant eligibility and intended transaction boundary.
- Product-object mapping for at least one variant-rich item and one unavailable item.
- Quote fixtures covering price, currency, discount, tax, shipping and expiry.
- Authentication scopes, consent screens, confirmation states and revocation results.
- Payment, retry, idempotency, fraud and failure-recovery test results.
- Order acknowledgement, fulfilment, cancellation, return and support hand-off evidence.
- RACI, monitoring thresholds, incident route and rollback procedure.
Redact payment and personal data from the review copy, but keep tamper-evident references to the secure system of record. A screenshot is useful context; it is not a substitute for the underlying transaction and event logs.
Separate fact, CDM inference and the operating decision
Documented fact
Google documents native-checkout and cart-transfer UCP paths and cautions that the standard is evolving; OpenAI publishes ACP commerce documentation for structured catalogue and transaction integration.
CDM inference
A protocol-neutral commerce capability layer should reduce duplicated controls and make future integrations easier to test, but that architectural benefit must be demonstrated in the merchant’s own stack.
Operating decision
Enable only the narrow transaction boundary for which product truth, consent, payment safety, lifecycle handling and observability have all been verified under current surface requirements.
Worked example: a retailer that is ready for cart transfer, not native checkout
A fictional homeware retailer passes product-ID, inventory and promotion tests for a selected UK catalogue. UCP cart creation produces the same line items and currency as the product page, and the transfer preserves the cart when the shopper lands on the retailer’s checkout.
Native-checkout testing exposes two gaps: final delivery surcharges are calculated only after address validation in the legacy checkout, and a retried payment callback can create a second order record. The capability crosswalk therefore records catalogue and cart as verified, landed-cost quote as partial, and payment idempotency as not verified.
The operating decision is a limited cart-transfer pilot. Native checkout remains off until surcharge calculation is exposed deterministically and duplicate-order tests pass. That is not a failed agentic-commerce programme; it is a controlled boundary supported by evidence.
Limitations and review boundary
Protocol documentation and surface support can change quickly. Re-run this audit against current provider documentation and test environments before each launch. Availability in documentation is not the same as merchant approval, geographic availability or production reliability. The article does not compare commercial terms or predict conversion impact.
Payment, privacy, consumer, accessibility and sector rules vary by market and implementation. Security and legal specialists must review the final design. A passing audit shows that defined tests passed under recorded conditions; it cannot prove the absence of every failure or fraud strategy.
Related guides
Frequently asked questions
Does a working ecommerce API mean the store is ACP- or UCP-ready?No. A general commerce API may omit protocol objects, capability discovery, signature or authentication expectations, deterministic quote states, supported payment handlers or lifecycle events. Map the current protocol requirements to the API and prove each state with tests.
Should we implement UCP and ACP at the same time?Not automatically. Build common product, cart, identity, transaction and observability capabilities, then evaluate each surface separately. Parallel launches increase the change surface and can hide whether a failure belongs to shared merchant logic or one protocol adapter.
What is the minimum viable agentic-checkout pilot?A narrow market and product set, explicit transaction boundary, reconciled catalogue, predictable quote, safe identity and payment flow, observable order lifecycle, named support route and tested rollback. “Minimum” should reduce scope, not remove controls.
How often should the capability audit be repeated?Review protocol and surface requirements monthly while specifications are moving, and rerun transaction tests after material changes to catalogue, checkout, identity, payment, fraud, tax or order-management systems.
Does protocol readiness guarantee more sales?No. Readiness is an operational and risk assessment. Demand, product relevance, placement, user trust and the provider’s experience affect outcomes. Measure exposure, completed transactions, failure rates, margin and support cost separately.
Method and publication status
This prepublication draft was researched from the primary materials linked at the claims they support and checked on 12 October 2026. It requires the named specialist review, live-product retesting where indicated, a real 16:9 editorial image and final URL verification before publication. It is operational analysis, not legal, security or compliance advice.
This article is editorial guidance. Apply the principles in proportion to your market, evidence, and responsibilities.
