MapGraphSeamsCalendarIntroductionDisclosureMethodFor agents and tools

Updated weekly, new versions on Mondays · Corrections: open an issue

Universal Commerce Protocol (UCP)

Industryspecificationcore entry

Verified 2026-10-14. Status as of 2026-10-14. All entries.

Seams: S1S2S3S4

Status

Latest GitHub release v2026-08-25 (2026-08-25); lodging booking draft merged 2026-09-24 (PR #780); the Common capability ask merged 2026-10-07 (PR #538); feed and subscription policy in draft (PR #866, PR #890); the food checkout proposal (PR #897) is under review (open on 2026-10-13). On 2026-10-13 main is at commit 9756aa9 (2026-10-12) and no release is listed after v2026-08-25. Governance and extension items filed 2026-10-09 to 2026-10-11, read 2026-10-13: issue #922 "[DTC Charter]: Local Services" (DTC: Domain Tech Council; labels Triage and gov:needs-gc-review, no comments) proposes a Domain Tech Council for appointments, group sessions, reservations and rentals, defined by "real-time slot computation over staff and resource calendars, with holds", leaves lodging, food, payments and shopping to the councils that own them, and says of three earlier proposals (#317, #303, #479) that "none has a home council"; the platform it lists is "Meta" and the businesses are "Wix, Housecall Pro, Squarespace, Jobber, HoneyBook, Stripe, Shopify". Issue #924 "Domain Working Group (DWG) Charter: Agentic Donations" (same labels, no comments) names the Shopping Tech Council as sponsor and a proposed chair from Stripe, asks for nominations by "October 23, 2026" and targets "November 2, 2026" for the initial package; "Merged PRs and production launches are not required for the DWG to close." It mentions the Donor Agent Protocol of GoFundMe, whose site gofundme.github.io/donor-agent (read 2026-10-13) is headed "Donor Agent Protocol (DAP) v0.1" and "An Evidence-First Donation Layer"; a repository for it is not found (gofundme/donor-agent, HTTP 404, 2026-10-13). Issue #929 (opened 2026-10-11, one comment besides the author's) proposes the extension dev.ucp.common.quote, described as "a one-quotation-at-a-time loop, not a negotiation protocol", with draft PR #930 as reference implementation ("not requesting merge before #929 reaches Provisional"); an accepted quotation appears in totals and on the Order as the quotation id and its subtotal only. A comment of 2026-10-11 calls it "a useful candidate for the narrower case of a Business-issued, price-only quotation accepted by reference into Cart/Checkout". PR #933 (open, one commit, 2026-10-11) says it "spells out which redirect codes are actually banned (301/302/303/307/308) and says 304 is fine, on both the hosting and fetching side"; PR #932, which proposed the same clarification, was closed on 2026-10-11, two minutes after it was opened, by the account that opened it. PR #897 (food) is still open on 2026-10-13 (head 1e2818c). Discussion #931 (2026-10-11, no comments) asks whether ucp.dev could list community implementations and names one open-source implementation, Portage, described there as an MIT-licensed agent command-line interface and a set of merchant-side Ruby gems; it is noted here and not evaluated. The Shopify/hydrogen pull request #4158 on the UCP profile route is open, not merged (2026-10-13), and is not counted.

Relevance

The AP2 mandates extension says businesses must "embed a cryptographic signature in checkout responses, proving the terms (price, line items) are authentic" and platforms provide mandates "proving the user explicitly authorized the specific checkout state and funds transfer". The Order page calls the entity "the authoritative latest state of the order at the time of retrieval or delivery", where webhook payloads "be signed by the business and verified by the platform". Terms travel in policies[] (PR #572, merged 2026-07-23), where the business states rules such as a refund window; the PR says "Policies never force display." On agent identity, the signatures page (PR #483, merged 2026-07-03) says a dual-audience signature "is the RECOMMENDED path for integrators" who want interoperability with Web Bot Auth verifiers; that interoperability is request-scoped.

A food domain (dev.ucp.food.checkout, food.fulfillment) was proposed on 2026-10-03 for early feedback (PR #897, opened by a participant "On behalf of the entire Food Domain Tech Council"; its label on 2026-10-05 was status:needs-triage and on 2026-10-09 and 2026-10-13 is status:under-review, with gov:needs-tc-review and 12 comments on 2026-10-13).

A proposal to authenticate the platform client through attestation (issue #852, opened 2026-09-22) was described by its author on 2026-10-04 as "now ready for Technical Council review". Issue #375 (2026-05-29) declined external place identifiers in the core schema: "Adding specialized reconciliation mappings to the core schema is a premature optimization." The Common capability dev.ucp.common.ask was merged on 2026-10-07 (PR #538; commit a41a2dc).

Its page says "The Ask capability provides natural-language Q&A about a Business's resources, policies, and services." and "ask is the open-question complement to UCP's structured commerce capabilities". Two rules of its text: "A Business MUST NOT change the state of any resource exposed through another UCP capability or extension in response to an ask request." and "An answer is indicative, not authoritative."; where an answer conflicts with the representation returned by the capability that owns the resource, "that representation is authoritative and the Platform MUST prefer it", and "A Platform MUST NOT treat an answer as the binding disclosure for a safety, allergen, or regulatory claim." The page lists as typical use cases product questions ("fit, materials, compatibility, comparisons"), policy questions ("returns, shipping, warranty, refunds"), FAQ and how-to ("store hours, shipping timelines, accepted payment methods") and clarification about a specific resource, grounded in an identifier.

The description of the pull request, not the specification, lists "policies, fit and suitability, materials, compatibility, amenities, support information, and Business-specific knowledge". The merge adds docs/specification/common/ask/ (index, Representational State Transfer (REST) and MCP bindings), docs/specification/shopping/ask/index.md and source/schemas/common/ask.json; text read at commit f2206e6 (the head of main on 2026-10-09; on 2026-10-13 main is at 9756aa9, and a git diff of the two commits shows no change to the overview, AP2 mandates, signatures, order, ask and lodging pages cited here).

Pull request #811 (opened 2026-09-07 by a participant, open; among its labels on 2026-10-09 status:stale-review and gov:needs-tc-review; no comment or review; state and labels unchanged on 2026-10-13) proposes an optional offers[] array on the catalog variant "so one catalog can list a product sold by several different merchants and send each to the right seller's checkout". Each offer names its seller by seller.domain, the Merchant of Record, with the seller's own item_id and an authoritative price; the proposed schema text describes the domain as "The seller's canonical host: a bare hostname without scheme, path, port, or trailing slash" and adds "A Platform resolves this host to the seller's UCP profile at /.well-known/ucp and verifies its signing keys via authority binding." The overview page uses "canonical" for the host that serves a schema (lines 158 to 164); which of the bare and the www host is canonical for a profile is not found in the overview page at f2206e6 nor in the five files of the pull request (2026-10-09).

The overview page says, in Profile Requirements, Hosting, item 2, "Profile endpoints MUST NOT use redirects (3xx)." (line 1466) and, in the rules for any URL dereferenced during identity resolution, item 2, "Implementations MUST NOT follow redirects (3xx)." (line 1514); line 182 applies the same rule to schema URLs (file at commit f2206e6 of 2026-10-07; unchanged at 9756aa9 on 2026-10-13).

Items 3 and 4 of Hosting ask for a Cache-Control with public and a max-age of at least 60 seconds, and for a validator (ETag or Last-Modified). A registration request for ucp has been open in the registry's repository since 2026-06-06 (issue #92), labelled "waiting for input" since 2026-07-11, when the designated expert asked for an e-mail address for the change controller (read 2026-10-14).

The profile rule first appears in commit 0426800 of 2026-02-17, "feat: signing for UCP requests & responses (#156)". The author of the census reported in issue #904 (2026-10-07, 2026-10-08) and Discussion #867 (comment 18810486, posted 2026-10-08) a census of 225 hosts probed from Seoul, one route and one attempt per host, 3xx not followed.

Version of 2026-10-08, read in the edit history of the comment (figures declared by the source, not verified by this map): 62 positives (200, parses as JSON, ucp.version present), of which 58 Shopify and 4 not identified; declared versions 2026-08-25 (58), 2026-04-08 (3), 2026-01-23 (1); signing keys published by 0 of 62; the other rows: 1 refused by robots.txt, 7 responses 200 that did not parse, 12 3xx at the profile path, 65 404, 2 410, 59 403, 3 429/418/503, 14 connect, timeout or TLS failures.

The author states "Not a random draw": a hand-built list of well-known storefronts plus the WooCommerce showcase, heavily Shopify-skewed, so the rate is not an adoption estimate; all figures declared by the source, not verified by this map. Four of the 62 positives have a home page answering 403 or 429 while the profile path answers 200 (comment of 2026-10-07, where the hosts are named).

The author reports that probing the host as written gave 60 positives and 23 3xx, and that resolving the canonical host first gave 62 and 12. In the frame of #867 the 62 is "row 2 and ucp.version present", that is a floor on row 2 as the frame defines it (parses as JSON), with rows 3 and 4 not measured; the author of this map replied that the 7 non-parsing 200s are row 1 without row 2, whereas the run lists them among the cases it "could not ask". In Discussion #864 (Lodging), a participant who operates a small property asked on 2026-10-07 how a platform finds a property that is not in a global distribution system (GDS), a chain central reservation system (CRS) or a channel manager feed; the author of this map replied on 2026-10-08 that "today a property-hosted profile is necessary but not sufficient", and the same participant asked whether platforms will discover a profile on the property's own domain or receive lodging inventory only through connectivity partners; no maintainer reply was found among the discussion's six comments, the last of 2026-10-08 (read 2026-10-13).

The lodging booking page says a platform "MUST supply valid property.id, and either a pre-composed stay.id OR both accommodation_type.id and rate_plan.id identifiers sourced from upper-funnel discovery mechanisms" (lines 426 to 428, commit f2206e6); the location_summary schema describes id as "Stable, opaque, Business-scoped Location identifier." Issue #678 (buyer consent at complete_checkout) was closed on 2026-10-07 with the merge of PR #883, and issue #666 (permalink and authenticated buyer session) the same day with the merge of PR #789, "require explicit buyer action before cart merge". In PR #691 (price_treatment, open) the author wrote on 2026-10-07 that after dropping not_asserted "an absent price_treatment and an absent tax now mean the same thing everywhere". WooCommerce PR #69577 (open, draft on 2026-10-08) adds UCP catalog routes for search, lookup and product, implementing spec version 2026-04-08, off by default behind the woocommerce_ucp_enabled filter.

Known Good posted in Discussion #867 on 2026-10-08, with the figures of https://knowngood.sh/standard/ucp, a run of 2026-09-26 to 2026-09-28 from AWS us-east-1 with robots.txt honoured and the user agent KnownGood-Verifier/0.3 (figures declared by the source, not verified by this map). Its population is 92,541 hosts that its crawl was allowed to ask, from its own index, "not a draw from storefronts". Rows of the frame as reported: HTTP 200 on 45,362 hosts (44,118 at the first request and 1,244 after a redirect), parses as JSON on 42,757, row 3 not measured ("Row 3 is empty on purpose."), and a protocol response (tools/list on the MCP endpoint named by the profile) on 41,424.

By endpoint domain: myshopify.com 31,568, wixapis.com 9,782 and three singletons; "Merchant count 41,424; decision count 2" (two tool signatures cover 41,352 endpoints). The Known Good page says "Shopify and Wix advertise the MCP endpoint they run for every store through this profile". No page of Wix on UCP support was found (two searches, 2026-10-09), so Wix is a platform observed by Known Good only.

The run follows 3xx at the profile path ("3xx followed up to 2 hops, https only, same registrable domain only"): 2,546 3xx, 2,188 followed, 1,244 ended in 200, and 286 cross-domain 3xx not followed; line 1514 of the overview page reads "Implementations MUST NOT follow redirects (3xx)." The 1,244 are reported here apart from the first-request count.

Other figures declared by the source, not verified by this map: 42,434 profiles declare a checkout capability (a declaration, not a transaction); ucp.version declared 2026-08-25 on 41,624, 2026-04-08 on 898 and none on 120; 925 of the parsing profiles are on hosts whose home page was not 2xx. Could not ask, site side: robots.txt 102, 401 and 403 1,350, 402 141, 5xx 157, TLS 5, connection refused 12, reset 6 (sum 1,773, computed here); prober side: 429 504, timeouts 104, per-host budget 89 and 31, other 3 (sum 731, computed here).

The authors report two defects in their own record: "Our probe stored the profile's top-level version, not ucp.version", with counts re-read from the stored bodies, and, in their words, "on 1,570 hosts the per-host budget ran out inside the capability loop, so 1,147 hosts that answered 200 kept no result beyond row 1", so "row 2 is a floor by that much". The comment was edited on 2026-10-09 as a re-run of that day restructured against the frame, and its author wrote the same day (comment 18831816) that it was updated against the three points.

Figures of the 9 October run (declared by the source, not verified by this map): 225 hosts and 675 requests (225 storefront requests to find the host the storefront settles on, 225 profile-path requests and 225 robots.txt requests), user agent string agentbi/0.1 (the prober's own), vantage KR (Seoul, AS45102); row 1 (HTTP 200) 68 hosts, row 2 and ucp.version present 62 (the source counted the two conditions as one figure until its run of 13 Oct, see below), rows 3 and 4 not measured, no validator run.

Other outcomes of that run: 404 64, 410 2, 3xx at the profile path 12 (8 same-host protocol or path redirects, 4 cross-host with the Location host recorded), 200 that does not parse 6, which the author counts as "row 1 without row 2"; could not ask, site side: 403 59, robots.txt refusal 1, 5xx 1, TLS failure 1, connection refused or DNS 2, other 4xx (418) 1; prober side: timeouts 10, 429 1 ("Retry-After not recorded; that is a gap on my side"), URLs not sent because of the prober's own server-side request forgery (SSRF) guard 3.

On 2026-10-09 the author of this map posted version 3 of the frame in Discussion #867 (comment 18833761), after the two full runs of issue #904 and of Known Good. It adds a run field for the probed host with the counts "seed host as written, www-normalised, other host in the same registrable domain"; a line for 3xx at the profile path, since "a profile reached only via a 3xx is never a positive"; a row 1a, "200 after redirect", counted "only if 3xx were followed; non-conforming, excluded from 2-4"; a prober-side line widened to "anything the prober chose not to send or could not finish"; and an optional hosting row H, "of row 2: Cache-Control public, max-age ≥ 60; ETag or Last-Modified". The comment ties the redirect rows to the two rules of the overview page quoted above (lines 1466 and 1514) and the hosting row to items 3 and 4 of the same Hosting list.

The author of the census answered the same day (comment 18834311) "this is how I'll report the next pass." (his figures, declared by the source, not verified by this map): for the 225 seeds the probed host is the seed host as written for 201, www-normalised for 14 and another host of the same registrable domain for 10; 3xx at the profile path are 8 same-host, 3 same registrable domain and 1 other domain, none counted positive; row 1a is 0 "by construction" because the run never follows a 3xx at the profile path; Retry-After is now recorded and the hosting row measurable in the next pass.

On 2026-10-10 and 2026-10-11 the thread of Discussion #867 went on. The author of the census re-ran on 2026-10-11 (comment 18860202; figures declared by the source, not verified by this map): 225 hosts, vantage KR, row 2 and ucp.version present on 61 hosts (62 on 9 Oct; one host moved from a 200 to a 403, so from positive to "could not ask, site side"), and none of the three hosts that had settled on an asset host on 9 Oct did so again; the hosting row was first measured, with 58 of the 61 positives sending Cache-Control public with max-age of at least 60 and 4 sending ETag or Last-Modified.

He adopted the case "storefront did not settle on a storefront host" (comment 18861115) and will publish beside the headline how many positives depend on the fallback from 2026-10-12. Known Good split its run by row 1a (comment 18866655; declared): of the 1,244 answers of 200 after a redirect, 4 parse and none is among the 41,424 protocol responses, so 0 of them depend on following a redirect; the bucket of hosts that did not settle on a storefront host (a) is 451 hosts, 80 of them protocol responses, all platform-supplied (myshopify.com 62, wixapis.com 18); his later comment gives the vantage as AWS us-east-1, one egress address.

The author of this map posted the updated frame on 2026-10-11 (comment 18867673), "the version to copy", with the new case, the probed and the settled host per row, and the vantage as a run field. No run by anyone else was posted after 2026-10-11 in the 11 comments read on 2026-10-13. On 2026-10-14 (03:00 UTC, comment 18913822; figures declared by the source, not verified by this map) the author of the census wrote that "row 2: 61" reads as though 61 were row 2 as the frame defines it (parses as JSON) and that it is not: the figure is 200, parses as JSON and ucp.version declared, so a floor on row 2; the two numbers are reported apart from the run of 13 Oct, and are 61 and 61 on 13 and 14 Oct (difference 0); on 14 Oct 67 hosts answered 200 at the path, 61 parse as JSON, 5 are HTML soft-404s and 1 answers 200 with a body that is neither; row 3 and row 4 are not measured.

On 2026-10-08 a participant working in hotel revenue management proposed restrictions on the stay object of the lodging draft and wrote that the current standard errors "would likely return inventory_exhausted, which gives the agent nothing to recover with"; a hotel operator added "+1 from a six-unit property" (comment 18822183).

The Standard Errors table of the lodging booking page (lines 384 to 389) lists four codes, inventory_exhausted, occupancy_exceeded_capacity, payment_failed and eligibility_invalid, and describes inventory_exhausted as "The selected accommodation unit or inventory hold is no longer available"; no code for rate or stay restrictions is listed there (main at f2206e6, read 2026-10-09).

Google's own developer pages, describing Google's product built on UCP (class statement; distinct from the standard's text): The lodging FAQ (https://developers.google.com/hotels/ucp/faq, "Last updated 2026-09-24 UTC") says "This first milestone unlocks Booking", "The best way to provide feedback is through GitHub, where the protocol is published." and "Over the coming months, Google will adopt this standard to power its hotel booking feature on AI Mode."; on ranking it answers "No.

Opting for our booking integration does not influence how we rank your properties or rates in listings." The lodging page (https://developers.google.com/hotels/ucp, no update date shown on the page read) has a waitlist ("Join the waitlist"), "Conceptual mock only." and "Detailed onboarding and specs coming soon." The food ordering page (https://developers.google.com/actions-center/verticals/ordering/ucp, no update date shown on the page read) has a waitlist, "Detailed onboarding and specs coming soon." and "You remain the Merchant of Record."; allergens, dietary information, nutrition, disclosures, notices and alcohol are not mentioned on the page read on 2026-10-09.

Committed next

Boundary

PR #780 declares out of scope "Upstream lodging search/discovery service."

Author participation

The author of this map took part in PR #866, issues #550 and #858, Discussions #864 and #867 (opened by the author; replies on 2026-10-10 and 2026-10-11 and the updated reporting frame of 2026-10-11), PR #890, PR #897 (comments from 2026-10-09 to 2026-10-13) and issue #904; see Disclosure.

Sources

Overlaps

Agentic Resource Discovery (ARD), Verifiable Intent

Neighbours in the map

Neighbours of Universal Commerce Protocol (UCP) in the map Each circle is an entry of the map and links to its page; the colour is the kind of body behind it, a filled circle is a core entry and a dashed circle a context entry. The entry in the middle, with the entries it overlaps and the entries named by the same seams. Overlaps (10)Share a seam (30)IETF vcon (Virtualized Conversations WG) (IETF, core)IETF vcon Individual IETF drafts on the seller side (IETF, core)Individual IETF drafts… AAIF Agentic Commerce Working Group (AAIF, core)AAIF Agentic Commerce W… x402 (Linux Foundation, core)x402 Agentic Resource Discovery (ARD) (Independent, core)Agentic Resource Discov… Agent Payments Protocol (AP2) (Industry, core)Agent Payments Protocol Agentic Commerce Protocol (ACP) (Industry, core)Agentic Commerce Protoc… Personal Agent Protocol (PAP, "Poppy"), published by Sierra with Meta (Industry, core)Personal Agent Protocol Shopify, MCP surfaces for buyer agents, developers and merchants (Industry, context)Shopify Verifiable Intent (Industry, core)Verifiable Intent W3C AI Agent Protocol Community Group (W3C, core)W3C AI Agent Protocol C… S1 DNS for AI Discovery (DNS-AID, draft-mozleywilliams-dnsop-dnsaid) (IETF, context)DNS for AI Discovery S1 IETF DAWN, Discovery of Agents With Names (proposed WG) (IETF, core)IETF DAWN S1 A2A protocol, agent discovery (Linux Foundation, core)A2A protocol S1 AI Catalog (Agent Card Working Group) (Linux Foundation, core)AI Catalog S1 S2 Agent2Agent (A2A) protocol, core specification (Linux Foundation, context)Agent2Agent S1 MCP Server Cards (ext-server-card, SEP-2127) (Linux Foundation, core)MCP Server Cards S1 Model Context Protocol (MCP), core specification (Linux Foundation, context)Model Context Protocol S1 schema.org vocabulary for products, offers, sellers and lodging (current release) (Independent, context)schema.org vocabulary f… S1 S2 Personal Agent Consent & Trust Protocol (PACT), published by Decagon with Instinct (Industry, core)Personal Agent Consent… S1 S3 S4 W3C DID Resolution (W3C, core)W3C DID Resolution S2 W3C/GS1 Workshop on E-commerce for Humans and AI Agents (Zurich, 8-9 Sep 2026) (W3C, core)W3C/GS1 Workshop on E-c… S2 GS1 Digital Link Standard, URI Syntax 1.7.0 (GS1, context)GS1 Digital Link Standa… S2 GS1-Conformant Resolver Standard 1.2.1 (GS1, core)GS1-Conformant Resolver… S2 UN Global Trust Register, namespace urn:gtr (UN/CEFACT, context)UN Global Trust Register S2 UN Transparency Protocol, Identity Resolver (UN/CEFACT, core)UN Transparency Protocol S2 schema.org open issues relevant to agents, bookings, product and establishment identity (Independent, core)schema.org open issues… S2 W3C Agentic Web Working Group (draft charter) (W3C, core)W3C Agentic Web Working… S3 WebMCP (Draft Community Group Report, Web Machine Learning CG) (W3C, context)WebMCP S3 IETF Web Bot Auth (webbotauth WG) (IETF, core)IETF Web Bot Auth S3 IETF agentproto (Agent Communication Protocols WG) (IETF, core)IETF agentproto S3 Browser vendor positions on WebMCP (WebKit, Mozilla, Chrome, Edge) (Independent, core)Browser vendor position… S3 S4 OpenID Foundation AuthZEN Working Group (agent authorization drafts AARP and COAZ) (Independent, context)OpenID Foundation AuthZ… S3 KYAPay (Skyfire) (Industry, core)KYAPay S3 Mastercard Agent Pay (Industry, core)Mastercard Agent Pay S3 Visa Trusted Agent Protocol (TAP) (Industry, core)Visa Trusted Agent Prot… S3 Payment HTTP Authentication Scheme (draft-httpauth-payment, Tempo Labs and Stripe) (IETF, context)Payment HTTP Authentica… S4 EMILIA Protocol (individual drafts and open-source gate) (Independent, context)EMILIA Protocol S4 EMV Agentic Payments Framework for Specifications (draft for public feedback) (Industry, core)EMV Agentic Payments Fr… S4 FIDO Alliance agentic authentication and payments work (Industry, context)FIDO Alliance agentic a… S4 Universal Commerce Protocol

Solid lines: overlaps declared by one of the two entries. Dashed lines, coloured by seam: entries named by the same seam (S1 to S4) in the seams note. Every node is a link.

Evidence and coverage

Read
On 2026-10-14 also: Discussion #867 up to the comment of 2026-10-14 (03:00 UTC, comment 18913822).
Not read
Draft feed specification of PR #866, DWG and Tech Council minutes (private), external links, items before 2026-01-01; the schema and the 17 examples of PR #930, the nomination form of #924, the other pages of the DAP site.
Not found
Not found in overview page or the repository read: Agentic Resource Discovery (ARD).

Open proposals

ProposalAuthorDateStateLink
Issue #929 and draft PR #930: dev.ucp.common.quote, a time-bound quotation accepted by id on Cart and Checkout, projected onto the Order as id and subtotal.a participant2026-10-11openhttps://github.com/Universal-Commerce-Protocol/ucp/issues/929
PR #933: state that a 304 Not Modified is not a forbidden redirect on profile hosting and fetching (301, 302, 303, 307 and 308 are the banned codes).a participant2026-10-11openhttps://github.com/Universal-Commerce-Protocol/ucp/pull/933
Food domain: dev.ucp.food.checkout and food.fulfillment, for early feedback.a participant2026-10-03openhttps://github.com/Universal-Commerce-Protocol/ucp/pull/897
Attestation-based platform client authentication for first-contact accelerated IdP chaining.a participant2026-09-22openhttps://github.com/Universal-Commerce-Protocol/ucp/issues/852
Issue #515 (MerchantStamp): one signed-receipt envelope verified through a single path.a participant2026-06-15openhttps://github.com/Universal-Commerce-Protocol/ucp/issues/515
Issue #629: business persists the checkout billing_summary as the record of authorized terms.a participant2026-07-23openhttps://github.com/Universal-Commerce-Protocol/ucp/issues/629
PR #890: subscription policy extension; the Order snapshot as dispute record.a participant2026-10-02drafthttps://github.com/Universal-Commerce-Protocol/ucp/pull/890
Discussion #895: merchant decisions as signed, portable evidence.a participant2026-10-03openhttps://github.com/Universal-Commerce-Protocol/ucp/discussions/895
Issue #896: contingencies, buyer-approved handling of surprises after an order.a participant2026-10-03openhttps://github.com/Universal-Commerce-Protocol/ucp/issues/896
RFC #550 comment: links[] and policies[] on the feed list and manifest, with a usage-policy rule.a participant2026-09-30openhttps://github.com/Universal-Commerce-Protocol/ucp/issues/550#issuecomment-5914588559
Discussion #563: an approval gate for unattended buying agents, when no human is at the surface.a participant2026-07-05openhttps://github.com/Universal-Commerce-Protocol/ucp/discussions/563
PR #691: price_treatment on the price type; an absent price_treatment equals an absent tax.a participant2026-09-21openhttps://github.com/Universal-Commerce-Protocol/ucp/pull/691
Discussion #864: a restrictions object on the stay (minimum and maximum nights, closed to arrival, closed to departure) and an error code stay_restriction_violated.a participant2026-10-08openhttps://github.com/Universal-Commerce-Protocol/ucp/discussions/864#discussioncomment-18816854
PR #811: optional offers[] on the catalog variant, each offer naming the seller by seller.domain as Merchant of Record, with the seller's own item_id and price.a participant2026-09-07openhttps://github.com/Universal-Commerce-Protocol/ucp/pull/811

Payment comparison row

Owner / governance
Governing Council of five (Google, Shopify permanent; three elected); Tech Councils decide by majority; Council charters Domain Working Groups (DWGs)
Version and state
latest GitHub release v2026-08-25 (2026-08-25); lodging booking draft (PR #780)
What it signs
checkout responses: business signature "proving the terms (price, line items) are authentic"; order webhooks: RFC 9421 signature
Who signs
business (checkout responses, order webhooks); mandates provided by the platform
Receipt or record
Order entity, "the authoritative latest state of the order at the time of retrieval or delivery"
Dispute
not found in the UCP pages read on main (2026-10-03); draft PR #890 only (author commented; see Disclosure)
Source
https://github.com/Universal-Commerce-Protocol/ucp/blob/f2206e680f64fe2cc73495acc3557569afd9097a/docs/specification/payment/extensions/ap2-mandates.md