On August 25th the UCP Technical Council shipped v2026-08-25 — 68 closed items, 17 of the merged pull requests flagged breaking, and the largest structural change the protocol has had.

The April release was the one where UCP stopped being a checkout-and-order protocol and started becoming a commerce platform. This is the one where it stops being a shopping protocol.

Here's what changed, what it breaks, and what the first day of adoption actually looks like.

#The headline: UCP is no longer shopping-shaped

The centrepiece is a structural refactor (#723, #736, #741, #761) that lifts the payment constructs out of shopping/ and into the cross-vertical common/ group, and moves shared primitives into common/types/.

That sounds like housekeeping. It isn't. Until this release, everything in UCP lived under shopping, because shopping was all there was. Payment constructs were shopping constructs. Token binding assumed a checkout session existed. A lodging or food vertical would have had to either fabricate a cart or fork the protocol.

Now payment lives under dev.ucp.common.payment.* rather than inside shopping, token binding is vertical-agnostic — a flat {type, id} pair that any capability can use — and the shared types sit where a Food or Lodging council can reach them without touching Shopping.

The Food and Lodging Technical Councils were seated over the summer. This release is the room being made for them.

#Location becomes a first-class capability

The most visible new surface is Location Search and Lookup — dev.ucp.common.location.search and dev.ucp.common.location.lookup. Agents can now find a business's physical locations and retrieve their details: address, geocoding, amenities, and deterministic operating hours with real timezone handling, including exception days.

Note the namespace: common, not shopping. Locations aren't a shopping feature. They're the thing that makes click-and-collect, restaurant pickup, and hotel properties expressible at all.

We wrote up what the Location capability was shaping up to be on July 1st, while it was still a proposal opened in June — the missing where primitive, alongside the what and the how every earlier capability answered. What shipped is recognisably that, with the geofencing debate resolved narrowly: geodata is restricted to search filters on the request and excluded from response objects.

This is also the release that makes the local verticals expressible rather than theoretical. It's the piece restaurants and hotels were missing — we tested what lodging would need back in May and the answer was always a place primitive — and it lands with the Lodging Technical Council seated in August to build on top of it.

Alongside it, fulfillment now connects to location context across Catalog, Cart and Checkout, and destination types are explicitly tagged as shipping or pickup rather than inferred from an ambiguous union.

#Fractional quantities

Groceries broke a quiet assumption: that you buy things in whole numbers. #597 and #653 upgrade quantity from a strict integer to either an integer or a structured measure — so 1.4 kg of apples is now a thing an agent can put in a cart, priced on a defined sale basis with declared step sizes.

If you sell anything by weight or volume, this is the release that makes you expressible.

#3DS, without a vendor

Payments got the security layer it was missing. #458 implements vendor-agnostic 3D Secure — device data collection and challenge flows — built on the new Actions primitive, a horizontal actions[] array that lets a business ask the platform to perform something out-of-band and return.

That matters beyond 3DS. Actions is the general mechanism for "I need the buyer to do something before I can continue," and step-up authentication is just its first use.

Also landing: payment terms and schedules (deposits, deferred payment, instalments), split payments across multiple instruments, and response-carried request constraints — a business can now return validation rules that apply to your next request, rather than the protocol trying to enumerate every case up front.

We covered both of these as they landed in mid-August, while they were still merging. The argument there holds up: discovery was never the hard part. Finding a product and reading a price is the easy half — the step-up challenge from the issuer, the pay-in-four the merchant wants to offer, the deferred obligation that has to survive to the receipt. That's where real checkouts get messy, and this is the release where the protocol stopped leaving it to the platform.

#What breaks

Seventeen merged pull requests are flagged breaking, grouped into eleven themes in the release notes. The ones most likely to bite:

One capability changed namespace. dev.ucp.shopping.ap2_mandate is now dev.ucp.common.payment.ap2_mandate.

One clarification worth making, because it changes what you have to do. The release notes group split payments and payment terms with it as payment extensions migrating out of dev.ucp.shopping.*. Comparing the two released artifacts directly, 2026-04-08 defines ten capability namespaces and contains neither — both were built during this cycle and relocated before the tag was cut. They arrive as new capabilities rather than moved ones, so there is nothing to migrate.

AP2 mandate is the only rename that can break a live integration, and it's the one to check for. If anything you own keys off the old string — a validator, a dashboard, an analytics pipeline — it will silently find nothing rather than error.

signing_keys[] is gone. #566 removed it from the profile schema entirely and promoted keys[] (a JWK Set) as the sole canonical field. Not deprecated — removed. If you publish signing_keys while declaring 2026-08-25, you're declaring a field the release deleted.

Buyer consent is no longer booleans. #451 restructures consent from fixed boolean flags into a dynamic map keyed by reverse-DNS identifiers (dev.ucp.consent.*) carrying granular per-segment purposes.

Fulfillment config was consolidated. merchant_fulfillment_config.json is deleted, flags dropped their allows_ prefix, description became a structured object, and multi_destination went from a map to an array.

Versions must now agree. A profile declaring ucp.version D must declare version D on every dev.ucp.* service, capability and extension entry — and a platform encountering one that differs must reject that entry outright, treating it as absent. Third-party namespaces (com.{vendor}.*) are explicitly exempt and version independently.

That last one is the change most likely to remove a capability from an agent's view without anyone noticing, because the failure mode is silence.

#Day one, measured

Here's the part you can't get from a changelog.

We re-check every verified store in our index daily, so we can say what the ecosystem actually looked like the day this shipped. Across more than 15,000 verified UCP stores:

• 99.8% were on the previous release, 2026-04-08.
• Nobody had moved to 2026-08-25 yet. Our own manifest declares it — we adopted the day it was tagged — and we don't count ourselves in adoption figures.
• A handful were still on January releases, and two declared version strings that have never existed.

That's what a protocol release looks like at t=0: the vocabulary grows the moment the tag is cut, and adoption is a separate curve entirely. Watching that second curve is the job. We're the measurement layer for it — every verified store is re-checked daily, so each one gets recorded as it transitions, at whatever point it's ready.

The April release makes the point better. Six months on, its headline capabilities are still barely declared.

To be precise about what follows: these are capabilities declared in a store's manifest, not capabilities observed working at runtime. Declaring one is a statement of intent, and the two are not the same number — which is rather the point of checking.

The transactional core is near-universal. Everything above it is a long tail. This release adds eight more capabilities on top of a layer the ecosystem has largely not reached yet — which is the honest context for any "UCP now supports X" headline, including ours.

Which is the useful part, and it cuts three ways.

Check a store against 2026-08-25 today. We took the new version the day it was tagged, so you can find out whether a manifest still passes before migrating rather than after — including against the two silent failures above, the AP2 rename and the version-match rule.

Test it before it reaches production. The validator takes pasted JSON during development, and the dashboard scores staging alongside production, so drift surfaces while it's still cheap to fix. A version migration is a small edit with a silent failure mode — much better caught in staging than in an agent's error log, and catching it there is what makes the transition quick rather than fraught.

Or hand the loop to an agent. Our agent-ready skill drives check → fix → re-check against the keyless API, so a coding agent can take a store from failing to conformant without anyone reading the spec end to end. It reads the current version from ucp.dev on every run, so it picked up 2026-08-25 the day it landed.

And the adoption curve gets observed rather than reconstructed. The move from nobody to whatever this release reaches is recorded as it happens, store by store — so nobody has to estimate afterwards how long the ecosystem took, or guess which capabilities were picked up and which were ignored. It's the same record that lets us say, six months on, that identity linking sits at a tenth of a percent.

There's a second thing the index sees: stores declaring namespaces under dev.ucp.* that the specification has never defined. Invented verticals, misspellings of real capability names, and namespaces from proposals that were closed without ever being merged. Namespace governance reserves dev.ucp.* for capabilities sanctioned by the governing body — vendors are required to use their own reverse-domain namespace — so these aren't early adoption, they're drift. We now label them as such rather than listing them alongside the real thing.

#What we changed

We adopted 2026-08-25 the day it was tagged.

• The validator accepts the new version and validates against its rules.
• The capability directory carries the eight new namespaces, and separates capabilities the spec defines from ones merely declared.
• The protocol tracker and spec versions show the new release from day zero, at zero adoption — because "released, nobody has moved yet" is a real state and worth being able to see.
• Our own profile at /.well-known/ucp declares 2026-08-25, publishes keys[] rather than the removed signing_keys[], and serves a genuine self-contained profile for the previous version at its own URL.

That last one is the part we got wrong first. Our profile advertised backwards compatibility by pointing every supported version at the same document — which cannot be true of more than one version at a time. If you run a validator, check your own manifest against it. We did, and it found something.

#What to do

If you run a store: you don't have to move. The transactional core is unchanged, and 2026-04-08 remains a supported release. When you do move, declare it properly — the version must match on every dev.ucp.* entry, and signing_keys has to become keys.

If you build agents: the capabilities you can rely on are still checkout, catalog and cart. Design for Location and fractional quantities now, but don't assume them.

If you build tooling: the namespace move and the version-match rule are both silent failures. Neither throws — they just make things disappear.

UCP Checker is an independent validator for the Universal Commerce Protocol — the canonical reference for which stores are agent-ready, observed continuously rather than self-reported. You can check any store against 2026-08-25 at UCPChecker.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats and the authority-bound vendor map, and track the spec as it evolves so you don't have to. For agents and developers, the docs put all of it behind one keyless MCP server and API. For businesses, the UCP Checker app turns the one-time check into continuous observability — daily conformance monitoring against the live spec, break alerts the moment agent access degrades, and benchmarking against the stores you compete with — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

• Connect your agent (docs): ucpchecker.com/docs
• Check your store: ucpchecker.com/check
• Grade it (UCP Score): ucpchecker.com/score
• Monitor it continuously (UCP Checker app): app.ucpchecker.com
• Track the spec: ucpchecker.com/protocol-tracker · spec versions · capabilities

#Sources

• UCP v2026-08-25 release notes
• Full changelog, v2026-04-08 → v2026-08-25
• Universal Commerce Protocol specification
• Spec version adoption — ucpchecker.com/specs
• Capability directory — ucpchecker.com/capabilities
• API & MCP documentation — ucpchecker.com/docs
• Related coverage: UCP v2026-04-08 spec update