Is UCP v2026-08-25 backward compatible?

Not entirely. The official release labels several changes as backward-incompatible, including fulfillment restructuring, namespace changes and parts of the payment and identity model. An implementation should compare its generated types and payloads against the release, not rely on the summary alone.

Does the August release mean UCP is live for grocery, food and lodging?

No. The release says it prepares the architecture for multiple verticals and adds grocery and location building blocks. UCP also says detailed Food and Lodging specifications are coming. Neither statement proves a shopper can use those verticals on a given surface today.

What was the April release mainly about?

The April release expanded the shopping foundation: Cart, Catalog Search and Lookup, Order operations, identity linking, request signing, attribution, errors and richer payment and fulfillment contracts.

What is the most important August change for a merchant?

It depends on the implementation. Grocery merchants gain location, operating-hours and fractional-quantity primitives. Payment teams gain 3DS2 actions, request constraints, split instruments and payment schedules. Every existing integration should first assess the breaking schema changes.

UCP April to August 2026: Release Diff

Short answer: UCP moved from a broad shopping foundation in April to a more mature, multi-vertical transaction model in August. The 8 April release added Cart, Catalog Search and Lookup, Order operations, OAuth-based identity linking, request signing, attribution and first-class error handling. The 25 August release reorganised the protocol for multiple industries, added grocery and location primitives, introduced 3DS2 actions and transaction-specific request constraints, expanded payment schedules and split payments, and rebuilt parts of identity and consent. It also contains breaking changes. This is a schema migration, not a routine content update.

The April baseline

The official v2026-04-08 release was already much more than checkout. It added the primitives needed to discover products, build a basket, link an identity, retrieve an order and explain failures. The release also introduced request and response signing, abuse and authorisation signals, eligibility claims, referral attribution and a richer totals contract.

That combination matters. Catalog and Cart gave agents something to shop with. Identity Linking and signing gave implementations a way to establish continuity and integrity. Order and attribution connected the agent interaction to the merchant's existing commercial workflow.

What changed by 25 August

Area	April 2026	August 2026	Operational effect
Architecture	Shopping capabilities and shared protocol services	Common, Shopping and Payment domains, with vertical-agnostic payment constructs	Generated clients, namespaces and imports may need to move
Verticals	General retail catalog, cart, checkout and order	Location Search and Lookup, operating hours, pickup context and fractional quantities	Grocery and location-aware fulfillment become representable
Authentication	Request signing, OAuth identity foundation and reauthentication	Actions primitive, 3DS2 flows, Web Bot Auth interoperability and canonical profile keys	Out-of-band authentication can be requested inside a transaction flow
Payments	Available instruments and payment-handler configuration	Split instruments, deposits, installments, deferred terms and separated PAN/network-token credentials	Payment negotiation can model more than an immediate single-instrument charge
Consent	Identity linking and capability-driven scopes	Extensible, reverse-DNS buyer-consent purposes and delegated identity providers	Consent can be expressed by purpose rather than fixed flags
Policies	Return-policy links and order data	Policy snapshots for returns, refunds and warranties on commercial objects	An agent can receive the terms that applied to the transaction state
Versioning	Dynamic versioning guidance	Independent capability versioning and a tighter release contract	Clients need capability-level negotiation, not one global version assumption

Three changes that alter implementation work

1. The protocol is no longer organised around shopping alone

The August release moves common types and payment extensions out of shopping-specific paths. It also introduces polymorphic token binding so a payment construct can work across more than one vertical. The release describes this as a foundation for Food and Lodging alongside Shopping.

Limit: architectural preparation is not deployment. The official UCP site still says detailed Food and Lodging specifications are coming. A merchant should not advertise support for those verticals solely because the common types now exist.

2. Payment is becoming a negotiated sequence

The new Actions primitive lets a merchant ask a platform to perform a step outside the immediate request, including 3DS2 device-data collection or a challenge. Response-carried request constraints let the merchant specify transaction-specific rules for the next request. Payment schedules add deposits, installments and deferred terms, while split payments allow more than one instrument.

These features change the integration question from “can the agent send a token?” to “can both sides negotiate the next valid action and preserve the resulting state?”

3. Identity, consent and policy become transaction data

April established an OAuth 2.0 foundation. August adds delegated identity providers, canonical signing keys and consent values keyed by purpose. It also places policy snapshots on Cart, Checkout, Catalog and Order objects. That makes consent and applicable terms inspectable parts of the protocol exchange.

Limit: a protocol field does not establish that a consent flow is legally sufficient in a particular jurisdiction. It records data and relationships. Legal effect depends on the implementation and applicable rules.

Migration questions for an existing UCP implementation

Which April namespaces, generated types or schema paths does the integration import?
Which August changes are marked breaking in the official release?
Does capability negotiation happen at the right version granularity?
Can the client process Actions and transaction-specific request constraints?
How are 3DS2, identity-provider delegation and buyer consent surfaced to the user?
Are return, refund and warranty policies snapshotted with the transaction?
Do tests cover split instruments, deposits, pickup, fractional quantities and time-zone-aware hours where relevant?

Start with the release notes, then diff the exact schemas your integration uses. This article groups changes by operational concern; it is not a substitute for generated-type and conformance testing.

What this release does not prove

It does not provide a merchant count, shopper count, transaction count or geographical deployment figure. It does not show that every named UCP supporter implements the August version. It does not prove that grocery, food or lodging checkout is available on a particular consumer surface. Those claims require separate product or adoption evidence.

For the broader context, see the six-month UCP review, the ACP vs UCP comparison and the merchant readiness guide.

UCP April to August 2026: the release diff