UCP Governing Council (Google and Shopify permanent seats, Stripe elected, 2 open), Google (custodian of the ucp.dev domain and proxy for open seats)
Status
Live Specified in dated releases (latest v2026-08-25; main is a draft). Live checkout on Google AI Mode and Gemini in the US since 2026-02-11. Microsoft says its Merchant Center will support UCP (future tense). Live use of the AP2 extension is unverified.
Latest version
v2026-08-25 (dated release; SDKs @ucp-js/sdk 0.5.1 and ucp-sdk 0.5.0),
State as of
Verified (verified under 30 days ago)
Rail-agnostic
Card network
Checkout and orders (primary layer)
Discovery
Payment credential
Identity and trust
Intent and authorization
Post-purchase and disputes
A. TL;DR and key facts
UCP lets an agent discover what a store supports, agree on capabilities and run checkout, cart and orders over REST, MCP, A2A or embedded UI. The store stays merchant of record; payments use tokenized credentials.
Why it exists
Every agent surface that wants to buy from every store faces an N by N integration problem: each retailer has its own cart, checkout and payment APIs, and each agent platform has its own way to call them. UCP gives both sides one published profile and one set of capability schemas, so a platform can read a store's profile at /.well-known/ucp, agree on the features both support, and drive checkout without a custom integration. The store keeps the customer relationship, its own payment provider and its liability as merchant of record, and the platform passes it an opaque payment token that a wallet or credential provider issued.
What it is not
Not Google's Universal Cart. Universal Cart is a Google shopping product announced on 2026-05-19 that uses UCP for checkout; UCP is the open protocol underneath. Source [20]
Not a way for Google to become the seller. The business is the merchant of record and keeps financial liability and the order; Google is not the merchant of record. Source [9, 21, 22]
Not the same thing as AP2. AP2 is an optional extension used inside UCP (dev.ucp.common.payment.ap2_mandate); UCP says where the AP2 signatures go, AP2 defines the mandate formats, and live use of AP2 mandates in UCP is unverified. Source [9, 19, 20, 23, 24, 25]? unverified
Not a payment network or processor. The business's own payment service provider authorizes and settles; UCP carries an opaque credential from platform to business, one way only. Source [12, 21]
Not a foundation project. A Governing Council owns the assets, Google and Shopify hold permanent seats, and Google keeps proxy votes for open seats until December 2028 and custody of ucp.dev. Source [1]
Not bridged to OpenAI's ACP. Both cover agent checkout with the merchant as merchant of record, but no mapping between the two is specified. Source [2, 26, 27]
Not an on-chain identity scheme. A platform is identified by its profile URL, its domain and the keys it publishes, not by a registry or a wallet address. Source [12]
Key facts as of 2026-10-11
Steward
UCP Governing Council; Google and Shopify hold permanent seats, Stripe an elected one; Google is custodian of ucp.dev Source [1, 2]
Governance
No foundation; Google holds proxy votes for open council seats until December 2028; Shopping, Food, Lodging and Payments tech councils of 16 Source [1]
License
Apache-2.0, copyright UCP Authors; contributors sign the Google CLA Source [1, 3]
First announced
2026-01-11 at NRF, co-developed with Shopify, Etsy, Wayfair, Target and Walmart Source [4, 5]
Latest version
v2026-08-25 (fourth dated release); main carries drafts such as dev.ucp.lodging.booking Source [6, 7]
Status
Live on Google AI Mode and Gemini in the US since 2026-02-11; no merchant counts published Source [8, 9, 10]? unverified
Transports
REST, MCP, A2A and embedded, each described by OpenAPI, OpenRPC or an Agent Card Source [11, 12]
Rails
Rail-agnostic payment handlers; credential types token, PAN and network token; Google surfaces use Google Pay PAN_ONLY Source [9, 12, 13, 14, 15, 16]
Builds on
RFC 9421 signatures with Content-Digest, RFC 8941 header, JWK Sets, OAuth 2.0 with PKCE, JSON Schema, OpenAPI and OpenRPC Source [11, 12, 17, 18]
Composes with
AP2 as an optional extension; MCP and A2A as transports; network tokens through the network_token credential type Source [9, 10, 12, 16, 19]
How to read this explanation
ELI5 is a short plain-language version. Practitioner is the full text. Spec-deep adds field tables and wire examples. STE shows the Simplified Technical English version instead.
B. Detailed explanation
ELI5 mode: plain-language version only.
Practitioner mode: the full explanation.
Spec-deep mode: the full explanation plus 4 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Think of a big shopping mall where every shop speaks a different language. A personal shopper who wants to buy for you would need to learn every language first. UCP gives each shop a sign on its front door that lists, in one shared language, what it can do: take orders, hold a basket, ship, give discounts. Your shopper reads the sign, says which of those things it understands too, and the two of them use only the overlap.
The shopper fills in the order form for you, but before anything is bought, it shows you the finished form on a screen you trust and you press the buy button yourself. If the shop needs something the shopper cannot give, like a signature for an expensive item, the shop hands back a link to its own counter so you can finish there.
To pay, the shopper does not carry your card. It asks your wallet for a sealed envelope that only the shop’s bank can open, and passes that envelope to the shop. The shop stays the seller: it owns the sale, the receipt and any refund, and it uses its usual bank. The mall that built the signs does not become the seller and does not touch the money.
Some shops and shoppers can also agree to sign the order form with special seals, so that later nobody can claim the form was changed. That is an optional add-on, not the main system.
UCP answers one question: how can any agent buy from any store without a custom integration for each pair? A business publishes a profile at /.well-known/ucp that lists its transports, the it supports (checkout, cart, catalog, orders) and the payment handlers it accepts.Source [11, 12] The agent’s platform names its own profile in a UCP-Agent header on every request, and the business keeps only the capabilities both sides list, at the highest version both support.Source [12] Checkout is a resource the platform creates and fills; when everything is present, the buyer places the order in a trusted interface unless the AP2 (Agent Payments Protocol) is active.Source [32] Payment arrives as an opaque token that the platform obtained from a wallet, and it flows one way, to the business, which charges it through its own payment service provider (PSP).Source [12] The business stays ; Google, which launched UCP, is not.Source [9, 21] What UCP does not give you: spending caps, reputation, or any statement that a platform is trustworthy beyond who it is.Source [12, 19, 33] Two names cause most confusion. UCP is not Google’s Universal Cart product, and AP2 is an optional extension inside UCP, not the same protocol.Source [9, 19, 20]
Problem and design goals
The Universal Commerce Protocol is an open commerce protocol published by the Universal-Commerce-Protocol organization on GitHub under Apache-2.0.Source [1, 3] Google introduced it on 2026-01-11 at the NRF (National Retail Federation) retail conference, co-developed with Shopify, Etsy, Wayfair, Target and Walmart and, in Google’s words, endorsed by more than 20 partners.Source [4, 5] The problem it targets is integration count: without a shared protocol, every agent surface needs its own connector to every store, and every store needs its own connector to every agent.
Four design choices follow. First, discovery is a static document, so a platform can learn what a business supports before it sends a single order.Source [12] Second, features are named capabilities with JSON schemas, and negotiation is a set intersection, so a store can add or drop a feature without breaking clients that do not use it.Source [12] Third, the same capability runs over REST (an HTTP API described by OpenAPI), (Model Context Protocol), (the Agent2Agent protocol) or an embedded checkout frame.Source [11, 12] Fourth, payment is delegated to handlers written by credential providers, so UCP never defines a card network or a wallet of its own.Source [12]
The business keeps commercial control. It is the merchant of record, holds financial liability and owns the order.Source [9, 21] It sets the checkout status and the totals, and it decides when a human has to take over.Source [32] At launch, UCP integrations powered checkout in AI Mode in Google Search and in the Gemini apps.Source [9]
Actors and roles
The glossary defines a platform as the consumer-facing surface, such as an AI agent, app or website, acting for the user.Source [21] The business sells the goods and is the merchant of record.Source [9, 21] A is a trusted entity, such as a digital wallet, that manages the user’s payment and identity credentials.Source [21] A PSP processes payments, authorizations and settlements for the business.Source [21] The buyer is the person who reviews and places the order.Source [32]
Payment handlers are the role newcomers misread. A handler is a specification, not a company: Google Pay publishes com.google.pay and Shop Pay publishes dev.shopify.shop_pay.Source [12] The credential provider writes the handler, the business configures it with its own merchant settings, and the platform executes it to obtain a token.Source [12] UCP defines the declaration format but, as of v2026-08-25, ships no concrete handler of its own.Source [12] A generic tokenization API with POST /tokenize and POST /detokenize is published as a building block for handler authors.Source [34]
On Google surfaces the platform is Google. Its UCP requests carry a UCP-Agent header and a User-Agent that starts with Google/UCP, and its health checks identify as Google-UCP-Prober/1.0.Source [9] Merchants do not need Google Pay on their own site, but their PSP must be able to process Google’s tokens.Source [9] On Microsoft’s side, Copilot Checkout requires a Microsoft Merchant Center account and a UCP-compliant feed, while Microsoft’s page says Merchant Center will support UCP, in the future tense.Source [22]
Core objects
Everything starts with the profile. A profile has a ucp object whose version, services and payment_handlers members are required, even when the registries are empty; capabilities is optional.Source [11, 12] Business profiles may add supported_versions, which maps older releases to version-specific profiles.Source [11, 12] Signing keys sit outside the ucp object in a top-level keys array that is a (JSON Web Key) Set, and private key members are forbidden.Source [11] Each service, capability and handler entry carries a required version plus optional spec, schema, id and config, and an extension names its parent in extends.Source [11, 12]
The checkout is the working object. It requires ucp, id, line_items, status, currency, totals and links. The links array is described as mandatory for legal compliance.Source [33]expires_at defaults to 6 hours after creation.Source [33]payment is optional on create and update but required on complete.Source [33] A payment instrument needs an id, a handler_id and a type, and carries the credential.Source [13] Credentials come in three types: a handler-specific token, a pan (, PAN) credential and a network_token credential with a .Source [13, 14, 15, 16] Every response also carries ucp.status, either success or error, which tells the reader what kind of body follows.Source [11, 32]
Orders and carts round out the shopping service. An order requires id, checkout_id, permalink_url, line_items, fulfillment, currency and totals, plus the ucp envelope.Source [35] Its adjustments record refunds, returns, credits, price adjustments, disputes and cancellations, each pending, completed or failed.Source [35] A cart requires ucp, id, line_items, currency and totals, and a checkout can be created from it with cart_id.Source [36]
Field tables. Spec version 2026-08-25, read from the JSON Schemas at tag v2026-08-25 (commit cd78fb3). main is a draft and differs. Descriptions are paraphrased.
Profile document (/.well-known/ucp for businesses)Spec version 2026-08-25
Keyed by service name such as dev.ucp.shopping; each binding has transport (rest, mcp, a2a, embedded) and an optional endpoint. May be empty. Spec reference for ucp.services
Top level, outside ucp. The only canonical signing key field since this release (replaced signing_keys). Private members such as d are forbidden. Spec reference for keys
Checkout (dev.ucp.shopping.checkout)Spec version 2026-08-25
On the older card credential: fpan, network_token or dpan. Deprecated now that PAN and network token are separate types. Spec reference for card_number_type
AP2 extension fields (dev.ucp.common.payment.ap2_mandate)Spec version 2026-08-25
Field
Type
Required
Description
ap2.merchant_authorization
string (header..signature)
No
Response only. JWS (JSON Web Signature) with detached content over the checkout without ap2, canonicalized with JCS (JSON Canonicalization Scheme); header carries alg and kid. Spec reference for ap2.merchant_authorization
ap2.checkout_mandate
string (SD-JWT, Selective Disclosure JSON Web Token, with key binding)
The main sequence in section C plays the default path: REST transport, a Google Pay style handler, and a buyer who places the order in a trusted interface.Source [32, 37]
The platform may fetch /.well-known/ucp first and should cache it. Profiles must be served over HTTPS, without redirects, with Cache-Control public and a max-age of at least 60 seconds.Source [12]
The platform picks a version, then checks for each capability that the schema URL host matches its reverse-DNS name, and rejects any that fail.Source [12]
It sends POST /checkout-sessions with UCP-Agent: profile="..." in RFC 8941 dictionary syntax; over MCP the same URL goes in meta["ucp-agent"].profile.Source [12]UCP-Agent and Request-Id are required, and Idempotency-Key is required on state-changing calls.Source [37]
The business fetches the , computes the intersection and returns the checkout with a ucp envelope that names the version and active capabilities.Source [12]
The platform sends the whole resource again with PUT /checkout-sessions/{id}; update is a full replacement, not a patch.Source [32]
When nothing is missing the status becomes ready_for_complete, and the buyer reviews and places the order in a trusted, deterministic UI (user interface).Source [32, 33]
The platform runs the handler with the credential provider, and the business plays no part in that exchange.Source [12] Handlers advertise available_instruments, and the list resolved in the checkout response is authoritative.Source [12]
POST /checkout-sessions/{id}/complete carries exactly one instrument, unless split payments was negotiated.Source [12] The response is completed with an order, or complete_in_progress with no order yet.Source [32]
A completed checkout is immutable and the business must email a confirmation.Source [32] Order events then arrive at the platform’s webhook_url as full snapshots with Standard Webhooks headers.Source [35, 37, 38]
Failures have defined shapes. Discovery and version problems are transport errors: invalid_profile_url (400), profile_unreachable (424), profile_malformed and version_unsupported (both 422).Source [12] An empty intersection is a business outcome instead: HTTP 200 with capabilities_incompatible.Source [12] Signature problems return 401 or 400 with codes such as signature_invalid and digest_mismatch.Source [12] Reusing an with a different body returns 409.Source [12, 17] The awkward case is a lost complete response. The platform polls Get Checkout with bounded backoff and may resend only the identical request under the same key, which is why section C plays it as its own failure flow.Source [32]
HTTP headers on the REST bindingSpec version 2026-08-25
On state-changing calls; at least 128 bits of entropy; stored 24 hours minimum, 48 recommended; 409 on reuse with a different payload. Spec reference for Idempotency-Key
The business owns the status field. A new checkout is usually incomplete, with messages that say what is missing.Source [33] Every message has a severity: recoverable means the platform can fix it with an update, requires_buyer_input and requires_buyer_review lead to requires_escalation, and unrecoverable means there is nothing left to act on.Source [32] The two severities mean different things. Buyer input means the business needs data its API cannot collect; buyer review means the checkout is complete but a policy, such as a high-value order, needs the buyer to approve it.Source [32]
Escalation is where UCP admits that not everything fits an API. With requires_escalation, the business must provide continue_url and at least one message with an escalation severity.Source [32]continue_url must be an absolute HTTPS URL, and the platform must open it for the buyer.Source [32] The business should also send it for other open statuses and leave it out once the session is completed or canceled.Source [32]
Completion can be synchronous or not. complete_in_progress means the business accepted the request and is still working, and during that time the platform must not start a new update or complete.Source [32] Since v2026-08-25, an outstanding action, for example a (EMV 3-D Secure) challenge, can sit in this state. Once the action finishes, the platform must confirm the result with Get Checkout, because the action’s own completion signal is not authoritative.Source [32, 39]completed is terminal and immutable. Any session that is not completed or already canceled can be canceled, and an expired session ends as canceled.Source [32]
Status
Meaning
Next
incomplete
Data missing, recoverable error or action outstanding
ready_for_complete, requires_escalation, canceled
requires_escalation
Buyer input or review needed; continue_url required
Complete accepted; no order yet; no new update or complete
completed, canceled (after fallback and handoff rules)
completed
Order placed; immutable
terminal
canceled
Canceled, invalid or expired
terminal
Message severities (checkout spec, Error Handling): recoverable, requires_buyer_input, requires_buyer_review, unrecoverable. Action types in the authentication extension: dev.ucp.common.payment.device_data_collection, dev.ucp.common.payment.three_ds_challenge. Order adjustment status:pending, completed, failed.
Security and trust model (summary)
The shop checks who your shopper is by asking for a signed note and comparing it with keys the shopper published on its own website. That proves who is talking, not that the shopper is good. Nothing in UCP stops a shopper from spending too much; that is up to your wallet and the shopper’s own rules.
Identity in UCP is domain-based. The platform is whoever controls the profile URL in UCP-Agent and the keys listed there.Source [11, 12] Requests, responses and webhooks can be signed with RFC 9421 HTTP Message Signatures, with an RFC 9530 Content-Digest binding the body.Source [17] Every implementation must be able to verify ES256; ES384 and EdDSA are optional, so ES256 is a baseline, not the only algorithm.Source [17] API keys, OAuth 2.0 and mTLS (mutual TLS) are allowed too, and with those the verifier must confirm that the authenticated principal may act for the profile it names.Source [12]
Replay protection lives at the business, through a signed Idempotency-Key, not through signature timestamps.Source [17] Keys need at least 128 bits of entropy and must be kept at least 24 hours, 48 recommended.Source [17] Webhooks must be signed, and a platform must reject an order event whose signer does not match the order’s business.Source [38] A compromised key stays usable until it is removed from the profile’s keys array.Source [12]
Onboarding is permissionless: any platform with a discoverable profile can call any business without registering first.Source [12] The spec therefore asks businesses to keep a list of pre-approved platforms, to bound the cost of discovering unknown ones, and to refuse profile URLs that resolve to special-use addresses such as 169.254.169.254.Source [12] proves where a schema came from but not that its author is honest, and it does not consult the Public Suffix List.Source [12]
Card data stays out of most hands. Credentials flow one way and are opaque, and the checkout spec says a business does not need to become PCI DSS (Payment Card Industry Data Security Standard) compliant to accept cards through the checkout capability.Source [12, 32] The buyer is the last check: without AP2, the order is placed by a human in a trusted UI.Source [32] With AP2 negotiated, the session is security locked and neither side may fall back to an unprotected checkout.Source [19] No GitHub security advisory and no CVE (Common Vulnerabilities and Exposures) entry naming UCP existed on 2026-10-11.Source [40] Section H has the threat table and section I the controls.
Versioning and governance
Versions are dates. Each release is a YYYY-MM-DD identifier, and git tags add a v prefix.Source [12, 41] Four releases exist: v2026-01-11, v2026-01-23, v2026-04-08 and v2026-08-25, the latest as of 2026-10-11.Source [6] ucp.dev serves latest and draft documentation, and latest points to 2026-08-25.Source [42] The main branch is ahead of the release with drafts such as dev.ucp.common.ask and dev.ucp.lodging.booking, so read field names at the tag, not on main.Source [7] Businesses must not advertise a non-date version such as draft in public discovery.Source [12]
One detail is often misreported. The v2026-08-25 release notes speak of independent capability versioning, but the normative spec ties every dev.ucp.* capability to the release date.Source [12, 24] Only third-party extensions under their own namespaces version independently and declare what they need with requires.Source [12] Published releases can also receive backward-compatible backports, so two parties can hold different copies of the same version.Source [12] Breaking pull requests carry an exclamation mark and are announced in GitHub Discussions 2 weeks before merge.Source [41]
Governance has no foundation. A Governing Council owns all UCP assets, and Google is custodian of the ucp.dev domain.Source [1] The council has 5 seats: permanent ones for Google and Shopify, and 3 elected.Source [1] Google holds the proxy vote for all open seats until December 2028.Source [1] As of 2026-10-11 the roster lists Amit Handa (Google), Ilya Grigorik (Shopify), Twum Djin (Stripe) and 2 open seats; Stripe joined on 2026-04-28.Source [2, 26] Domain Tech Councils have 16 seats, some of them permanent founding seats; the Governing Council elects members every 6 months, and each council decides by majority.Source [1] Shopping expanded on 2026-04-24 with Amazon, Meta, Microsoft, Stripe and Salesforce, and Food, Lodging and Payments councils followed on 2026-07-16, 2026-08-11 and 2026-09-02.Source [26] Google holds 6 of 10 permanent Food seats and 6 of 12 permanent Lodging seats.Source [1] Every change needs a maintainer’s approval, and contributors sign the Google CLA (contributor license agreement).Source [1]
Extensibility
Names carry the extension model. A capability is named reverse domain, then service, then capability, as in dev.ucp.shopping.checkout.Source [12] The dev.ucp namespace is reserved for the UCP governing body, and vendors must use their own domain.Source [12] Released shopping capabilities are checkout, cart, catalog search and lookup, order and permalink.Source [12, 24] Fulfillment, discount and buyer consent extend checkout, and loyalty is a common extension.Source [12] Common capabilities cover and location search and lookup.Source [12] Payment extensions live under dev.ucp.common.payment: ap2_mandate, authentication, split_payments and terms.Source [23, 24]
Identity linking deserves a closer look because it is how a platform acts for a signed-in buyer. It uses the OAuth 2.0 authorization code flow with PKCE (Proof Key for Code Exchange) S256, and plain PKCE is forbidden.Source [18] The platform finds the authorization server through RFC 9728 and RFC 8414 metadata, and falls back to OpenID discovery only on 404.Source [18] Scopes derive from capabilities, such as dev.ucp.shopping.order:read.Source [18, 32] Three access levels exist: public, agent-authenticated and user-authenticated.Source [18] Since v2026-08-25 an accelerated IdP (identity provider) flow can chain a trusted IdP identity to a new business with RFC 8693 token exchange and an RFC 7523 bearer grant.Source [18] Businesses must support RFC 7009 token revocation.Source [18]
Transports are the third axis. Over A2A, checkout data travels in DataPart objects keyed a2a.ucp.checkout, a2a.ucp.checkout.payment and a2a.ucp.checkout.signals.Source [43] The embedded protocol uses JSON-RPC messages such as ec.ready, ec.start, ec.complete and ec.payment.credential_request.Source [44] MCP runs over streamable HTTP so that the same RFC 9421 signatures apply, and the glossary says capabilities map one to one to MCP tools.Source [17, 21]
Capability namespace at v2026-08-25 (drafts on main marked)Spec version 2026-08-25
Field
Type
Required
Description
dev.ucp.shopping.checkout
capability
No
Checkout sessions; released since v2026-01-11.
dev.ucp.shopping.cart
capability
No
Carts; first released in v2026-04-08.
dev.ucp.shopping.catalog.search, .catalog.lookup
capabilities
No
Product search and lookup; first released in v2026-04-08.
dev.ucp.shopping.order, .permalink
capabilities
No
Orders since v2026-01-11; permalink new in v2026-08-25.
3DS2 through actions, more than one instrument, payment terms; new in v2026-08-25.
dev.ucp.common.ask, dev.ucp.lodging.booking
draft capabilities
No
On main only, in no release.
How it composes with the other seven
UCP is a checkout and order layer that leaves payment authorization to whatever the handler and the PSP do, so it pairs with protocols that carry stronger payment evidence.Source [12] AP2 is the documented example: UCP says where the AP2 signatures go, and AP2 defines the mandate formats.Source [9, 19] The extension existed from the first release as dev.ucp.shopping.ap2_mandate and was renamed dev.ucp.common.payment.ap2_mandate in v2026-08-25.Source [23, 24, 25, 45] Live use of AP2 mandates inside UCP is unverified as of 2026-10-11.Source [19, 20]? unverified MCP and A2A are transports, not rival commerce protocols.Source [12] The network_token credential type can carry card network tokens in general, but no Mastercard Agent Pay integration is documented.Source [10, 16] UCP and Visa TAP (Trusted Agent Protocol) both sign with RFC 9421, without a bridge.Source [17] No mapping to OpenAI’s ACP (Agentic Commerce Protocol), to Stripe’s MPP (Machine Payments Protocol), to x402 or to ERC-8004 is specified.Source [2, 12, 26, 27, 46] The section “Compare and compose” below goes further.
Limitations and open issues
Google’s structural weight. Google holds a permanent council seat, the proxy for open seats until December 2028 and the ucp.dev domain, and critics point to exactly that.Source [1]
No adoption numbers. Neither Google nor the project publishes merchant counts or volumes; Google said in February that hundreds of companies had shown interest.Source [8, 9, 10]? unverified
Two-layer negotiation. A platform first selects one version profile, then the business intersects capabilities by exact version, which is easy to get subtly wrong.Source [12]
Documentation drift. The ucp.dev “UCP and AP2” page still describes a checkoutSignature and a hashed checkout mandate, unlike the schema.Source [19, 47] The release notes spell the AP2 extension ap2_mandates, and the REST binding examples spell the Shop Pay handler com.shopify.shop_pay.Source [12, 23, 24, 48]
Conformance lag. The conformance suite’s example configuration still targets 2026-04-08.Source [49]
Privacy and upselling. Senator Elizabeth Warren raised data-sharing and upselling concerns in a letter dated 2026-02-03 (reported), and the roadmap lists cross-sell and upsell modules as a priority.Source [50, 51]
Attribution. The attribution field carries campaign parameters such as gclid but no attribution model.Source [12]
Merchant consent. Secondary reports say eligible US Shopify merchants were enrolled in Google’s native checkout automatically around 2026-09-22, with an opt-out; no primary source was found.Source [31]
No spending limits or reputation. Caps sit in AP2 mandates or with the credential provider, and the spec has no reputation mechanism.Source [12, 19, 33]
What changed in 2025 and 2026
2025-12-31: the ucp repository was created on GitHub.Source [3]
2026-01-11: launch at NRF with version 2026-01-11 (its git tag and GitHub release were created on 2026-01-23); v2026-01-23 followed the same day.Source [4, 5, 6]
2026-02-11: UCP checkout began rolling out to US shoppers for Etsy and Wayfair in AI Mode and Gemini.Source [8]
2026-02-17 and 2026-03-13: request signing and signals merged; carts (2026-01-26) and catalog (2026-03-08) also landed in v2026-04-08.Source [25, 52]
2026-03-19: a Google update on carts, catalog and loyalty or identity linking (reported only).Source [53]
2026-04-24 and 2026-04-28: Shopping council expansion; Stripe on the Governing Council; AP2 donated to the FIDO (Fast IDentity Online) Alliance.Source [26, 28]
2026-05-19 and 2026-05-20: Universal Cart, AP2 plans for Gemini Spark, and expansion plans for Canada, Australia and the UK.Source [20, 29]
2026-08-25: release v2026-08-25 with actions, 3DS2, split payments, keys, and the AP2 rename.Source [11, 23, 24, 25]
2026-09-02: the Payments Tech Council formed.Source [26]
2026-09-08: a UCP session at the W3C and GS1 workshop.Source [30]
2026-09-25: the draft lodging booking capability merged on main.Source [7, 26]
C. Diagrams
Main flow: UCP checkout over REST: discovery, negotiation, payment handler, completion and order webhook
The default UCP path on the REST binding. The platform reads the business profile at /.well-known/ucp, creates a checkout session with its own profile URL in UCP-Agent, the business intersects capabilities and answers with the active set and its payment handlers. The platform fills in missing data with a full-replacement update, shows the checkout to the buyer in a trusted UI, obtains an opaque token from the credential provider, and completes. The business charges the token through its own PSP and later sends signed order webhooks.
Buyer
Platform (agent surface)
Business (merchant of record)
Credential provider (wallet)
Business PSP
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 13Platform (agent surface) toto Business (merchant of record)
GET /.well-known/ucp
The platform may fetch the business profile before its first request and should cache it per the HTTP cache headers. The profile must be served over HTTPS without redirects, with Cache-Control public and a max-age of at least 60 seconds.
Step 1 of 13: Platform (agent surface) to Business (merchant of record). GET /.well-known/ucp. Crosses a trust boundary.
Sequence diagram: UCP checkout over REST: discovery, negotiation, payment handler, completion and order webhook
Scroll to see the whole diagram
Generated from the flow definition (spec version 2026-08-25, 2026-08-25). The player above uses the same data.
Text alternative
Sequence diagram: UCP checkout over REST: discovery, negotiation, payment handler, completion and order webhook. 5 participants: Buyer, Platform (agent surface), Business (merchant of record), Credential provider (wallet), and Business PSP. 13 steps, 12 crossing a trust boundary, 16 failure branches. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): GET /.well-known/ucp. This step crosses a trust boundary. If The profile URL redirects or is not HTTPS: The platform must not use it; there is no profile to negotiate with. Step 2: Business (merchant of record) to Platform (agent surface): 200 business profile (ucp, keys). This step crosses a trust boundary. If The profile advertises a non-date version such as draft: Not allowed in public discovery; the platform should treat it as malformed. Step 3: Platform (agent surface) to Platform (agent surface): Pick a version, check namespace authority. If A capability schema URL is on a host that does not own the namespace: The platform rejects that capability before fetching anything from it. Step 4: Platform (agent surface) to Business (merchant of record): POST /checkout-sessions (UCP-Agent, signed). This step crosses a trust boundary. If Signature or key problem: signature_missing, signature_invalid or key_not_found (401); digest_mismatch or algorithm_unsupported (400). If Profile URL malformed, unreachable or invalid: invalid_profile_url (400), profile_unreachable (424) or profile_malformed (422), with an optional continue_url. Step 5: Business (merchant of record) to Platform (agent surface): GET platform profile, verify key, intersect. This step crosses a trust boundary. If The platform profile URL resolves to a special-use address such as 169.254.169.254: The business must refuse to fetch it (server-side request forgery guard). If The intersection is empty: capabilities_incompatible as a UCP response (HTTP 200) with an optional continue_url; see the failure flow. Step 6: Business (merchant of record) to Platform (agent surface): 201 checkout, status incomplete. This step crosses a trust boundary. If All items are unavailable: ucp.status error with an out_of_stock message and no checkout resource. Step 7: Platform (agent surface) to Business (merchant of record): PUT /checkout-sessions/chk_123 (full replacement). This step crosses a trust boundary. If The business needs data its API cannot collect, or a policy needs buyer review: status requires_escalation with continue_url; see the escalation flow. If Idempotency key reused with a different payload: HTTP 409. Step 8: Platform (agent surface) to Buyer: Show checkout in a trusted UI; buyer places order. This step crosses a trust boundary. If The buyer declines: The platform may call POST /checkout-sessions/chk_123/cancel, or let the session expire. Step 9: Platform (agent surface) to Credential provider (wallet): Run the payment handler, get an opaque token. This step crosses a trust boundary. If The platform cannot run any advertised handler: The platform cannot complete; it can hand off with continue_url. Step 10: Platform (agent surface) to Business (merchant of record): POST /checkout-sessions/chk_123/complete. This step crosses a trust boundary. If More than one instrument without split payments: payment_failed. If The response is lost: Poll Get Checkout, then resend only the identical request with the same Idempotency-Key; see the failure flow. Step 11: Business (merchant of record) to Business PSP: Authorize the token with the PSP (outside UCP). This step crosses a trust boundary. If The issuer asks for 3DS2: With the authentication extension, the business returns an action; see the 3DS flow. Step 12: Business (merchant of record) to Platform (agent surface): 200 completed with order. This step crosses a trust boundary. Step 13: Business (merchant of record) to Platform (agent surface): POST webhook_url: signed order event. This step crosses a trust boundary. If Unsigned webhook or signer does not match the order business: The platform must reject the event; it can reconcile with GET /orders/order_789.
Step 1: Platform (agent surface) to Business (merchant of record): GET /.well-known/ucp. This step crosses a trust boundary. If The profile URL redirects or is not HTTPS: The platform must not use it; there is no profile to negotiate with.
Step 2: Business (merchant of record) to Platform (agent surface): 200 business profile (ucp, keys). This step crosses a trust boundary. If The profile advertises a non-date version such as draft: Not allowed in public discovery; the platform should treat it as malformed.
Step 3: Platform (agent surface) to Platform (agent surface): Pick a version, check namespace authority. If A capability schema URL is on a host that does not own the namespace: The platform rejects that capability before fetching anything from it.
Step 4: Platform (agent surface) to Business (merchant of record): POST /checkout-sessions (UCP-Agent, signed). This step crosses a trust boundary. If Signature or key problem: signature_missing, signature_invalid or key_not_found (401); digest_mismatch or algorithm_unsupported (400). If Profile URL malformed, unreachable or invalid: invalid_profile_url (400), profile_unreachable (424) or profile_malformed (422), with an optional continue_url.
Step 5: Business (merchant of record) to Platform (agent surface): GET platform profile, verify key, intersect. This step crosses a trust boundary. If The platform profile URL resolves to a special-use address such as 169.254.169.254: The business must refuse to fetch it (server-side request forgery guard). If The intersection is empty: capabilities_incompatible as a UCP response (HTTP 200) with an optional continue_url; see the failure flow.
Step 6: Business (merchant of record) to Platform (agent surface): 201 checkout, status incomplete. This step crosses a trust boundary. If All items are unavailable: ucp.status error with an out_of_stock message and no checkout resource.
Step 7: Platform (agent surface) to Business (merchant of record): PUT /checkout-sessions/chk_123 (full replacement). This step crosses a trust boundary. If The business needs data its API cannot collect, or a policy needs buyer review: status requires_escalation with continue_url; see the escalation flow. If Idempotency key reused with a different payload: HTTP 409.
Step 8: Platform (agent surface) to Buyer: Show checkout in a trusted UI; buyer places order. This step crosses a trust boundary. If The buyer declines: The platform may call POST /checkout-sessions/chk_123/cancel, or let the session expire.
Step 9: Platform (agent surface) to Credential provider (wallet): Run the payment handler, get an opaque token. This step crosses a trust boundary. If The platform cannot run any advertised handler: The platform cannot complete; it can hand off with continue_url.
Step 10: Platform (agent surface) to Business (merchant of record): POST /checkout-sessions/chk_123/complete. This step crosses a trust boundary. If More than one instrument without split payments: payment_failed. If The response is lost: Poll Get Checkout, then resend only the identical request with the same Idempotency-Key; see the failure flow.
Step 11: Business (merchant of record) to Business PSP: Authorize the token with the PSP (outside UCP). This step crosses a trust boundary. If The issuer asks for 3DS2: With the authentication extension, the business returns an action; see the 3DS flow.
Step 12: Business (merchant of record) to Platform (agent surface): 200 completed with order. This step crosses a trust boundary.
Step 13: Business (merchant of record) to Platform (agent surface): POST webhook_url: signed order event. This step crosses a trust boundary. If Unsigned webhook or signer does not match the order business: The platform must reject the event; it can reconcile with GET /orders/order_789.
Lifecycle: UCP checkout session status (v2026-08-25), with the AP2 lock
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
Transition
incomplete to ready_for_complete
Trigger
All information collected, no Action outstanding
API call
PUT /checkout-sessions/{id} (update_checkout)
Spec reference
shopping/checkout/index.md#status-values
About ready_for_complete
All data present and no Action outstanding. The platform may call Complete Checkout. With AP2 negotiated, every response here carries ap2.merchant_authorization.
State notes
incomplete
Data missing or a recoverable error or Action outstanding. Messages say what to fix. expires_at defaults to 6 hours after creation.
requires_escalation
Needs buyer input or buyer review. continue_url is required, with a requires_buyer_input or requires_buyer_review message.
ready_for_complete
All data present and no Action outstanding. The platform may call Complete Checkout. With AP2 negotiated, every response here carries ap2.merchant_authorization.
complete_in_progress
Complete accepted for asynchronous processing; no order yet. An Action (for example a 3DS challenge) can be outstanding. No new Update or Complete; on trouble the platform follows fallback, handoff, then cancel.
completed
Order placed; order.id and order.permalink_url present. Immutable. The business sends a confirmation email.
canceled
Canceled by the platform or invalid or expired. Start a new session if needed.
Spec version 2026-08-25.
State diagram: UCP checkout session status (v2026-08-25), with the AP2 lock
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version 2026-08-25).
Text alternative
State diagram: UCP checkout session status (v2026-08-25), with the AP2 lock. 6 states: incomplete, requires_escalation, ready_for_complete, complete_in_progress, completed, and canceled. Starts in incomplete. Ends in completed and canceled. 13 transitions. From incomplete to ready_for_complete when All information collected, no Action outstanding (PUT /checkout-sessions/{id} (update_checkout)). From incomplete to requires_escalation when Business needs data its API cannot collect, or a policy needs buyer review (POST or PUT /checkout-sessions response). From requires_escalation to incomplete when Issue resolved through an update (PUT /checkout-sessions/{id}). From requires_escalation to completed when Buyer finishes on the business UI through continue_url (continue_url (browser), then GET /checkout-sessions/{id}). From ready_for_complete to completed when Complete Checkout succeeds synchronously (POST /checkout-sessions/{id}/complete (complete_checkout)). From ready_for_complete to complete_in_progress when Complete Checkout accepted for asynchronous processing (POST /checkout-sessions/{id}/complete). From ready_for_complete to incomplete when Complete returns a recoverable change (for example payment_failed or out_of_stock) (POST /checkout-sessions/{id}/complete). From ready_for_complete to requires_escalation when Complete returns a buyer handoff (requires_buyer_input or requires_buyer_review) (POST /checkout-sessions/{id}/complete). From complete_in_progress to completed when Business finishes processing; any Action resolved (GET /checkout-sessions/{id} (get_checkout)). From incomplete to canceled when Platform cancels, or the session expires (POST /checkout-sessions/{id}/cancel (cancel_checkout)). From requires_escalation to canceled when Platform cancels, or the session expires (POST /checkout-sessions/{id}/cancel). From ready_for_complete to canceled when Platform cancels, or the session expires (POST /checkout-sessions/{id}/cancel). From complete_in_progress to canceled when Session invalid or expired (cancellation race rules apply) (POST /checkout-sessions/{id}/cancel).
From incomplete to ready_for_complete when All information collected, no Action outstanding (PUT /checkout-sessions/{id} (update_checkout)).
From incomplete to requires_escalation when Business needs data its API cannot collect, or a policy needs buyer review (POST or PUT /checkout-sessions response).
From requires_escalation to incomplete when Issue resolved through an update (PUT /checkout-sessions/{id}).
From requires_escalation to completed when Buyer finishes on the business UI through continue_url (continue_url (browser), then GET /checkout-sessions/{id}).
From ready_for_complete to completed when Complete Checkout succeeds synchronously (POST /checkout-sessions/{id}/complete (complete_checkout)).
From ready_for_complete to complete_in_progress when Complete Checkout accepted for asynchronous processing (POST /checkout-sessions/{id}/complete).
From ready_for_complete to incomplete when Complete returns a recoverable change (for example payment_failed or out_of_stock) (POST /checkout-sessions/{id}/complete).
From ready_for_complete to requires_escalation when Complete returns a buyer handoff (requires_buyer_input or requires_buyer_review) (POST /checkout-sessions/{id}/complete).
From complete_in_progress to completed when Business finishes processing; any Action resolved (GET /checkout-sessions/{id} (get_checkout)).
From incomplete to canceled when Platform cancels, or the session expires (POST /checkout-sessions/{id}/cancel (cancel_checkout)).
From requires_escalation to canceled when Platform cancels, or the session expires (POST /checkout-sessions/{id}/cancel).
From ready_for_complete to canceled when Platform cancels, or the session expires (POST /checkout-sessions/{id}/cancel).
From complete_in_progress to canceled when Session invalid or expired (cancellation race rules apply) (POST /checkout-sessions/{id}/cancel).
Five zones: the buyer, the platform with its own profile, keys and trusted UI, the credential provider that issues tokens, the business that is merchant of record and publishes /.well-known/ucp, and the business's PSP. Credentials move one way, platform to business. Numbers follow the main flow.
Text alternative
Flowchart. The buyer asks an agent on the platform to buy. The platform discovers the business profile at /.well-known/ucp, then calls the business UCP endpoint over REST, MCP, A2A or embedded transport with a UCP-Agent header and a signature. The business fetches the platform profile and keys. The platform shows the checkout in a trusted UI where the buyer places the order, runs the payment handler with a credential provider such as Google Pay to get an opaque token, and completes the checkout with that token. The business authorizes the token with its own PSP and sends signed order webhooks to the platform. When escalation is needed, the buyer finishes on the business web checkout through continue_url.
The profile document holds the ucp metadata and a top-level keys array. A checkout carries payment instruments that point at a handler instance by handler_id and hold an opaque credential (token, PAN or network token). With the AP2 extension a checkout also has an ap2 object. A completed checkout points to an order, which records fulfillment and adjustments. Field names from the v2026-08-25 JSON Schemas; lists trimmed.
Text alternative
Class diagram. Profile has ucp metadata and keys. Ucp metadata has version, services, capabilities, payment_handlers, supported_versions and status, and links to service bindings (version, transport, endpoint, schema), capability entries (version, spec, schema, extends, config) and payment handlers (id, version, available_instruments, config). Checkout has id, status, line_items, currency, totals, links, messages, actions, expires_at, continue_url, payment and order. Checkout has payment instruments (id, handler_id, type, credential, display); each instrument refers to a payment handler by handler_id and contains a credential with type and token. Checkout has an optional ap2 object with merchant_authorization and checkout_mandate. Checkout refers to an order with id, checkout_id, permalink_url, line_items, fulfillment and adjustments; adjustments have id, type, status and occurred_at.
UCP discovery and capability negotiation (two layers)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Negotiation happens in two layers. First the platform picks one protocol version profile from the business profile. Then, on each request, the business intersects capabilities by exact version and prunes extensions whose parent is not in the result. The example shows a cart capability dropped because only the platform lists it, and a loyalty extension dropped because only the business lists it.
Text alternative
Sequence diagram: UCP discovery and capability negotiation (two layers). 2 participants: Platform (agent surface) and Business (merchant of record). 7 steps, 5 crossing a trust boundary, 3 failure branches. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): GET /.well-known/ucp. This step crosses a trust boundary. Step 2: Business (merchant of record) to Platform (agent surface): Profile: version, supported_versions, capabilities. This step crosses a trust boundary. Step 3: Platform (agent surface) to Platform (agent surface): Layer 1: select version 2026-08-25. If No version in common: version_unsupported (REST 422) as a transport error, with an optional continue_url. Step 4: Platform (agent surface) to Business (merchant of record): Request with UCP-Agent: profile="...". This step crosses a trust boundary. Step 5: Business (merchant of record) to Platform (agent surface): GET platform profile. This step crosses a trust boundary. If Fetch fails or times out: profile_unreachable (REST 424). If Not valid JSON or violates the schema: profile_malformed (REST 422). Step 6: Business (merchant of record) to Business (merchant of record): Layer 2: intersect and prune. Step 7: Business (merchant of record) to Platform (agent surface): Response ucp envelope: version and active capabilities. This step crosses a trust boundary.
Step 1: Platform (agent surface) to Business (merchant of record): GET /.well-known/ucp. This step crosses a trust boundary.
Step 2: Business (merchant of record) to Platform (agent surface): Profile: version, supported_versions, capabilities. This step crosses a trust boundary.
Step 3: Platform (agent surface) to Platform (agent surface): Layer 1: select version 2026-08-25. If No version in common: version_unsupported (REST 422) as a transport error, with an optional continue_url.
Step 4: Platform (agent surface) to Business (merchant of record): Request with UCP-Agent: profile="...". This step crosses a trust boundary.
Step 5: Business (merchant of record) to Platform (agent surface): GET platform profile. This step crosses a trust boundary. If Fetch fails or times out: profile_unreachable (REST 424). If Not valid JSON or violates the schema: profile_malformed (REST 422).
Step 6: Business (merchant of record) to Business (merchant of record): Layer 2: intersect and prune.
Step 7: Business (merchant of record) to Platform (agent surface): Response ucp envelope: version and active capabilities. This step crosses a trust boundary.
HTTP payload. Illustrative example, spec version 2026-08-25.
# Illustrative example, spec version 2026-08-25.
GET /.well-known/ucp HTTP/1.1
Host: shop.example
Spec version 2026-08-25 (2026-08-25). Sources: [11], [12]
Step 1 of 7: Platform (agent surface) to Business (merchant of record). GET /.well-known/ucp. Crosses a trust boundary.
UCP capability namespace tree
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Names follow reverse domain, service, capability. Everything under dev.ucp belongs to the UCP governing body and carries the release date as its version; vendors use their own reverse domain and version independently. Payment extensions moved from shopping to common.payment in v2026-08-25. Items marked draft exist only on main.
Text alternative
Tree. dev.ucp has three services: shopping, common and lodging. Shopping has checkout, cart, catalog.search, catalog.lookup, order and permalink; checkout is extended by fulfillment, discount and buyer_consent. Common has identity_linking, location.search and location.lookup, loyalty as an extension, payment and the draft ask capability. Payment has ap2_mandate (formerly shopping.ap2_mandate), authentication for 3DS2 actions, split_payments and terms. Lodging has a draft booking capability. Separately, com.vendor and org.org namespaces version independently.
The same capability runs over four transports. Each service entry in a profile pairs a transport with an endpoint and a machine-readable description. The platform names its profile in a header on REST and A2A, and in a meta object on MCP.
Text alternative
Flowchart. One operation, create checkout, maps to four transports. REST uses POST /checkout-sessions with UCP-Agent, Idempotency-Key and Request-Id headers and is described by OpenAPI 3.1. MCP uses tools/call create_checkout with meta ucp-agent profile in the arguments and is described by OpenRPC over streamable HTTP. A2A sends a message with a DataPart keyed a2a.ucp.checkout, with UCP-Agent and X-A2A-Extensions headers, described by an Agent Card at the endpoint. Embedded uses ec.* JSON-RPC messages such as ec.ready, ec.start, ec.complete and ec.payment.credential_request inside a host frame, described by OpenRPC.
UCP alternative path: requires_escalation and handoff through continue_url
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The business needs something the API cannot collect, or a policy needs the buyer to approve the order. It returns requires_escalation with a continue_url and a message whose severity is requires_buyer_input or requires_buyer_review. The platform fixes any recoverable errors first, then opens continue_url, and the buyer finishes on the business UI.
Text alternative
Sequence diagram: UCP alternative path: requires_escalation and handoff through continue_url. 3 participants: Buyer, Platform (agent surface), and Business (merchant of record). 6 steps, 5 crossing a trust boundary, 2 failure branches. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): PUT /checkout-sessions/chk_456. This step crosses a trust boundary. Step 2: Business (merchant of record) to Platform (agent surface): status requires_escalation + continue_url. This step crosses a trust boundary. If continue_url is missing: The business broke a MUST; the platform cannot hand off and should treat the checkout as stuck. Step 3: Platform (agent surface) to Platform (agent surface): Resolve recoverable errors first. Step 4: Platform (agent surface) to Buyer: Open continue_url for the buyer. This step crosses a trust boundary. Step 5: Buyer to Business (merchant of record): Buyer finishes on the business UI. This step crosses a trust boundary. If The buyer abandons: The session expires (default 6 hours) and becomes canceled. Step 6: Platform (agent surface) to Business (merchant of record): GET /checkout-sessions/chk_456. This step crosses a trust boundary.
Step 1: Platform (agent surface) to Business (merchant of record): PUT /checkout-sessions/chk_456. This step crosses a trust boundary.
Step 2: Business (merchant of record) to Platform (agent surface): status requires_escalation + continue_url. This step crosses a trust boundary. If continue_url is missing: The business broke a MUST; the platform cannot hand off and should treat the checkout as stuck.
Step 4: Platform (agent surface) to Buyer: Open continue_url for the buyer. This step crosses a trust boundary.
Step 5: Buyer to Business (merchant of record): Buyer finishes on the business UI. This step crosses a trust boundary. If The buyer abandons: The session expires (default 6 hours) and becomes canceled.
Step 6: Platform (agent surface) to Business (merchant of record): GET /checkout-sessions/chk_456. This step crosses a trust boundary.
Spec version 2026-08-25 (2026-08-25). Sources: [32], [33]
Step 1 of 6: Platform (agent surface) to Business (merchant of record). PUT /checkout-sessions/chk_456. Crosses a trust boundary.
UCP failure: no capability in common
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The platform only supports carts and the business only supports checkout, so the intersection is empty. This is a business outcome, not a transport error: HTTP 200, ucp.status error, a capabilities_incompatible message and an optional continue_url to the web storefront.
Text alternative
Sequence diagram: UCP failure: no capability in common. 3 participants: Platform (agent surface), Business (merchant of record), and Buyer. 4 steps, 3 crossing a trust boundary. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): POST /carts with UCP-Agent. This step crosses a trust boundary. Step 2: Business (merchant of record) to Business (merchant of record): Intersection is empty. Step 3: Business (merchant of record) to Platform (agent surface): 200 OK, ucp.status error, capabilities_incompatible. This step crosses a trust boundary. Step 4: Platform (agent surface) to Buyer: Fall back to continue_url. This step crosses a trust boundary.
Step 1: Platform (agent surface) to Business (merchant of record): POST /carts with UCP-Agent. This step crosses a trust boundary.
Step 2: Business (merchant of record) to Business (merchant of record): Intersection is empty.
Step 3: Business (merchant of record) to Platform (agent surface): 200 OK, ucp.status error, capabilities_incompatible. This step crosses a trust boundary.
Step 4: Platform (agent surface) to Buyer: Fall back to continue_url. This step crosses a trust boundary.
Spec version 2026-08-25 (2026-08-25). Sources: [12]
Step 1 of 4: Platform (agent surface) to Business (merchant of record). POST /carts with UCP-Agent. Crosses a trust boundary.
UCP failure: the Complete Checkout response is lost
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The complete call reaches the business but the response never arrives. The platform must not start a new complete. It polls Get Checkout with bounded backoff until expires_at, and only if the state is still unclear does it resend the identical request with the same Idempotency-Key. A different payload under the same key gets HTTP 409.
Text alternative
Sequence diagram: UCP failure: the Complete Checkout response is lost. 2 participants: Platform (agent surface) and Business (merchant of record). 5 steps, 5 crossing a trust boundary, 4 failure branches. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): POST .../complete (Idempotency-Key K1). This step crosses a trust boundary. Step 2: Business (merchant of record) to Platform (agent surface): Response lost (timeout). This step crosses a trust boundary. Step 3: Platform (agent surface) to Business (merchant of record): GET /checkout-sessions/chk_123 with backoff. This step crosses a trust boundary. If Get Checkout shows completed: Stop. The order exists; read order.id. Step 4: Platform (agent surface) to Business (merchant of record): Resend identical request with K1. This step crosses a trust boundary. If The platform changes the body but keeps K1: HTTP 409, idempotency key reused with a different payload. If The platform uses a new key for the retry: Forbidden by the spec; it risks a second order. If The business cannot reach its idempotency store: It fails closed with HTTP 503. Step 5: Business (merchant of record) to Platform (agent surface): Stored result: completed with order. This step crosses a trust boundary.
Step 1: Platform (agent surface) to Business (merchant of record): POST .../complete (Idempotency-Key K1). This step crosses a trust boundary.
Step 2: Business (merchant of record) to Platform (agent surface): Response lost (timeout). This step crosses a trust boundary.
Step 3: Platform (agent surface) to Business (merchant of record): GET /checkout-sessions/chk_123 with backoff. This step crosses a trust boundary. If Get Checkout shows completed: Stop. The order exists; read order.id.
Step 4: Platform (agent surface) to Business (merchant of record): Resend identical request with K1. This step crosses a trust boundary. If The platform changes the body but keeps K1: HTTP 409, idempotency key reused with a different payload. If The platform uses a new key for the retry: Forbidden by the spec; it risks a second order. If The business cannot reach its idempotency store: It fails closed with HTTP 503.
Step 5: Business (merchant of record) to Platform (agent surface): Stored result: completed with order. This step crosses a trust boundary.
HTTP payload. Illustrative example, spec version 2026-08-25.
# Illustrative example, spec version 2026-08-25.
POST /ucp/v1/checkout-sessions/chk_123/complete HTTP/1.1
Idempotency-Key: 3b7f0c3e-9d1a-4f5e-8c2b-1a6e4d9f7b20
Spec version 2026-08-25 (2026-08-25). Sources: [12], [17], [32]
Step 1 of 5: Platform (agent surface) to Business (merchant of record). POST ../complete (Idempotency-Key K1). Crosses a trust boundary.
UCP alternative path: 3DS2 step-up through actions (authentication extension)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
With dev.ucp.common.payment.authentication negotiated, the business can answer a complete with complete_in_progress and an action for device data collection or a 3DS challenge. The platform runs the browser surface, the surface reports back, and the platform confirms the outcome with Get Checkout. UCP does not carry EMV 3DS messages itself.
Text alternative
Sequence diagram: UCP alternative path: 3DS2 step-up through actions (authentication extension). 4 participants: Buyer, Platform (agent surface), Business (merchant of record), and Business PSP. 6 steps, 6 crossing a trust boundary, 1 failure branch. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): POST .../complete. This step crosses a trust boundary. Step 2: Business (merchant of record) to Business PSP: Authorize; issuer wants 3DS. This step crosses a trust boundary. Step 3: Business (merchant of record) to Platform (agent surface): complete_in_progress + action. This step crosses a trust boundary. Step 4: Platform (agent surface) to Buyer: Show the challenge surface. This step crosses a trust boundary. Step 5: Platform (agent surface) to Business (merchant of record): GET /checkout-sessions/chk_123. This step crosses a trust boundary. If Challenge fails: The business returns incomplete or requires_escalation; the platform must not reprocess the same action id unless its contract allows it. Step 6: Business (merchant of record) to Platform (agent surface): completed with order. This step crosses a trust boundary.
Step 1: Platform (agent surface) to Business (merchant of record): POST .../complete. This step crosses a trust boundary.
Step 2: Business (merchant of record) to Business PSP: Authorize; issuer wants 3DS. This step crosses a trust boundary.
Step 3: Business (merchant of record) to Platform (agent surface): complete_in_progress + action. This step crosses a trust boundary.
Step 4: Platform (agent surface) to Buyer: Show the challenge surface. This step crosses a trust boundary.
Step 5: Platform (agent surface) to Business (merchant of record): GET /checkout-sessions/chk_123. This step crosses a trust boundary. If Challenge fails: The business returns incomplete or requires_escalation; the platform must not reprocess the same action id unless its contract allows it.
Step 6: Business (merchant of record) to Platform (agent surface): completed with order. This step crosses a trust boundary.
Spec version 2026-08-25 (2026-08-25). Sources: [32], [39], [44]
Step 1 of 6: Platform (agent surface) to Business (merchant of record). POST ../complete. Crosses a trust boundary.
AP2 mandates inside a UCP checkout (spec flow; live use unverified)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
When dev.ucp.common.payment.ap2_mandate is in the intersection, the session is security locked. The business signs every checkout response (ap2.merchant_authorization, a detached JWS over the JCS-canonical checkout). The platform verifies it before showing the checkout, and on complete sends ap2.checkout_mandate (an SD-JWT with key binding that contains the whole signed checkout) plus a payment mandate inside the credential token. No public source shows this running in production as of 2026-10-11.
Text alternative
Sequence diagram: AP2 mandates inside a UCP checkout (spec flow; live use unverified). 4 participants: Buyer, Platform (agent surface), Business (merchant of record), and Business PSP. 7 steps, 6 crossing a trust boundary, 4 failure branches. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): POST /checkout-sessions (profile lists AP2, keys). This step crosses a trust boundary. If The platform profile has no usable key: agent_missing_key. Step 2: Business (merchant of record) to Business (merchant of record): Intersection includes AP2: lock the session. Step 3: Business (merchant of record) to Platform (agent surface): Checkout + ap2.merchant_authorization. This step crosses a trust boundary. If Signature missing or invalid: merchant_authorization_missing or merchant_authorization_invalid; the platform must not show the checkout. Step 4: Platform (agent surface) to Buyer: Verify, show, get consent. This step crosses a trust boundary. Step 5: Platform (agent surface) to Business (merchant of record): complete with ap2.checkout_mandate. This step crosses a trust boundary. If No checkout mandate: mandate_required; the business must reject the complete. If Mandate bound to another checkout, expired or badly signed: mandate_scope_mismatch, mandate_expired or mandate_invalid_signature. Step 6: Business (merchant of record) to Business PSP: Verify mandate; pass payment mandate to PSP. This step crosses a trust boundary. Step 7: Business (merchant of record) to Platform (agent surface): completed with order. This step crosses a trust boundary.
Step 1: Platform (agent surface) to Business (merchant of record): POST /checkout-sessions (profile lists AP2, keys). This step crosses a trust boundary. If The platform profile has no usable key: agent_missing_key.
Step 2: Business (merchant of record) to Business (merchant of record): Intersection includes AP2: lock the session.
Step 3: Business (merchant of record) to Platform (agent surface): Checkout + ap2.merchant_authorization. This step crosses a trust boundary. If Signature missing or invalid: merchant_authorization_missing or merchant_authorization_invalid; the platform must not show the checkout.
Step 4: Platform (agent surface) to Buyer: Verify, show, get consent. This step crosses a trust boundary.
Step 5: Platform (agent surface) to Business (merchant of record): complete with ap2.checkout_mandate. This step crosses a trust boundary. If No checkout mandate: mandate_required; the business must reject the complete. If Mandate bound to another checkout, expired or badly signed: mandate_scope_mismatch, mandate_expired or mandate_invalid_signature.
Step 6: Business (merchant of record) to Business PSP: Verify mandate; pass payment mandate to PSP. This step crosses a trust boundary.
Step 7: Business (merchant of record) to Platform (agent surface): completed with order. This step crosses a trust boundary.
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 7Platform (agent surface) toto Business (merchant of record)
POST /checkout-sessions (profile lists AP2, keys)
Both profiles list dev.ucp.common.payment.ap2_mandate, which extends checkout; the business config declares vp_formats_supported with dc+sd-jwt. Under the trusted platform provider model, the platform profile must publish at least one key in keys.
Spec version 2026-08-25 (2026-08-25). Sources: [19], [20], [23]
Step 1 of 7: Platform (agent surface) to Business (merchant of record). POST /checkout-sessions (profile lists AP2, keys). Crosses a trust boundary.
The AP2 lock inside UCP
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
AP2 is an optional extension. If it is in the capability intersection the session is security locked: the business signs every checkout response, the platform must verify that signature, and complete must carry a checkout mandate. Without AP2 the buyer places the order in a trusted UI. The extension is specified; no public source shows it in production as of 2026-10-11.
Text alternative
State diagram. Negotiation leads either to Unlocked, when AP2 is not in the intersection, or to Security locked, when dev.ucp.common.payment.ap2_mandate is. Unlocked leads to the buyer placing the order in a trusted UI. Security locked leads to a signed checkout carrying ap2.merchant_authorization. If the platform cannot verify the signature the session is rejected. Otherwise the buyer consents and a checkout mandate is signed. A missing, expired or mis-scoped mandate is rejected; a valid one is verified by the business and the payment mandate by the PSP, and the checkout completes. A note says there is no downgrade to an unprotected checkout for that session.
UCP identity linking: OAuth 2.0 authorization code with PKCE
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
To act for a signed-in buyer (orders, saved addresses, loyalty), the platform links the buyer account at the business with OAuth 2.0. It finds the authorization server through protected-resource and authorization-server metadata, runs the authorization code flow with PKCE S256, and requests scopes derived from capabilities. Three access levels exist: public, agent-authenticated and user-authenticated.
Text alternative
Sequence diagram: UCP identity linking: OAuth 2.0 authorization code with PKCE. 3 participants: Buyer, Platform (agent surface), and Business (merchant of record). 7 steps, 7 crossing a trust boundary, 3 failure branches. Based on ucp 2026-08-25 (2026-08-25). Step 1: Platform (agent surface) to Business (merchant of record): GET /.well-known/oauth-protected-resource. This step crosses a trust boundary. Step 2: Platform (agent surface) to Business (merchant of record): GET /.well-known/oauth-authorization-server. This step crosses a trust boundary. If Issuer mismatch: The platform must stop; the metadata may be spoofed. Step 3: Platform (agent surface) to Buyer: Redirect to authorize (PKCE S256, capability scopes). This step crosses a trust boundary. Step 4: Buyer to Business (merchant of record): Sign in and consent at the business. This step crosses a trust boundary. Step 5: Business (merchant of record) to Platform (agent surface): Redirect with code and iss. This step crosses a trust boundary. Step 6: Platform (agent surface) to Business (merchant of record): Token request with code_verifier. This step crosses a trust boundary. Step 7: Platform (agent surface) to Business (merchant of record): User-authenticated call, e.g. GET /orders/{id}. This step crosses a trust boundary. If No user token: identity_required (401) with a WWW-Authenticate Bearer challenge. If Token lacks the scope: insufficient_scope (403).
Step 1: Platform (agent surface) to Business (merchant of record): GET /.well-known/oauth-protected-resource. This step crosses a trust boundary.
Step 2: Platform (agent surface) to Business (merchant of record): GET /.well-known/oauth-authorization-server. This step crosses a trust boundary. If Issuer mismatch: The platform must stop; the metadata may be spoofed.
Step 3: Platform (agent surface) to Buyer: Redirect to authorize (PKCE S256, capability scopes). This step crosses a trust boundary.
Step 4: Buyer to Business (merchant of record): Sign in and consent at the business. This step crosses a trust boundary.
Step 5: Business (merchant of record) to Platform (agent surface): Redirect with code and iss. This step crosses a trust boundary.
Step 6: Platform (agent surface) to Business (merchant of record): Token request with code_verifier. This step crosses a trust boundary.
Step 7: Platform (agent surface) to Business (merchant of record): User-authenticated call, e.g. GET /orders/{id}. This step crosses a trust boundary. If No user token: identity_required (401) with a WWW-Authenticate Bearer challenge. If Token lacks the scope: insufficient_scope (403).
Source of truth: Discovery (external link) Generated from src/content/flows/ucp-identity-linking.json.
Play this flow step by step
Buyer
Platform (agent surface)
Business (merchant of record)
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 7Platform (agent surface) toto Business (merchant of record)
GET /.well-known/oauth-protected-resource
RFC 9728 protected-resource metadata names the authorization server.
Spec version 2026-08-25 (2026-08-25). Sources: [18], [32]
Step 1 of 7: Platform (agent surface) to Business (merchant of record). GET /.well-known/oauth-protected-resource. Crosses a trust boundary.
How UCP composes with the other protocols
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Solid lines are documented links: AP2 as an optional extension, MCP and A2A as transports, Web Bot Auth as optional signature interop. Dotted lines are overlaps without a specified bridge. Copilot Checkout requires a UCP-compliant feed, and Microsoft says its Merchant Center will support UCP.
Text alternative
Flowchart centered on UCP. AP2 mandates plug in as the optional ap2_mandate extension. MCP and A2A are transports. Web Bot Auth is an optional signature interop. Dotted, undocumented overlaps: Mastercard Agent Pay tokens could fit the network_token credential type; Visa TAP also uses RFC 9421 but has no bridge; OpenAI ACP does the same job with no bridge; x402 is not mentioned in the spec; ERC-8004 is not mentioned and UCP identity is domain-based. UCP powers checkout in Google AI Mode, Gemini and Universal Cart, and Microsoft Copilot Checkout requires a UCP-compliant feed.
Spec-deep mode: the full explanation plus 0 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
This section uses Simplified Technical English (ASD-STE100): short sentences, one instruction per step, and one word for one meaning.
UCP is the Universal Commerce Protocol. It is an open protocol for checkout, carts and orders. An agent uses UCP to buy from a business. Google started UCP in 2026 with Shopify and other companies.
UCP has four main roles. The platform is the agent or app that acts for the buyer. The business sells the goods and is the merchant of record. The credential provider is a wallet that gives a payment token. The payment service provider (PSP) of the business charges the token.
Each business publishes a profile at the path /.well-known/ucp. The profile shows the versions, the transports, the capabilities and the payment handlers of the business. The profile also contains the public keys of the business. The platform also has a profile, and it sends the address of that profile in the UCP-Agent header.
The business compares the two profiles. It keeps only the capabilities that both sides support. It uses the highest version that both sides support. It removes an extension when the parent capability is not available.
The business is the merchant of record. Google is not the merchant of record. Universal Cart is a Google product that uses UCP. It is not the protocol. AP2 is an optional extension inside UCP. It is not the same protocol as UCP.
Procedure Buy an item through UCP (platform)
Get the business profile from /.well-known/ucp.
Make sure that the profile uses HTTPS and has no redirect.
Select the highest version that you and the business support.
Send a create checkout request. Put the address of your profile in the UCP-Agent header.
Add an Idempotency-Key header and a Request-Id header to the request.
Read the status and the messages in the response.
If a message has the severity recoverable, correct the data. Send the full checkout again.
If the status is requires_escalation, open the continue_url for the buyer.
When the status is ready_for_complete, show the checkout to the buyer in a trusted screen.
Get a payment token from the credential provider of the selected payment handler.
Send the complete checkout request with one payment instrument.
Keep the order identifier and the permalink_url from the response.
Procedure Accept UCP checkouts (business)
Publish your profile at /.well-known/ucp with Cache-Control public and a max-age of 60 seconds or more.
Put your public keys for signatures in the top-level keys array.
When a request arrives, get the platform profile from the address in the UCP-Agent header.
Make sure that the address does not point to a special-use IP address.
Verify the signature of the request with a key from the platform profile.
Calculate the capabilities that both profiles support.
Put the version and the active capabilities in the ucp field of each response.
If you need data that your API cannot collect, set the status to requires_escalation and send a continue_url.
Send the payment token to your PSP.
After the order is complete, send a confirmation email to the buyer.
Technical nouns and technical verbs
Platform (TN): The agent, app or website that acts for the buyer.
Business (TN): The seller. It is the merchant of record for the order.
Business profile (TN): The JSON document at /.well-known/ucp that shows what the business supports.
Capability (TN): A named function, for example checkout or cart, with a JSON schema.
Extension (TN): A capability that adds fields to a parent capability.
Payment handler (TN): A specification from a credential provider that tells the platform how to get a token.
Credential provider (TN): A wallet or similar entity that holds the payment credentials of the buyer.
continue_url (TN): The address of the web checkout of the business. The buyer uses it to finish the order.
Security lock (TN): The state of a session after the business and the platform agree to use AP2 mandates.
Negotiate (TV): To find the capabilities and the version that two profiles both support.
Escalate (TV): To move the checkout from the agent to the buyer.
STE check report
Sentences
72
Longest procedural sentence
19 words (limit 20)
Longest descriptive sentence
17 words (limit 25)
Flags
None
Written to the public ASD-STE100 Issue 9 writing rules. Vocabulary not checked against the official dictionary.
Compare with the practitioner text side by side
Practitioner text (section B)
UCP answers one question: how can any agent buy from any store without a custom integration for each pair? A business publishes a profile at `/.well-known/ucp` that lists its transports, the capabilities it supports (checkout, cart, catalog, orders) and the payment handlers it accepts. The agent's platform names its own profile in a `UCP-Agent` header on every request, and the business keeps only the capabilities both sides list, at the highest version both support. Checkout is a resource the platform creates and fills; when everything is present, the buyer places the order in a trusted interface unless the AP2 (Agent Payments Protocol) extension is active. Payment arrives as an opaque token that the platform obtained from a wallet, and it flows one way, to the business, which charges it through its own payment service provider (PSP). The business stays merchant of record; Google, which launched UCP, is not. What UCP does not give you: spending caps, reputation, or any statement that a platform is trustworthy beyond who it is. Two names cause most confusion. UCP is not Google's Universal Cart product, and AP2 is an optional extension inside UCP, not the same protocol.
The Universal Commerce Protocol is an open commerce protocol published by the Universal-Commerce-Protocol organization on GitHub under Apache-2.0. Google introduced it on 2026-01-11 at the NRF (National Retail Federation) retail conference, co-developed with Shopify, Etsy, Wayfair, Target and Walmart and, in Google's words, endorsed by more than 20 partners. The problem it targets is integration count: without a shared protocol, every agent surface needs its own connector to every store, and every store needs its own connector to every agent.
Simplified Technical English
UCP is the Universal Commerce Protocol. It is an open protocol for checkout, carts and orders. An agent uses UCP to buy from a business. Google started UCP in 2026 with Shopify and other companies.
UCP has four main roles. The platform is the agent or app that acts for the buyer. The business sells the goods and is the merchant of record. The credential provider is a wallet that gives a payment token. The payment service provider (PSP) of the business charges the token.
Each business publishes a profile at the path /.well-known/ucp. The profile shows the versions, the transports, the capabilities and the payment handlers of the business. The profile also contains the public keys of the business. The platform also has a profile, and it sends the address of that profile in the UCP-Agent header.
E. Main personas
Enterprise commerce architect
The business: publishes /.well-known/ucp, runs the checkout endpoints, sets status and totals, and stays merchant of record. Source [9, 12, 31, 32, 55]
Goals
Sell through AI Mode, Gemini and other agent surfaces without one integration per platform
Keep the customer relationship, its PSP and its own terms
Hand off to its own web checkout whenever policy needs the buyer
Pains
Two-layer negotiation and full-replacement updates are easy to get subtly wrong
Attribution gaps when checkout happens on a platform surface
Reported automatic enrollment of Shopify merchants in Google's native checkout without an explicit opt-in
Implements
The business profile with capabilities, payment handlers and a keys array
REST or MCP checkout endpoints with idempotency storage of 24 to 48 hours
continue_url handoff, confirmation emails and signed order webhooks
Must trust
The platform profile and keys named in UCP-Agent
The credential provider's handler and the token its PSP receives
Google to route traffic as documented in its FAQ
Questions, first steps, metrics and a day in the life
Questions they ask
Which capabilities and extensions should we advertise first?
Does our PSP process Google tokens?
When should we return requires_escalation instead of an error?
First three steps
Read the v2026-08-25 overview and the checkout spec at the tag, not on main
Run the samples REST server and the conformance suite against it
Publish a minimal profile with checkout and one payment handler
Metrics they care about
Checkout completion rate by platform
Escalation rate and continue_url conversion
Idempotency conflicts (409) and duplicate orders
A day in the life
Dana leads commerce engineering at a home-goods retailer. Her team publishes a profile at /.well-known/ucp with checkout, fulfillment and a Google Pay handler, and keeps its own PSP. The first week, agent orders arrive through AI Mode, and the platform's profile and signature check out on every call. Large furniture orders need a delivery window that their API cannot take, so the checkout returns requires_escalation with a continue_url to the store's own page. Conversion on that path is lower, so she adds a scheduling field to the next release. The merchant-of-record question never comes up: refunds and disputes stay with her team, exactly as before.
The platform: an agent surface that discovers businesses, negotiates capabilities, fills checkouts and hands the buyer a trusted review screen. Source [12, 17, 18, 32]
Goals
Buy from many stores with one protocol
Keep the buyer in control of the final purchase
Pass payment without touching raw card data
Pains
Every business can advertise a different capability set and version
Permissionless onboarding means businesses may still block unknown platforms
Documentation drift between ucp.dev pages and the schemas
Implements
A platform profile with keys and an order webhook_url
Namespace authority checks and schema resolution
Payment handler execution and the trusted checkout UI
Must trust
The business profile and its schema URLs
Credential providers to issue valid tokens
Businesses to honor idempotency keys
Questions, first steps, metrics and a day in the life
Questions they ask
What happens if the complete response is lost?
Which handlers can we execute on our surface?
Do we need the AP2 extension to place orders without a human click?
First three steps
Publish a platform profile with an ES256 key
Implement the intersection and pruning rules against two test profiles
Wire the trusted review screen and the continue_url handoff
Metrics they care about
Share of businesses with a compatible intersection
Time from create to completed
Escalations per 100 checkouts
A day in the life
Ravi runs the shopping agent of a large assistant app. Each store his agent visits has a slightly different profile: one offers cart and loyalty, another only checkout. His code picks the highest common version, prunes the loyalty extension when checkout is missing, and sends the platform profile in UCP-Agent on every call. One night a store times out on complete. The agent polls Get Checkout, sees complete_in_progress, and waits instead of resending. The order shows up as completed an hour later, with one charge. Ravi adds the case to his test suite and moves on to identity linking.
The credential provider: writes a payment handler specification and issues opaque tokens to platforms. Source [9, 12, 13, 19, 56]
Goals
Make its wallet a payment option in every agent checkout
Keep raw credentials inside its own systems
Bind tokens to a merchant and a session
Pains
UCP defines the handler format but no concrete handler, so each provider documents its own
Platforms must execute the handler correctly on many surfaces
Google surfaces use Google Pay with PAN_ONLY, which limits token types there
Implements
A handler spec under its own reverse domain, for example com.google.pay
Token issuance to platforms
Optional AP2 support for user-signed mandates
Must trust
Platforms to run the handler as written
Businesses to configure merchant settings correctly
PSPs to accept its tokens
Questions, first steps, metrics and a day in the life
Questions they ask
Which credential type do we return: token, PAN or network token?
How do businesses publish our config?
Do we support the digital payment credential model of the AP2 extension?
First three steps
Read the payment architecture section of the overview
Publish a handler spec and schema under your own domain
Test with the samples and one PSP
Metrics they care about
Handler adoption by businesses
Token approval rate at PSPs
Share of checkouts using the handler
A day in the life
Ana works on a wallet team that wants its button in agent checkouts. She writes a handler spec under the wallet's own domain, because dev.ucp is reserved, and a schema for the business config. Businesses add the handler to their profile with their merchant id. Platforms run the handler, get a token bound to the merchant and session, and pass it in payment.instruments. Ana never sees the checkout itself, and the business never sees the card number. Her open question is AP2: the extension lets a wallet sign mandates with a key bound to a payment credential, but she has not found a deployment that does it yet.
The business's payment service provider: receives the token from the business, authorizes and settles, and may publish its own UCP handler. Source [9, 35, 39, 46, 56]
Goals
Process agent-originated tokens like any other card-not-present payment
Offer merchants a ready UCP handler
Support 3DS2 through UCP actions
Pains
Token formats differ by handler
No dispute rules specific to agent transactions
3DS state lives with the PSP, while the challenge surface lives with the platform
Implements
Token processing for Google and other handlers
A tokenization handler (Adyen) or a payments handler (Stripe)
Payment mandate verification if AP2 is used
Must trust
The business to forward tokens unchanged
The credential provider's token binding
Platforms to render 3DS challenges correctly
Questions, first steps, metrics and a day in the life
Questions they ask
Which handler do our merchants advertise?
How do we map UCP actions to our 3DS flow?
Who carries the loss when an agent misreads the buyer?
First three steps
Document which UCP handlers you can process
Publish a handler or tokenization guide
Map the authentication extension's actions to your 3DS server
Metrics they care about
Authorization rate for UCP-originated tokens
3DS challenge completion rate
Dispute rate on agent orders
A day in the life
Jonas manages agentic payments at a PSP. Merchants ask whether his platform can take tokens from UCP checkouts on Google, and the answer has to be yes, because the merchant's PSP must process Google's tokens. His team also publishes a tokenization handler that returns a token tied to the checkout session and merchant. When v2026-08-25 adds 3DS2 through actions, he maps device data collection and challenge to his existing 3DS server. UCP never carries the EMV messages, so his state machine stays where it was. Disputes still follow card rules, which he finds both reassuring and incomplete.
The buyer: asks an agent to shop, reviews and places the order, and deals with the merchant afterward. Source [8, 9, 21, 32]
Goals
Buy without filling in forms on every site
See the real seller, price and terms before paying
Get refunds and support from the store as usual
Pains
Not always clear who the seller is on an agent surface
Privacy and upselling concerns raised about agent checkout
Handoffs to a store web page in the middle of a purchase
Implements
Nothing; uses the platform's trusted checkout screen
Must trust
The platform to show the business's own checkout and links
The business as merchant of record
The wallet that issues the token
Questions, first steps, metrics and a day in the life
Questions they ask
Who is the seller?
Can the agent buy without me pressing buy?
Where do I go for a refund?
First three steps
Check the seller name and the terms link on the review screen
Use a wallet you already trust
Keep the order link from the confirmation email
Metrics they care about
Time to purchase
Number of handoffs
Refund and return experience
A day in the life
Maria asks Gemini to find a ceramic vase under $80 and buy it. The agent finds one at a store that supports UCP checkout, fills in her address and shows her a review screen with the store's name, the total and the store's terms. She presses buy and Google Pay supplies the payment. A confirmation email from the store arrives a minute later with an order link. When the vase arrives chipped, she returns it through the store's site, because the store, not Google, sold it to her. She never typed a card number, and the agent never placed the order without her tap.
The developer who builds a platform or business integration with the SDKs, samples and conformance tests. Source [7, 49, 57, 58, 59]
Goals
Get a working checkout against the samples in a day
Validate payloads against the release schemas
Pass the conformance suite
Pains
main is a draft and differs from the latest release
The conformance README still targets 2026-04-08
Examples spell some names differently from the schemas
Implements
@ucp-js/sdk or ucp-sdk models pinned to schema 2026-08-25
RFC 9421 signing with an ES256 key
Idempotency and lost-response handling
Must trust
The SDK version table
The schemas at the release tag
The sample server's behavior
Questions, first steps, metrics and a day in the life
Questions they ask
Which SDK version matches the release we target?
Do I sign requests or use OAuth?
How do I test escalation and 3DS paths?
First three steps
Install @ucp-js/sdk 0.5.x or ucp-sdk 0.5.x
Run the Python sample server and the happy path client
Validate a checkout response with the SDK schema
Metrics they care about
Conformance tests passed
Schema validation errors
Time to first completed checkout
A day in the life
Lee is building a UCP integration for a mid-size retailer. He installs ucp-sdk 0.5.0 because its table says it matches schema 2026-08-25, starts the sample server and runs the happy path client, which signs every request with a throwaway ES256 key. Everything works until he reads the spec on main and finds draft capabilities that are not in any release. He pins his schema URLs to the tag. The conformance suite's example config still says 2026-04-08, so he edits it and records the difference in his notes. By Friday his server returns valid checkouts and passes the idempotency tests.
Builds Tamarin models of x402, MPP, ACP and AP2 from their specifications, schemas and reference code using one shared abstraction of the agent payment lifecycle, then asks source-backed verification questions to expose missing bindings and cross-stage correspondences, which it consolidates into 18 security principles. Across 86 verification cases it reproduces 46 known or calibration cases, reports 40 new formal-consistency findings, and validates ten of them against x402 implementations with proofs of concept.
Why it matters here: The only side-by-side formal model of x402, stripe-mpp, openai-acp and ap2 so far; it shows where each specification leaves delegated authority, settlement and fulfillment unbound. AP2: Tamarin models that include AP2. ERC-8004: Trustless Agents: Formal models of agent payment protocols around ERC-8004. Agentic Commerce Protocol (ACP): Models ACP in Tamarin with x402, MPP and AP2; the only formal analysis that names it. Stripe MPP (Machine Payments Protocol): Models MPP in Tamarin alongside x402, ACP and AP2; the only formal analysis that names MPP. UCP: Formal analysis of agent payment protocols; the abstract does not name UCP but analyzes AP2, which UCP embeds as an extension. x402: Formal Tamarin models of x402 alongside MPP, ACP and AP2.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jiang2026formal,
title = {{A Formal Analysis of Agent Payment Protocols}},
author = {Ke Jiang and Mohan Yu and Yuan Chang and Mohit Kumar Jangid and Jianyu Niu and Cong Wang and Yinqian Zhang},
year = {2026},
eprint = {2609.00060},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.00060}
}
Models the checkout part of Google's Universal Commerce Protocol as a declarative Langshaw interaction protocol, implements agents for it in the Peach programming model, and shows those agents interoperating with UCP agents built by Google. The arXiv comment says it was presented at the EMAS workshop at AAMAS 2026.
Why it matters here: One of only two papers found on 2026-10-11 that analyze UCP by name; it shows that UCP checkout can be specified declaratively and checked for interoperability. UCP: Models UCP checkout as a declarative protocol and reports interoperation with Google's UCP agents; one of two papers that name UCP.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{christie2026strabo,
title = {{Strabo: Declarative Specification and Implementation of Agentic Interaction Protocols}},
author = {Samuel H. Christie and Amit K. Chopra and Munindar P. Singh},
year = {2026},
eprint = {2606.05043},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2606.05043}
}
Analyzes the AP2 mandate lifecycle and finds runtime enforcement gaps created by retries, concurrency and orchestration, then proposes a zero-trust runtime verifier that enforces explicit context binding and consume-once mandate semantics with time-bound nonces. Simulations at up to 10,000 transactions per second show both mechanisms are needed to stop replay and context-redirect attacks, at about 3.8 ms verification latency.
Why it matters here: Shows that ap2 (and ucp, which it also names as a mandate-based protocol) needs execution-time checks on mandates, not just signature validity at issuance. AP2: Replay and context-binding gaps in the mandate lifecycle. UCP: Names UCP and AP2 in its abstract; replay and context-binding failures in mandate-based protocols.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{lan2026zerotrust,
title = {{Zero-Trust Runtime Verification for Agentic Payment Protocols: Mitigating Replay and Context-Binding Failures in AP2}},
author = {Qianlong Lan and Anuj Kaul and Shaun Jones and Stephanie Westrum},
year = {2026},
eprint = {2602.06345},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2602.06345}
}
Surveys agent communication protocols with a two-dimensional classification (context-oriented versus inter-agent, general-purpose versus domain-specific), compares them on security, scalability and latency, and lays out directions such as layered architectures, privacy preservation and group interaction.
Why it matters here: Provides the taxonomy into which payment and commerce protocols (x402, AP2, ACP, UCP) slot as domain-specific layers above MCP and A2A. UCP: Survey of AI agent protocols for orientation.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2025protocols,
title = {A Survey of AI Agent Protocols},
author = {Yingxuan Yang and Huacan Chai and Yuanyi Song and Siyuan Qi and Muning Wen and Ning Li and Junwei Liao and Haoyi Hu and Jianghao Lin and Gaowei Chang and Weiwen Liu and Ying Wen and Yong Yu and Weinan Zhang},
year = {2025},
eprint = {2504.16736},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2504.16736},
note = {arXiv preprint}
}
Simulates conversations between an LLM-played user and an agent that has domain API tools and policy documents, grading by comparing the final database state to an annotated goal and introducing the pass^k reliability metric. Even strong function-calling agents succeeded on under half of the tasks and were inconsistent across trials, with pass^8 below 25 percent in retail.
Why it matters here: Its retail domain (orders, exchanges, refunds under policy) is the post-purchase side of ACP and UCP, and pass^k is the reliability framing merchants need before letting agents touch orders. Agentic Commerce Protocol (ACP): Retail tool-use benchmark close to ACP checkout tool calls.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{yao2025taubench,
title = {{$\tau$}-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains},
author = {Shunyu Yao and Noah Shinn and Pedram Razavi and Karthik Narasimhan},
year = {2025},
booktitle = {The Thirteenth International Conference on Learning Representations (ICLR 2025)},
url = {https://openreview.net/forum?id=roNSXZpUDN},
eprint = {2406.12045},
archivePrefix = {arXiv}
}
A reproducible environment of fully functional websites across e-commerce, forums, software development and content management, with tools and knowledge bases and a benchmark of long-horizon tasks graded on functional correctness rather than on action traces.
Why it matters here: Its e-commerce site is the standard sandbox for web shopping agents; Piet et al. and Shi et al. in this bibliography build their security arguments on it. UCP: Foundation benchmark for web agents that shop through ordinary sites, the path UCP replaces.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{zhou2024webarena,
title = {WebArena: A Realistic Web Environment for Building Autonomous Agents},
author = {Shuyan Zhou and Frank F. Xu and Hao Zhu and Xuhui Zhou and Robert Lo and Abishek Sridhar and Xianyi Cheng and Tianyue Ou and Yonatan Bisk and Daniel Fried and Uri Alon and Graham Neubig},
year = {2024},
booktitle = {The Twelfth International Conference on Learning Representations (ICLR 2024)},
url = {https://openreview.net/forum?id=oKn9c6ytLx},
eprint = {2307.13854},
archivePrefix = {arXiv}
}
A design-science study proposing a protocol-agnostic merchant-side architecture for agentic commerce built around a canonical decision envelope, protected dependency and result hashes, Ed25519 or HMAC authentication, live-request rebinding, a generated-claim gate and eleven semantic invariants, evaluated on an open-source JavaScript implementation with eight scenarios and five ablations; the author lists production security and interoperability as not established.
Why it matters here: Addresses what a merchant must keep authoritative when openai-acp, ucp or ap2 checkout messages arrive from agents, complementary to those protocol specifications. Agentic Commerce Protocol (ACP): Merchant-side reference architecture for agent commerce of the kind ACP serves.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{sfiris2026decisioncentered,
title = {{A Decision-Centered Reference Architecture for Trustworthy Agentic Commerce}},
author = {Dimitrios S. Sfiris},
year = {2026},
eprint = {2607.18347},
archivePrefix = {arXiv},
primaryClass = {cs.SE},
url = {https://arxiv.org/abs/2607.18347}
}
Treats reusable agent skills as externalized policies and presents SkillShift, a supply-chain attack that keeps a skill's declared task and output interface while covertly steering decisions toward an undisclosed objective. In agentic commerce and dependency selection it achieved attacker-favored selection rates of 81.33 and 63.33 percent with no utility loss, transferred across backends, and evaded the evaluated scanners.
Why it matters here: A merchant-steering attack that needs no prompt injection: a shopping agent's skill package can bias which seller wins an ACP or UCP checkout while every protocol message stays valid.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026skillshift,
title = {A Finger on the Scale: Covert Policy Steering through Agentic Skills},
author = {Jiarui Li and Jiahao Chen and Chunyi Zhou and Yuwen Pu and Oubo Ma and Zhou Feng and Chunqiang Hu and Shouling Ji},
year = {2026},
eprint = {2609.02564},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.02564},
note = {arXiv preprint}
}
A simulated consumer-to-consumer marketplace with 100 agents, eBay-derived inventories and reputation-based trust, scoring six failure types across five transaction stages over 357,608 model calls. All five tested models promise the same item to multiple buyers, and under adversarial instructions the share of committed sales completed despite unavailable items or overstated condition rises from 15.4 to 33.4 percent, with most extra earnings coming from goods the sellers never held.
Why it matters here: Tests whether reputation can hold a decentralized agent market together, the premise behind ERC-8004's Reputation Registry, and measures delegation failures that ACP and UCP style checkouts would inherit from the agents using them.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{wang2026bazaarbench,
title = {BazaarBench: Delegation Safety in Decentralized C2C Marketplaces Run by LLM Agents},
author = {Ziyan Wang and Shuqing Shi and James Oldfield and Samuele Marro and Jialin Yu and Philip Torr and Yali Du and Adel Bibi},
year = {2026},
eprint = {2610.06748},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2610.06748},
note = {arXiv preprint}
}
Introduces WebDecept, a plugin that injects seven deceptive interface patterns (targeted advertisements, domain redirection, shopping manipulation and others) into existing web environments, and evaluates multimodal web agents under them. Agents were highly susceptible to several classes of deception and prompt-based constraints were often insufficient.
Why it matters here: Measures the merchant-side manipulation surface that structured checkouts in UCP and ACP are meant to remove, and gives a baseline for how agents behave when they must still browse a storefront. UCP: Web agent safety under deceptive e-commerce interfaces, which a trusted review UI must withstand.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{shi2026deceptive,
title = {Benchmarking Web Agent Safety under E-commerce Deceptive Interfaces},
author = {Zijing Shi and Meng Fang and Ling Chen},
year = {2026},
booktitle = {Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers)},
publisher = {Association for Computational Linguistics},
pages = {22090-22103},
doi = {10.18653/v1/2026.acl-long.1009},
url = {https://aclanthology.org/2026.acl-long.1009/},
eprint = {2606.13686},
archivePrefix = {arXiv}
}
Analyzes 2,583 inter-agent emails from twenty one-year runs of Vending-Bench Arena across 13 frontier models and labels 12.6 percent as misaligned (false factual claims, manipulation, collusion or threats). Misalignment appears in every run and in 74.7 percent of agent-runs, is reciprocal, rises under inventory scarcity, and is not predicted by model capability rank.
Why it matters here: Agent-to-agent commerce protocols assume counterparties negotiate in good faith; this measurement shows deceptive speech acts emerging without adversarial prompting, which bears on reputation layers in ERC-8004 and on merchant-agent trust in ACP and UCP.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026misaligned,
title = {Emergent Misaligned Communication in Long-Horizon Multi-Agent LLM Commerce},
author = {Zeyuan Li and Lukas Petersson and Alessandro Acquisti and Michiel A. Bakker},
year = {2026},
eprint = {2608.14825},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2608.14825},
note = {arXiv preprint}
}
Argues that the most consequential risks in agentic commerce platforms sit in the protocol between agents and commerce services rather than in the model, documenting 33 structural vulnerabilities across three platforms that succeed deterministically regardless of model, three of which chain into a payment hijack. Contributes a taxonomy, AIP-Bench as a deterministic benchmark, and PCAT, a platform-agnostic defense that removes four of five structural attack classes.
Why it matters here: Cross-platform evidence that protocol design, not model alignment, decides the security of openai-acp, ap2 and ucp style checkout flows; the three platforms are not named in the abstract, so the mapping is unconfirmed. Agentic Commerce Protocol (ACP): Protocol-level attacks on agentic commerce platforms; does not name ACP but covers the same layer. UCP: Cross-platform attack taxonomy for agentic commerce platforms; context for section H.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{louck2026protocollevel,
title = {{Protocol-Level Attacks on Agentic Commerce Platforms: A Cross-Platform Taxonomy, AIP-Bench, and Unified Defense}},
author = {Yedidel Louck},
year = {2026},
eprint = {2607.21824},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.21824}
}
Argues that ReAct is the wrong default for web agents because product pages mix seller, reviewer and advertiser content, and that agents should commit to a task program before seeing runtime content. All WebArena tasks fit plan-then-execute and 80 percent can run as pure programs; the barrier is that browser actions lack typed, semantic interfaces.
Why it matters here: Makes the case for typed, task-level commerce APIs, which is what UCP and OpenAI ACP provide in place of clicks: structured checkout interfaces are a security measure, not only a convenience.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{piet2026plan,
title = {Web Agents Should Adopt the Plan-Then-Execute Paradigm},
author = {Julien Piet and Annabella Chow and Yiwei Hou and Muxi Lyu and Sylvie Venuto and Jinhao Zhu and Raluca Ada Popa and David Wagner},
year = {2026},
eprint = {2605.14290},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2605.14290},
note = {arXiv preprint}
}
Shows that an external provider controlling only content about its own product can redirect a proactive personal agent to recommend it, recruit the user's private context to justify it and lower adoption friction, without compromising the agent or gaining permissions. Across three environments and six user models the macro gain reaches 77.4 percentage points, and provider influence persists even when no final authorization is given.
Why it matters here: Models the merchant-side incentive to manipulate agent recommendations in ACP and UCP style markets, where the provider's own listing is the injection vector.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{wang2026provider,
title = {Who Is Your Agent Serving? Provider-Side Indirect Prompt Injection in Proactive Agents},
author = {Rui Wang and Chao Wang and Xinchen Wang and Yufeng Zheng and Binbin Liu and Yaofei Wang},
year = {2026},
eprint = {2610.05266},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2610.05266},
note = {arXiv preprint}
}
Provides a taxonomy of attacks specific to agent pipelines, organized by threat actor, objective, entry point, attacker observability, strategy and inherent pipeline weaknesses, and demonstrates simple, practical attacks on popular open-source and commercial agents.
Why it matters here: Documents that deployed browsing and shopping agents, the clients that ACP and UCP checkouts serve, can be steered by web content without any model jailbreak.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2025commercial,
title = {Commercial LLM Agents Are Already Vulnerable to Simple Yet Dangerous Attacks},
author = {Ang Li and Yin Zhou and Vethavikashini Chithrra Raghuram and Tom Goldstein and Micah Goldblum},
year = {2025},
eprint = {2502.08586},
archivePrefix = {arXiv},
primaryClass = {cs.LG},
url = {https://arxiv.org/abs/2502.08586},
note = {arXiv preprint}
}
ACWorld is an environment in which independently controlled buyer and merchant agents transact through a Vibe Commerce Protocol that validates each action before updating shared state and records the interactions for audit. Its benchmark has a 200-task capability track and a 60-task large-catalog track over 785,022 listings; ten models score 65.9 to 85.6 percent and 56.1 to 91.4 percent, and process-level evidence catches errors that final state misses.
Why it matters here: A reproducible testbed for the buyer-agent to merchant-agent transaction loop that OpenAI ACP and UCP standardize, with an audit-log design relevant to dispute handling.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{fan2026acworld,
title = {Agentic Commerce World: An Auditable and Verifiable Environment for Vibe Commerce},
author = {Shicheng Fan and Mingdai Yang and Duohao Wang and Canyu Chen and Yongfeng Zhang and Hua Wei and Manling Li and Julian McAuley and Kun Zhang and Philip S. Yu and Kejing Yu and Zhiwei Liu},
year = {2026},
eprint = {2608.02441},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2608.02441},
note = {arXiv preprint}
}
A search-theoretic model that compares manual product search, which evaluates a few products accurately, with agentic search, which screens a broad catalog through noisy representations of preferences. Manual search collapses beyond a preference-complexity threshold and platform revenue falls to zero, while agentic search avoids the collapse; the paper derives how platforms should set agent refinement depth.
Why it matters here: Supplies the economic rationale for the discovery and product-feed layers of UCP and OpenAI ACP: once consumers delegate search, platform revenue depends on how well the agent elicits preferences rather than on how many items a person inspects. UCP: Economics of agentic commerce, from product search to preference articulation.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{dong2026preference,
title = {From Product Search to Preference Articulation: The Economics of Agentic Commerce},
author = {Lingxiu Dong and Kaiwen Luo and Fasheng Xu},
year = {2026},
eprint = {2608.08395},
archivePrefix = {arXiv},
primaryClass = {econ.TH},
url = {https://arxiv.org/abs/2608.08395},
note = {arXiv preprint}
}
LLM merchant agents fabricate product attributes in most listings under competitive pressure even when told to be honest. CARP, a reputation-penalty mechanism with a deadband that forgives complaint noise and a state-dependent severity, suppresses low-rated liars without any product-level ground truth, and SPARC makes the penalty behaviorally binding so merchants restrain themselves once lying costs sales.
Why it matters here: Shows how a platform-level reputation penalty can govern seller agents behind ACP or UCP storefronts using only noisy complaints, a design that could sit on top of ERC-8004 feedback entries.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2026honesty,
title = {Paying for Honesty Without Knowing the Truth: Reputation-Penalty Design for LLM Marketplace Agents},
author = {Mingdai Yang and Shicheng Fan and Kejing Yu and Duohao Wang and Li Sun and Hao Peng and Philip S. Yu and Zhiwei Liu},
year = {2026},
eprint = {2607.28330},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2607.28330},
note = {arXiv preprint}
}
Using Tool-Lab, a process-tracing setup that hides product attributes behind costly tool calls, the authors test eight deployed LLMs from three providers against just-below pricing and promotional framing. Cues rarely mislead when information is free, but under acquisition costs and a vague goal the agents skip the attributes needed to compute unit price and make heuristic, suboptimal choices much like people.
Why it matters here: Shows that storefront information architecture and tool cost shape what agents buy, which matters for how merchants expose product data in ACP and UCP feeds and for proposals to sell product information per fact over x402. Agentic Commerce Protocol (ACP): Agents as surrogate consumers; behavior behind ACP purchases.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{wadi2026shopping,
title = {Shopping by algorithm: How agentic AI deploys human heuristics as a surrogate consumer},
author = {Davood Wadi and Yu Ma},
year = {2026},
eprint = {2609.28372},
archivePrefix = {arXiv},
primaryClass = {econ.GN},
url = {https://arxiv.org/abs/2609.28372},
note = {arXiv preprint}
}
Argues that the deepest economic effect of generative AI is lower communication friction between consumers and businesses, with assistant agents and service agents transacting programmatically. The authors separate unscripted interactions, enabled by language and protocol design, from unrestricted interactions, which depend on market structure and governance, and discuss walled gardens versus an open agent web, advertising and discovery, micro-transactions and the rebundling of digital goods.
Why it matters here: The clearest economic framing of why ACP, UCP and AP2 exist: its assistant-agent and service-agent split maps onto the buyer-agent and merchant roles those protocols standardize, and its walled-garden warning is the open question behind all of them, with x402 as the micro-transaction case.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{rothschild2026agenticeconomy,
title = {The Agentic Economy},
author = {David M. Rothschild and Markus M. Mobius and Jake M. Hofman and Eleanor Dillon and Daniel G. Goldstein and Nicole Immorlica and Sonia Jaffe and Brendan Lucier and Aleksandrs Slivkins and Matthew Vogel},
year = {2026},
journal = {Communications of the ACM},
volume = {69},
number = {2},
pages = {39-42},
doi = {10.1145/3747175},
url = {https://doi.org/10.1145/3747175},
eprint = {2505.15799},
archivePrefix = {arXiv}
}
Studies agentic recommendation markets in which a user agent states a need first and platforms compete for its attention. Across three product domains, broader access does not translate into exposure, platforms answer with selectively positive explanations in 73 to 78 percent of first-ranked positions, and tying platform behavior to later user feedback cuts this to 36 to 41 percent while raising purchases of the relevant item.
Why it matters here: Models the merchant-side incentives that UCP and ACP discovery surfaces create when many sellers answer one agent's query, and argues that access, attention and accountability must be designed as one mechanism. Agentic Commerce Protocol (ACP): Platform competition in agentic recommendation, context for ranking and fees. UCP: Economics of agentic recommendation markets and platform competition.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{hong2026platforms,
title = {The User Asks, Platforms Compete: How Agentic Recommendation Markets Take Shape},
author = {Deyao Hong and Kehan Zheng and Qian Li and Jun Zhang and Jie Jiang and Hongning Wang},
year = {2026},
eprint = {2607.25253},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2607.25253},
note = {arXiv preprint}
}
Proposes a framework for the Agentic Web built on three dimensions (intelligence, interaction, economics), traces its evolution from the PC and mobile web, and discusses communication protocols, orchestration and an Agent Attention Economy together with governance risks.
Why it matters here: Its economics dimension and attention-economy discussion anticipate the discovery and monetization questions that UCP, ACP and x402 are now standardizing.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2025agenticweb,
title = {Agentic Web: Weaving the Next Web with AI Agents},
author = {Yingxuan Yang and Mulei Ma and Yuxuan Huang and Huacan Chai and Chenyu Gong and Haoran Geng and Yuanjian Zhou and Ying Wen and Meng Fang and Muhao Chen and Shangding Gu and Ming Jin and Costas Spanos and Yang Yang and Pieter Abbeel and Dawn Song and Weinan Zhang and Jun Wang},
year = {2025},
eprint = {2507.21206},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2507.21206},
note = {arXiv preprint}
}
Places LLM sellers in simulated continuous double auctions and tests when they collude, defined as secret cooperation that harms another party. Direct seller communication increases collusion, propensity differs by model, and oversight or urgency from authority figures changes collusive behavior.
Why it matters here: Relevant to any multi-seller agent market on ACP, UCP or x402: giving seller agents a channel to talk to each other is itself a competition risk.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{agrawal2025collusion,
title = {Evaluating LLM Agent Collusion in Double Auctions},
author = {Kushal Agrawal and Verona Teo and Juan J. Vazquez and Sudarsh Kunnavakkam and Vishak Srikanth and Andy Liu},
year = {2025},
eprint = {2507.01413},
archivePrefix = {arXiv},
primaryClass = {cs.GT},
url = {https://arxiv.org/abs/2507.01413},
note = {arXiv preprint}
}
Introduces Magentic-Marketplace, an open-source simulated two-sided market in which assistant agents represent consumers and service agents represent competing businesses, and uses it to measure utility, behavioral bias, vulnerability to manipulation and the effect of search mechanisms. Frontier models approach optimal welfare only under ideal search, degrade sharply with scale, and show a severe first-proposal bias that gives response speed a 10 to 30 times advantage over quality.
Why it matters here: Discovery and checkout protocols such as UCP and OpenAI ACP create the two-sided agent markets this environment simulates, so its first-proposal and search findings bear directly on how merchant feeds and ranking should be designed. Agentic Commerce Protocol (ACP): Simulated agent marketplaces; context for agent-mediated checkout. UCP: Simulated agentic marketplaces; useful to reason about many platforms meeting many businesses.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{bansal2025magentic,
title = {Magentic Marketplace: An Open-Source Environment for Studying Agentic Markets},
author = {Gagan Bansal and Wenyue Hua and Zezhou Huang and Adam Fourney and Amanda Swearngin and Will Epperson and Tyler Payne and Jake M. Hofman and Brendan Lucier and Chinmay Singh and Markus Mobius and Akshay Nambi and Archana Yadav and Kevin Gao and David M. Rothschild and Aleksandrs Slivkins and Daniel G. Goldstein and Hussein Mozannar and Nicole Immorlica and Maya Murad and Matthew Vogel and Subbarao Kambhampati and Eric Horvitz and Saleema Amershi},
year = {2025},
eprint = {2510.25779},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2510.25779},
note = {arXiv preprint}
}
Builds an experimental framework in which consumer and merchant LLM agents negotiate and transact with each other. Outcomes differ sharply across models, and behavioral anomalies lead to overspending or acceptance of unreasonable deals, producing losses for both sides.
Why it matters here: Agent-to-agent negotiation is the step before an ACP or UCP checkout and before an AP2 mandate is signed; the paper quantifies the asymmetry and loss risk users accept when they delegate the deal itself.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhu2025risky,
title = {The Automated but Risky Game: Modeling and Benchmarking Agent-to-Agent Negotiations and Transactions in Consumer Markets},
author = {Shenzhe Zhu and Jiao Sun and Yi Nian and Tobin South and Alex Pentland and Jiaxin Pei},
year = {2025},
eprint = {2506.00073},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2506.00073},
note = {arXiv preprint}
}
Using ACES, a provider-agnostic framework for auditing agent decisions, the authors measure how LLM shopping agents choose among products. They find demand concentrating on a few modal products, preferences that reshuffle with model updates, strong position biases that persist even in text-only interfaces, and consistent reactions to sponsored tags and platform endorsements.
Why it matters here: Checkout protocols such as OpenAI ACP and UCP move the purchase decision into an agent; this paper quantifies the ranking and position biases merchants and platforms inherit when the agent, not a person, picks the product. Agentic Commerce Protocol (ACP): How agents choose products, relevant to feed-driven discovery in ChatGPT. UCP: Shows how agent buyers are biased by placement and model choice, which matters for platform checkout.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{allouah2025buying,
title = {What Is Your AI Agent Buying? Evaluation, Biases, Model Dependence, & Emerging Implications for Agentic E-Commerce},
author = {Amine Allouah and Omar Besbes and Josué D Figueroa and Yash Kanoria and Akshit Kumar},
year = {2025},
eprint = {2508.02630},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2508.02630},
note = {arXiv preprint}
}
A simulated e-commerce site with 1.18 million real products and 12,087 crowd-sourced instructions in which an agent must search, customize and buy an item. It introduced compositional instruction following, query reformulation and noisy web text as grounding challenges and collected over 1,600 human demonstrations for training.
Why it matters here: The ancestor of every agentic shopping benchmark; the search, option selection and checkout steps it scripted are what ACP and UCP now turn into protocol messages. Agentic Commerce Protocol (ACP): Foundational shopping-agent benchmark.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{yao2022webshop,
title = {WebShop: Towards Scalable Real-World Web Interaction with Grounded Language Agents},
author = {Shunyu Yao and Howard Chen and John Yang and Karthik Narasimhan},
year = {2022},
booktitle = {Advances in Neural Information Processing Systems 35 (NeurIPS 2022)},
url = {https://proceedings.neurips.cc/paper_files/paper/2022/hash/82ad13ec01f9fe44c01cb91814fd7b8c-Abstract-Conference.html},
eprint = {2207.01206},
archivePrefix = {arXiv}
}
Builds the standard model of competition between two-sided platforms that must attract both buyers and sellers, showing how price structure, not just price level, determines adoption, with payment cards as a leading example.
Why it matters here: Every agentic checkout protocol is a two-sided platform bet; this model explains the subsidy and fee choices behind merchant and agent adoption of ACP, UCP and card network programs. Agentic Commerce Protocol (ACP): Two-sided market economics behind platform fees on merchants. UCP: Two-sided platform economics behind a protocol that joins agent surfaces and merchants.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{rochet2003platform,
title = {{Platform Competition in Two-Sided Markets}},
author = {Jean-Charles Rochet and Jean Tirole},
year = {2003},
journal = {Journal of the European Economic Association},
volume = {1},
number = {4},
pages = {990--1029},
doi = {10.1162/154247603322493212},
url = {https://doi.org/10.1162/154247603322493212}
}
Grey literature: central banks, standards drafts and white papers
Christoph Busch. 2026. CERRE Issue Paper. Not peer reviewed
An issue paper (published 2026-07-16) asking whether EU consumer law, built on the assumption that a human makes the final purchase decision, is ready for AI shopping agents, and proposing how to adapt it. It is part of CERRE's Regulatory Lab series, which received input from members including Apple, Booking.com and Microsoft.
Why it matters here: Checkout protocols such as ACP and UCP assume the agent can confirm a purchase; this paper explains where EU disclosure and consent rules may not fit that flow. Agentic Commerce Protocol (ACP): Consumer protection analysis of agentic commerce including ACP.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@techreport{busch2026cerre,
title = {{Agentic AI and Consumer Protection}},
author = {Christoph Busch},
year = {2026},
institution = {Centre on Regulation in Europe (CERRE)},
type = {Issue Paper},
month = {jul},
url = {https://cerre.eu/publications/agentic-ai-and-consumer-protection/}
}
T. Meunier, S. Major. 2026. IETF Internet-Draft draft-ietf-webbotauth-httpsig-protocol-00 (Web Bot Auth working group). Not peer reviewed
The first Web Bot Auth working group draft (revision 00, 2026-09-01) for identifying automated HTTP clients with HTTP Message Signatures. It defines the Signature-Agent header for in-band key discovery, a JWKS-based key directory format and a well-known URI for serving it.
Why it matters here: The Visa TAP spec calls itself aligned with Web Bot Auth, Cloudflare says the Visa and Mastercard agent protocols build on it, and UCP offers an optional Web Bot Auth profile; this working group draft, posted almost a year after TAP launched, is the standards-track form of that request signing. Mastercard Agent Pay: The HTTP Message Signatures draft for automated traffic that Agent Pay's edge verification resembles. Visa Trusted Agent Protocol: The IETF working group draft TAP is compared against.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{meunier2026webbotauth,
title = {{HTTP Message Signatures for automated traffic}},
author = {T. Meunier and S. Major},
year = {2026},
howpublished = {Internet-Draft draft-ietf-webbotauth-httpsig-protocol-00, IETF},
note = {Work in progress, 2026-09-01},
url = {https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/}
}
Aaron Cheris, Mikey Vu, Stephanie Koszyk and others. 2025. Bain & Company Snap Chart. Not peer reviewed
A short forecast (2025-12-17) estimating the US agentic commerce market at $300 billion to $500 billion by 2030, about 15% to 25% of e-commerce, with specification-driven purchases such as household essentials moving first.
Why it matters here: Another anchor for the forecast range used in the atlas market pages; Bain counts transactions that agents start, influence or complete.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{cheris2025bain,
title = {{2030 Forecast: How Agentic AI Will Reshape US Retail}},
author = {Aaron Cheris and Mikey Vu and Stephanie Koszyk and Katherine Hall},
year = {2025},
howpublished = {Bain \& Company},
note = {Snap Chart, 2025-12-17. Forecast figures as of publication},
url = {https://www.bain.com/insights/2030-forecast-how-agentic-ai-will-reshape-us-retail-snap-chart/}
}
Morgan Stanley Research. 2025. Morgan Stanley Insights article. Not peer reviewed
A research summary (2025-12-08) forecasting that agentic shoppers could account for $190 billion to $385 billion of US e-commerce spending by 2030, 10% to 20% of the market, and citing a survey in which about 23% of Americans bought something through AI in the past month.
Why it matters here: A mid-range market forecast with survey data on current AI-assisted buying; it marks how far analyst expectations sit from the small measured protocol volumes.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{morganstanley2025shoppingbots,
title = {{Here Come the Shopping Bots}},
author = {{Morgan Stanley Research}},
year = {2025},
howpublished = {Morgan Stanley},
note = {Article, 2025-12-08. Forecast figures as of publication},
url = {https://www.morganstanley.com/insights/articles/agentic-commerce-market-impact-outlook}
}
Katharina Schumacher, Roger Roberts, Katharina Giebel. 2025. McKinsey & Company report. Not peer reviewed
A consulting report (2025-10-17) estimating that agents could orchestrate $900 billion to $1 trillion of US B2C retail revenue by 2030 and $3 trillion to $5 trillion globally, counting goods only. It discusses the infrastructure, business models and trust needed for that shift.
Why it matters here: The largest of the widely cited market forecasts; useful as the upper bound when the atlas compares adoption claims, and it is a forecast, not measured volume.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{schumacher2025mckinsey,
title = {{The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants}},
author = {Katharina Schumacher and Roger Roberts and Katharina Giebel},
year = {2025},
howpublished = {McKinsey \& Company},
note = {Report, 2025-10-17. Forecast figures as of publication},
url = {https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants}
}
UCP authenticates the parties and protects messages: platforms are identified by a profile URL and its keys, requests, responses and webhooks can carry RFC 9421 signatures with a Content-Digest, replay is stopped by signed idempotency keys, and credentials flow one way as opaque tokens. It deliberately leaves out trust in a platform's intent, spending limits and reputation, and onboarding is permissionless, so abuse handling (discovery budgets, SSRF guards, allowlists) falls on each business. Without the AP2 extension the final safeguard is a human placing the order in a trusted UI. No advisory or CVE naming UCP existed on 2026-10-11, and two arXiv papers name UCP.
STRIDE threats (13)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Platform impersonation with a copied profile URLAn attacker sends requests that name a well-known platform's profile in UCP-Agent without holding its key, hoping the business trusts the header alone. Source [12, 17]Preconditions: The business authenticates with an API key or not at all; The business does not bind the principal to the profile.Impact: Orders and data requests attributed to a trusted platform.
Partly
Verify RFC 9421 signatures against the keys in the named profile, or confirm that the API key, OAuth client or mTLS identity may act for that profile, as the spec requires.
S Spoofing
Namespace squatting on shared hosting suffixesA party publishes a capability under a namespace on a shared suffix such as github.io, where co-tenants share a registrable domain; authority binding passes because the Public Suffix List is not consulted. Source [12]Preconditions: The platform accepts capabilities from arbitrary namespaces; The namespace sits on a shared suffix.Impact: A look-alike capability schema is accepted as provenance-checked.
Partly
Treat authority binding as provenance, not trust. Allowlist vendor namespaces and declare entities only under a registrable domain you control.
S Spoofing
Stale compromised signing keyA leaked key stays in the profile keys array and keeps verifying. Source [12, 17]Preconditions: Key compromise; Slow profile updates and long caches.Impact: Forged requests or merchant authorizations accepted.
Partly
Remove compromised keys from keys immediately; a key is not effectively revoked until it is absent; keep cache max-age short enough for rotation.
T Tampering
Body tampering by an intermediaryA proxy or gateway rewrites or re-serializes the JSON body of a signed request, changing amounts or items. Source [12, 17]Preconditions: Requests pass through a component that parses and re-serializes JSON.Impact: Changed orders, or valid requests rejected with digest_mismatch.
Mitigated by spec
Sign with Content-Digest over the raw bytes and forbid re-serialization at proxies; verify the digest before parsing.
T Tampering
Checkout altered between display and completionThe business or a man in the middle changes totals after the buyer reviewed them, and the platform completes against the new state. Source [19, 32]Preconditions: AP2 extension not negotiated; The platform does not re-read the checkout before complete.Impact: Buyer charged for something other than what they approved.
Partly
Without AP2, show the latest checkout in the trusted UI immediately before complete. With AP2, the merchant signature and the checkout mandate bind the exact checkout.
T Tampering
Duplicate orders through retriesA platform retries a lost complete call with a new idempotency key, or a business fails open when its idempotency store is down. Source [17, 32]Preconditions: Network timeout on complete; Idempotency storage unavailable.Impact: Two orders and two charges.
Mitigated by spec
Resend only the identical request with the same key after polling Get Checkout; businesses keep keys 24 to 48 hours and fail closed with 503.
R Repudiation
Disputed purchase with no signed evidenceA buyer says the agent bought something they did not approve, and neither side holds a signed record of consent. Source [19, 32, 35]Preconditions: AP2 extension not used; No logs of the trusted UI confirmation.Impact: Liability falls back to card dispute rules with weak evidence.
Partly
Keep the trusted UI confirmation, the order permalink and the confirmation email. The AP2 extension stores JCS-canonical mandates as durable evidence.
R Repudiation
Forged order webhooksAn attacker posts fake shipment or refund events to a platform's webhook_url. Source [17, 38]Preconditions: The webhook URL is known; The platform does not verify signatures or signer identity.Impact: False order status shown to buyers; refunds or support actions on false data.
Mitigated by spec
Webhooks must be RFC 9421 signed; reject events whose signer profile does not match the order's business and reconcile with GET /orders/{id}.
I Information disclosure
Payment credential leakageA business echoes a credential back, logs it, or a platform handles raw PAN data it should not touch. Source [12, 13, 32]Preconditions: PAN credential type in use; Logging of request bodies.Impact: Card data exposure and PCI DSS scope creep.
Partly
Credentials flow one way and must not be echoed; prefer token or network_token types; keep handler logic with the credential provider.
I Information disclosure
Over-sharing buyer data with the platformCheckout payloads carry buyer email, addresses, signals such as buyer IP, and order history to the platform surface. Source [12, 18, 50]Preconditions: Identity linking or signals in use.Impact: Privacy exposure and regulatory risk under GDPR and similar laws; concerns raised in a senator's letter (reported).
Partly
Share only what the capability needs; do not persist signals beyond operational need; scope identity linking tokens narrowly.
D Denial of service
Discovery amplification against businessesMany unknown platform profiles force the business to fetch and parse remote documents on every request. Source [12]Preconditions: Permissionless onboarding; No profile cache or rate limit.Impact: Resource exhaustion at the business.
Partly
Bound discovery cost with a fixed-size cache, a global rate limit, backoff or asynchronous discovery answering 503 with Retry-After; keep a registry of pre-approved platforms.
E Elevation of privilege
Server-side request forgery through profile URLsA platform names a profile URL that resolves to an internal or metadata address, so the business fetches internal resources. Source [12]Preconditions: The business fetches profile, jwks_uri or CIMD URLs without address checks.Impact: Access to cloud metadata or internal services.
Mitigated by spec
Reject non-HTTPS URLs, redirects and special-use IP ranges such as 169.254.169.254, and check resolved addresses against DNS rebinding.
E Elevation of privilege
Downgrade away from AP2 protectionAn attacker or buggy client tries to complete a session without a mandate after AP2 was negotiated. Source [19, 23]Preconditions: AP2 extension in the intersection.Impact: Unprotected checkout despite a negotiated mandate requirement.
Mitigated by spec
Once negotiated the session is security locked; the business must reject complete without ap2.checkout_mandate (mandate_required).
Attack scenarios
An injected tool result steers the agent to a look-alike store Source [12, 60]
Preconditions: The agent follows links from untrusted content; The buyer approves quickly in the review screen.
A web page tells the agent to buy from a look-alike domain
The look-alike publishes a valid profile at /.well-known/ucp
Negotiation and signatures succeed because they prove identity, not honesty
The buyer approves a checkout that shows the look-alike's name
Impact: Payment to the wrong seller; recovery depends on card dispute rules.
Preconditions: The platform does not implement the lost-response rules.
The platform calls complete and times out
It sends a new complete with a fresh idempotency key
The business treats it as a new operation
Impact: Duplicate order and charge.
Profile URL used to probe internal services Source [12]
Preconditions: The business fetches any URL in UCP-Agent.
An attacker sends UCP-Agent with a URL that resolves to 169.254.169.254
The business fetches it to read the profile
Metadata leaks through error messages or timing
Impact: Exposure of cloud credentials or internal data.
Published research findings
Protocol-Level Attacks on Agentic Commerce Platforms: A cross-platform attack taxonomy for agentic commerce; the abstract does not name UCP, so read it as context. (paper in section G) Source [62]
Strabo: Declarative Specification and Implementation of Agentic Interaction Protocols: Models UCP checkout as a declarative protocol and reports interoperation with Google's UCP agents; useful for checking state and message ordering. (paper in section G) Source [61]
Zero-Trust Runtime Verification for Agentic Payment Protocols: Names UCP and AP2 as mandate-based protocols and studies replay and context-binding failures, proposing runtime verification. (paper in section G) Source [60]
CVEs and advisories
No CVE or advisory is recorded for this protocol as of the last verification.
UCP natively covers agent identity (profile plus keys), expiry, key and token revocation, replay protection through idempotency keys, and monitoring signals. Consent, step-up, payee scoping, evidence and disputes are partial and depend on optional extensions (AP2, authentication) or on the business and PSP. Spending caps and reputation are absent. A controls layer acts best at the platform before complete, at the trusted review screen, and at the business edge where profiles are fetched.
Platform profile URL in UCP-Agent with RFC 9421 signatures against its keys, or API key, OAuth or mTLS bound to that profile. Source [12, 17]
Agent registration (know your agent)
Partial
Permissionless by design; businesses should keep a registry of pre-approved platforms. No know-your-agent registry. Source [12]
User consent capture
Partial
Buyer places the order in a trusted UI unless AP2 is active; buyer_consent map; AP2 checkout_mandate as signed consent. Source [19, 24, 32]
Spending caps
External
No cap field; limits live in AP2 mandates, the credential provider or the platform. Source [19, 33]
Merchant or payee scoping
Partial
Tokens are handler-specific and some (Adyen) are bound to session and merchant; AP2 mandates bind the merchant-signed checkout. Source [19, 56]
Time windows and expiry
Native
Checkout expires_at defaults to 6 hours; mandate_expired in the AP2 extension. Source [23, 33]
Revocation
Native
Remove keys from the profile; RFC 7009 token revocation required for identity linking; OpenID RISC recommended. Source [12, 18]
Step-up authentication
Partial
requires_escalation handoff through continue_url; 3DS2 device data collection and challenge actions in the optional authentication extension. Source [32, 39]
Replay protection
Native
Signed Idempotency-Key with 128-bit entropy, 24 to 48 hour storage and 409 on mismatch; Web Bot Auth shape adds nonce. Source [17]
Receipts and evidence
Partial
Order with permalink_url and a required confirmation email; AP2 mandates kept as JCS-canonical evidence. Source [19, 32]
Dispute support
Partial
Order adjustments can record disputes, refunds and returns; dispute handling stays with the business and PSP. Source [35]
Reputation
None
No reputation mechanism for platforms or businesses. Source [12]
Monitoring signals
Native
signals such as dev.ucp.buyer_ip and dev.ucp.user_agent, plus signed order webhooks. Source [12, 38]
Kill switch
Partial
Businesses can refuse platforms, answer 503 or cancel sessions; no protocol-level global stop. Source [9, 12]
No spending limits. Nothing in the checkout schema caps what an agent may buy; limits must come from AP2 mandates, the wallet or the platform. Source [19, 33]
Identity is not trust. Signatures and authority binding prove who a platform or schema author is, not that it behaves well, and there is no reputation layer. Source [12]
Consent evidence is optional. Without AP2 the only consent record is the platform's trusted UI and the business confirmation email; live AP2 use is unverified. Source [19, 32]
Permissionless onboarding. Any platform with a profile can call any business, so each business must build its own allowlists and discovery budgets. Source [12]
Disputes outside the protocol. Adjustments can record a dispute, but chargeback rules and liability stay with card networks and PSPs. Source [35]
Where an independent controls layer can act
Before authorization
Decide whether the agent may buy from this business at all. Allowlist businesses and capability namespaces at the platform; check the intersection and the advertised handlers before create. Source [12]
At signing
Bind consent to the exact checkout. Show the latest checkout in a trusted UI immediately before complete, or negotiate the AP2 extension so the checkout mandate covers the merchant-signed checkout. Source [19, 32]
At the edge
Filter unknown or abusive platforms. Verify signatures, enforce pre-approved platform registries, cache and rate-limit profile fetches, and apply SSRF guards at the business edge. Source [12, 17]
At settlement
Apply payment risk checks. PSP fraud screening and 3DS2 through the authentication extension's actions. Source [39]
After the fact
Reconcile and detect anomalies. Verify signed order webhooks, reconcile with GET /orders/{id}, and track adjustments. Source [35, 38]
Implementer checklist
Pin schema URLs to the release tag you target, not main. main carries drafts that are in no release. Source [7]
Bind every authenticated principal to the profile named in UCP-Agent. The header alone is not authentication. Source [12]
Store idempotency keys for 48 hours and fail closed when storage is down. Prevents duplicate orders on retries. Source [17]
Implement the lost complete response rules exactly. A new key on retry can place a second order. Source [32]
Reject profile URLs on special-use IP ranges and never follow redirects. Stops SSRF through UCP-Agent. Source [12]
Remove compromised keys from keys immediately and keep cache lifetimes short. A key stays valid until it is absent. Source [12]
Verify webhook signatures and the signer's match with the order business. Stops forged order events. Source [38]
Set spending limits outside UCP for unattended agents. The protocol has no cap field. Source [19]
J. Compliance and regulation
Not legal advice. This is a study summary of public rules as of the dates cited. Ask counsel about your situation.
UCP is a checkout protocol on existing card rails, so most rules land where they already do: the business is merchant of record, its PSP handles authentication, AML screening and disputes, and card and payment-services law decides liability. The new questions are consent (who approved what, which the trusted UI or an AP2 mandate records), AI transparency, and the data a platform sees. UCP checkout runs in the US today, with Canada, Australia and the UK announced. Rows are dated; check each source.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
UCP checkouts on Google are card payments with the business as merchant of record, so credit card disputes follow Regulation Z: unauthorized use means use without actual, implied or apparent authority, and liability is capped at $50. Whether an agent acting outside the buyer's wishes had apparent authority is untested. Source [9, 63]
Verified
United States
For debit-funded payments, Regulation E excludes transfers by someone the consumer gave the access device to, until notice. A buyer who lets an agent pay may carry that loss until they withdraw authority. Source [64]
Verified
European Union
PSD2 requires payer consent to the specific transaction and caps payer liability for unauthorized ones. The trusted UI confirmation, or an AP2 checkout mandate, is the evidence of consent. Source [32, 69]
Verified
United Kingdom
Under the Payment Services Regulations 2017 a payment is authorized only with payer consent (regulation 67), and payer liability for misappropriated instruments is capped at GBP 35 (regulation 77). Google said UCP checkout would reach the UK after Canada and Australia. Source [29, 73, 74]
Verified
Canada
No agent-specific payment liability rule was found; Google said UCP checkout would roll out in Canada in the coming months (as of 2026-05-20). Source [29, 78]
Unverified
Singapore
The E-Payments User Protection Guidelines allocate liability for unauthorized and erroneous e-payments. No UCP deployment in Singapore was found. Source [82]
Verified
Card network rules
No public Visa or Mastercard rule is specific to agent-initiated transactions as of 2026-10-11; tokenized agent payments follow existing rules, and Worldpay says no liability shift exists yet (reported). Source [86]
Reported
AML and sanctions
United States
UCP has no AML or sanctions layer of its own; screening stays with the merchant's PSP and the card networks. OFAC obligations apply as for any card payment. Source [12, 67]
Verified
Canada
The Retail Payment Activities Act has required PSPs to keep risk management and safeguarding frameworks since 2025-09-08; it applies to the merchant's PSP, not to UCP itself. Source [80, 81]
Verified
Strong customer authentication
European Union
Remote card payments need strong customer authentication with dynamic linking under the RTS on SCA. UCP's authentication extension carries 3DS2 device data collection and challenges as actions; the PSP owns the 3DS state. Source [39, 68]
Verified
United Kingdom
HM Treasury's consultation (2026-07-14 to 2026-10-06) asks how authentication, consent and liability should adapt for agentic payments; no response yet. Source [75]
Verified
Card network rules
EMVCo published a draft EMV Agentic Payments framework on 2026-09-01; UCP carries 3DS2 through actions but does not re-specify EMV 3DS. Source [39, 87]
Verified
AI-specific rules
United States
No federal statute or CFPB rule governs AI shopping agents. A senator's letter dated 2026-02-03 asked Google about data sharing and upselling in Gemini checkout built on UCP (reported). Source [50, 65]
Reported
European Union
AI Act Article 50 transparency applies from 2026-08-02: a buyer must know they deal with an AI system. A shopping agent is not high-risk by default. Source [70, 71]
Verified
United Kingdom
No AI statute; the FCA applies existing rules and will consider with HM Treasury whether agentic payments need changes. Source [76]
Reported
Singapore
MAS Guidelines on AI Risk Management (issued 2026-10-07, effective 2027-10-07) name agentic AI systems and apply to financial institutions, such as PSPs, that use them. Source [83, 84]
Verified
Data protection
United States
California's CCPA rules on automated decisionmaking technology apply from 2026-01-01; checkout data shared with an agent platform and signals such as buyer IP are personal information. Source [12, 66]
Verified
European Union
GDPR applies to buyer data in checkouts, identity linking and signals; the UCP overview says PII and payment data must follow PCI DSS and GDPR guidance. Source [12, 72]
Verified
United Kingdom
The Data (Use and Access) Act 2025 amends UK GDPR rules on automated decision-making. Source [77]
Verified
Canada
PIPEDA governs private-sector personal information such as checkout and identity-linking data. Source [79]
Verified
Singapore
The Personal Data Protection Act 2012 applies to buyer data (statute site blocked; reported). Source [85]
Reported
Card network rules
The checkout spec says a business does not need PCI DSS compliance to accept cards through the checkout capability, because it receives tokens; a business that accepts the pan credential type is back in scope. Source [13, 32]
Verified
K. Observability lens
2 of 5 observability score
Business profiles at /.well-known/ucp are public and cacheable, so anyone can see which capabilities, transports, handlers and keys a domain advertises.
No public registry, index or explorer of UCP businesses exists, so finding profiles means crawling domains (unverified absence as of 2026-10-11).
Checkouts, orders, tokens and webhooks are bilateral and private; no ledger or public log records transactions.
Governance and releases are public: GitHub releases, Discussions, announcements and a meeting-minutes repository.
No merchant counts or volumes are published by Google or the project.
Publicly observable
Public signals
What
Where
How
Business profiles
https://{domain}/.well-known/ucp
HTTP GET; Cache-Control public with max-age of at least 60 seconds. Shows ucp.version, services, capabilities, payment_handlers and keys. Source [11, 12]
UCP-Agent plus User-Agent beginning Google/UCP; health checks with Google-UCP-Prober/1.0. Source [9]
Private by design
Checkout sessions and orders. Point-to-point REST, MCP or A2A calls between platform and business.
Payment credentials and AP2 mandates. Opaque tokens flow platform to business to PSP; never published.
Order webhooks (orderEvent). Sent to the platform's webhook_url with Webhook-Id and Webhook-Timestamp.
Embedded checkout messages. ec.*, ep.cart.* and action.* JSON-RPC messages stay inside the host frame.
Identity linking tokens. OAuth tokens between platform and business authorization server.
What an indexer or monitor could capture
UCP support and capability sets per domain from Crawl of /.well-known/ucp across merchant domains: ucp.version, capability names, payment handler names, service endpoints, keys[].kidSource [11, 12]
Release adoption from ucp.version and supported_versions in crawled profiles, compared with versions.json: ucp.version, supported_versions keysSource [11, 42]
Payment handler mix from payment_handlers registries in crawled profiles: com.google.pay, dev.shopify.shop_pay, vendor handler namesSource [12]
AP2 extension availability from Profiles listing dev.ucp.common.payment.ap2_mandate (advertised support, not live use): dev.ucp.common.payment.ap2_mandate, vp_formats_supportedSource [19]
Project activity from GitHub API for the Universal-Commerce-Protocol organization: releases, tags, stars, DiscussionsSource [3, 88]
L. Ecosystem and adoption
Stewards
UCP Governing Council: Owns all UCP assets; 5 seats (Google and Shopify permanent, Stripe elected, 2 open as of 2026-10-11). Source [1, 2]
Google: Launched UCP, holds a permanent seat and the proxy vote for open seats until December 2028, custodian of ucp.dev. Source [1, 4]
Shopify: Co-developer and permanent council seat. Source [1, 5]
Domain Tech Councils (Shopping, Food, Lodging, Payments): 16-seat councils (some seats permanent), members elected every 6 months; Payments council includes Adyen, Ant International, Coinbase, Global Payments, PayPal and Stripe. Source [1, 26]
Implementers and deployments
Implementers (9)
Name
Role
Status
Google AI Mode in Search and Gemini
Platform; UCP checkout for US shoppers, starting with Etsy and Wayfair on 2026-02-11. Source [8, 9]
Live
Etsy and Wayfair
Businesses live on Google surfaces from 2026-02-11. Source [8]
Live
Shopify, Target and Walmart
Businesses; Google said on 2026-02-11 that their checkout through UCP was coming soon. Source [8]
Announced
Shopify merchants (native checkout on Google)
Reported automatic enrollment of eligible US merchants around 2026-09-22 (secondary only). Source [31]
Unknown
Google Universal Cart
Google shopping product that uses UCP for checkout (announced 2026-05-19). Source [20]
Announced
Microsoft Copilot Checkout and Merchant Center
Copilot Checkout requires a UCP-compliant feed; Microsoft says MMC will support UCP (future tense). Source [22]
Announced
Stripe
Documents a Stripe Payments handler for UCP. Source [46]
Live
Adyen
Documents a UCP Tokenization Handler bound to checkout session and merchant. Source [56]
crates.ioucp-schema (external link) version 1.4.1: Runtime resolution of UCP schema annotations; 2026-08-03.
Metrics
Metrics, each with its date and definition
Metric
Value
As of
Definition and caveats
Co-developer organizations listed on ucp.dev
21 organizations
Unique names across the Shopping, Lodging and Food co-developer lists. Source [10] Caveat: Google appears in three verticals (23 logo slots); a count of names, not of integrations.
Endorsers listed on ucp.dev
51 organizations
Names in the endorser list on the homepage. Source [10] Caveat: Endorsement is not deployment.
Co-developed with Shopify, Etsy, Wayfair, Target and Walmart; over 20 endorsers. The v2026-01-11 git tag and GitHub release were created on 2026-01-23.
Run the sample business server and the happy path clientUCP samples (rest/python) commit cdb291c (2026-10-05)Command linebash
# from rest/python/serveruv run server.py \ --products_db_path=/tmp/ucp_test/products.db \ --transactions_db_path=/tmp/ucp_test/transactions.db \ --port=8182# from rest/python/client/flower_shopuv run simple_happy_path_client.py --server_url=http://localhost:8182
Edit a business and an agent profile to see the negotiated capabilities, the chosen version and why each extension was pruned, then drive a checkout through escalation, payment-handler selection and the same call as REST, MCP and A2A messages. Simulation only, fixture stores and handlers, no network.
Simulation, no real fundsFollows spec version 2026-08-25
Loading the simulation.
Keys are generated in this browser for this session only, on test chain identifiers or fixture data. No wallet connects and nothing is sent to a network.
P. Compare and compose
OpenAI’s ACP is the closest sibling: both specify agent checkout sessions in which the merchant stays . No bridge or mapping between them is specified, and no source supports the idea that they are converging.Source [2, 22, 26, 27] The overlap is in people more than in wire formats. Stripe co-develops ACP and holds UCP Governing Council and Tech Council seats.Source [2, 26, 27] The economics differ as reported: a 4% ChatGPT checkout fee for Shopify merchants, against no additional fee “for now” on Google and Microsoft surfaces.Source [54] Pick UCP when you need discovery and negotiation across many agent surfaces from one profile; compare the two in the matrix before you commit.
AP2 sits inside UCP, not beside it. When both sides negotiate dev.ucp.common.payment.ap2_mandate, the business signs every checkout, the platform returns an checkout mandate that wraps that signature, and the payment mandate rides in the credential token.Source [19] Google’s FAQ calls AP2 a specialized payment layer within UCP, and Google said on 2026-05-19 that AP2 would come to its products starting with Gemini Spark.Source [9, 20] Until a source shows mandates in production, treat this as specified, not deployed.Source [19, 20]? unverified
The card protocols meet UCP at the credential and at the signature. UCP’s network_token type can carry a with its , yet Google’s AI surfaces use Google Pay with PAN_ONLY, and which network’s agentic token flows inside a handler is not published.Source [9, 16]? unverified Visa TAP and UCP both use RFC 9421, and UCP’s optional Web Bot Auth shape follows the same direction TAP aligns with. Visa and Mastercard are listed endorsers, but no bridge is documented.Source [10, 17] x402, Stripe MPP and ERC-8004 have no documented link. Coinbase’s seat on the Payments Tech Council is governance overlap, not a technical one.Source [2, 12, 46]
Relations to other protocols
Embedsfrom AP2: UCP embeds AP2 through the extension dev.ucp.common.payment.ap2_mandate (renamed in v2026-08-25): merchant signature in ap2.merchant_authorization, Checkout Mandate in ap2.checkout_mandate, Payment Mandate in the credential token. Live use unverified. Source [23, 92, 93]
Compatible withfrom Mastercard Agent Pay: Verifiable Intent says its credentials can travel in UCP's AP2 mandate extension (now dev.ucp.common.payment.ap2_mandate). Mastercard endorses UCP; no Agent Pay integration is documented. Source [94, 95, 96]
Competes withfrom Agentic Commerce Protocol (ACP): Both define merchant-hosted agent checkout sessions; five status names match and both publish well-known discovery documents, but no bridge or mapping exists. Stripe supports both. Source [97, 98, 99]
Compatible withUCP to Mastercard Agent Pay: The network_token credential type (number, cryptogram, eci_value, token_requestor_id) can carry network tokens in general; no Agent Pay integration is documented, and Google surfaces use Google Pay PAN_ONLY. Source [9, 10, 13]
Competes withUCP to Agentic Commerce Protocol (ACP): Both specify agent checkout with the merchant as merchant of record; no bridge or mapping is specified. Stripe co-develops ACP and sits on UCP councils. Source [2, 21, 26]
ComplementsUCP to Visa Trusted Agent Protocol: Both use RFC 9421 HTTP Message Signatures and UCP added optional Web Bot Auth interop; the UCP spec never names TAP and no bridge is documented. Visa is a listed endorser. Source [10, 17]
EmbedsUCP to AP2: AP2 is an optional UCP extension, dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate before v2026-08-25). UCP places the merchant authorization, checkout mandate and payment mandate; AP2 defines the formats. Live use is unverified. Source [9, 19, 23, 45]
Same stewardUCP to AP2: Google launched both; Google donated AP2 to the FIDO Alliance on 2026-04-28 while UCP stays under its own Governing Council. Source [1, 28]
Complementsfrom Visa Trusted Agent Protocol: Intelligent Commerce Connect accepts UCP payments and Visa is listed as a UCP endorser; UCP has its own RFC 9421 signing, closer to the Web Bot Auth draft, and never names TAP. Source [10, 17, 100]
UCP in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
Agent checkout, carts and orders with capability negotiation Discovery at /.well-known/ucp, negotiation, then checkout over REST, MCP, A2A or embedded.Source [12, 32]
Verified
Layers covered
Discovery, checkout and orders, payment credential handoff, identity linking; mandates only through the AP2 extension No settlement rail of its own.Source [12, 19]
Verified
Stewards
UCP Governing Council; Google and Shopify permanent, Stripe elected Google is custodian of ucp.dev.Source [1, 2]
Verified
Governance model
Council-owned, no foundation; Google proxy for open seats until December 2028 Domain Tech Councils of 16 seats, some permanent, decide by majority.Source [1]
Verified
License (spec and code)
Apache-2.0 (UCP Authors) Contributors sign the Google CLA.Source [1, 3]
Rail-agnostic handlers; cards via the merchant's PSP in practice Credential types token, PAN, network token.Source [9, 12, 13]
Verified
Agent identity model
Domain-based platform profile plus JWK keys; RFC 9421, OAuth, API key or mTLS Authenticated principal must be bound to the profile in UCP-Agent.Source [12, 17]
Verified
User authorization model
Buyer places the order in a trusted UI; optional AP2 checkout mandate Identity linking with OAuth 2.0 for signed-in actions.Source [18, 19, 32]
Verified
Human-present and human-not-present support
Human present by default; human not present only with AP2 (specified, unverified live) Source [19, 20, 32]
Verified
Merchant of record
The business Google and Microsoft are not merchant of record.Source [9, 21, 22]
Verified
Credential type
Opaque handler token, PAN or network token Google surfaces: Google Pay PAN_ONLY.Source [9, 13]
Verified
Cryptography
RFC 9421 with Content-Digest; ES256 baseline; JWS and SD-JWT in the AP2 extension Source [17, 19]
Verified
Replay protection
Signed Idempotency-Key, 24 to 48 hour storage, 409 on mismatch Source [17]
Verified
Native spending controls
None in UCP Caps come from AP2 mandates, the wallet or the platform.Source [19, 33]
Verified
Revocation
Key removal from the profile; RFC 7009 token revocation for identity linking Source [12, 18]
Verified
Refunds and disputes
Order adjustments record refunds, returns and disputes; handling stays with merchant and PSP Source [35]
Verified
Privacy exposure
Platform sees buyer data, signals and order history; credentials are opaque Privacy and upselling concerns raised in a senator's letter (reported).Source [12, 50]
Verified
Discovery mechanism
/.well-known/ucp business profile No public registry of businesses.Source [12]
Verified
Permissionless or registration required
Permissionless; businesses may keep allowlists Google surfaces need Merchant Center onboarding.Source [12, 55]
Verified
Decentralization
Federated by domain, governance concentrated at Google Google holds proxy votes and the domain.Source [1, 12]
Verified
Observability score
2 of 5 Public profiles and governance; transactions private.Source [10, 12]
Verified
Fees and who pays them
No protocol fee; Google says no cut (reported); merchant pays its PSP Google, Microsoft checkouts reported with no additional fee for now.Source [9, 54, 89]
MisconceptionIs UCP the same as Google's Universal Cart?
No. UCP is the open Universal Commerce Protocol. Universal Cart is a Google shopping product, announced on 2026-05-19, that uses UCP for checkout. Source [20]
MisconceptionDoes Google become the merchant of record?
No. In the spec and in Google's FAQ the business is the merchant of record and keeps financial liability and the order. Microsoft says the same for Copilot Checkout. Source [9, 21, 22]
MisconceptionIs AP2 another name for UCP?
No. AP2 is an optional extension inside UCP, dev.ucp.common.payment.ap2_mandate since v2026-08-25. UCP says where the AP2 signatures go and AP2 defines the mandate formats. Live use of AP2 mandates in UCP is unverified as of 2026-10-11. Source [9, 19, 20, 23, 24, 25]? unverified
MisconceptionDoes UCP process payments?
No. The platform gets an opaque token from a credential provider and passes it to the business, which charges it through its own PSP. Credentials flow one way. Source [12, 21]
MisconceptionCan an agent buy without the buyer pressing buy?
Not in the base protocol. Without the AP2 extension, the agent must hand the checkout to a trusted, deterministic UI where the buyer places the order. Source [32]
MisconceptionAre UCP capabilities versioned independently since 2026-08-25?
Only third-party ones. The release notes speak of independent capability versioning, but the normative spec ties every dev.ucp capability to the release date; vendor extensions version on their own. Source [12, 24]
MisconceptionIs ES256 the only signature algorithm?
No. Every implementation must be able to verify ES256, and ES384 and EdDSA are optional. Source [17]
MisconceptionDoes Microsoft support UCP today?
Microsoft's page uses the future tense: Merchant Center will support UCP. Copilot Checkout already requires a UCP-compliant feed. Source [22]
Where does a business publish its profile?
At /.well-known/ucp. The platform publishes its own profile at the URL it names in the UCP-Agent header. Source [12]
What happens when a checkout needs something the API cannot collect?
The business returns requires_escalation with a continue_url and a message whose severity is requires_buyer_input or requires_buyer_review, and the platform opens continue_url for the buyer. Source [32]
Does Google take a fee?
Google told The Register it does not plan to take a cut (reported), and reports say Google and Microsoft checkouts carry no additional fee for now. Google publishes no fee schedule; since the merchant keeps its own PSP, its normal processing fees presumably still apply, which is an inference. Source [9, 54, 89]? unverified
Who governs UCP?
A Governing Council with permanent seats for Google and Shopify, an elected seat for Stripe and 2 open seats; Google holds the proxy vote for open seats until December 2028. There is no foundation. Source [1, 2]
MisconceptionHas any paper studied UCP?
Yes, two arXiv papers name it: 2606.05043 (Strabo) models UCP checkout, and 2602.06345 studies replay and context binding in UCP and AP2. Source [60, 61]
R. Open questions and research frontier
Will the AP2 extension run in production, and where first?
The extension is specified and Google said AP2 would reach its products starting with Gemini Spark, but no public source shows mandates in a live UCP checkout as of 2026-10-11. Source [19, 20]
How many merchants and how much volume?
Neither Google nor the project publishes merchant counts or volumes; the only figures are co-developer and endorser lists and a February claim of hundreds of interested companies. Source [8, 10]
Will governance move to a neutral body?
Google holds proxy votes for open seats until December 2028 and custody of ucp.dev, and there is no foundation. AP2 moved to FIDO; UCP has announced no such move. Source [1, 28]
Will non-Google platforms go live on UCP checkout?
Microsoft requires a UCP-compliant feed for Copilot Checkout and says Merchant Center will support UCP; whether Copilot runs UCP checkout calls, not only feeds, is unclear. Source [22]
Will Google Pay on AI surfaces move beyond PAN_ONLY?
Google's FAQ limits allowed_auth_methods to PAN_ONLY on its AI surfaces, so network tokens and agentic tokens are not in that path today. Source [9, 13]
Will UCP and ACP converge or bridge?
No source supports convergence and no mapping is specified, although Stripe works on both. Source [2]
How will merchants consent and measure attribution?
Reports of automatic Shopify enrollment and attribution gaps on platform surfaces raise questions the spec does not answer; the attribution field carries campaign parameters but no model. Source [12, 31]
Can formal models catch negotiation and lifecycle bugs?
Strabo models UCP checkout declaratively; the two-layer negotiation and backports into dated releases are natural targets for formal checking. Source [12, 61]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
/.well-known/ucp
T. Notes
Notes stay in this browser. Nothing is sent anywhere.