Google's UCP puts four headers on every checkout. Three exist for the argument afterwards

On January 11, 2026, Google published the Universal Commerce Protocol — an open-source standard for letting AI agents buy things — co-developed with Shopify and endorsed by more than 20 partners including Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa and Zalando.

The coverage that followed was about shopping. Agents that browse for you, agents that check out for you, the end of the shopping cart, and so on.

Then you read the specification, and the shopping turns out to be the least interesting thing in it. What UCP standardises with unusual care is not the purchase. It is the evidence that the purchase happened the way both parties say it did.

TL;DR:

• Every mutating UCP request carries four headers, and three of them — request-signature, idempotency-key, request-id — do nothing for the transaction itself. They exist so that afterwards, someone can prove what was asked, prove it was asked once, and find it again.
• Non-repudiation is a named feature. The optional AP2 mandates extension (dev.ucp.shopping.ap2_mandate) has businesses cryptographically sign the checkout terms while platforms supply cryptographic mandates proving the user authorised them. The spec's stated purpose: "significantly reducing risks of tampering and disputes."
• The endorsement number is not an adoption number. "Over 20 global partners" is what Google published, and it describes endorsement. As of this writing we found no primary source giving a count of live UCP merchant integrations.

Header set taken from Google's own launch-day walkthrough. Sources listed at the end.

What UCP is, in the fewest words that stay true

Before the argument, the facts you can look up. These come from the specification published at ucp.dev and from Google's developer blog, both retrieved September 5, 2026.

Two things in that table are worth pausing on, because most write-ups skip both.

The first is the transport row. UCP is not an MCP thing, and it is not a REST thing. The same declared data is offered over REST, MCP, A2A and an embedded binding, and the business picks. That is a deliberate refusal to bet on which agent plumbing wins.

The second is date-based versioning. 2026-04-08 is not a semantic version, it is a day. The spec's stated reason is chronological ordering and unambiguous comparison — but the practical effect is that every negotiated session records the date of the rules it was conducted under. That is an archival decision dressed up as a versioning decision, and it sets the tone for everything else in the document.

The bottleneck it was built to kill

Google's framing is an N×N problem. Every business that wants to appear inside a conversational surface has to build a bespoke connection to each one; every surface has to onboard each business separately; nobody ships.

Shopify's engineering write-up, published the same day by distinguished engineer Ilya Grigorik, comes at the same problem from underneath. After 20+ years, billions of transactions and millions of merchants, the lesson is that commerce refuses to normalise: "payment options and rules differ based on properties of the cart, buyer, and market; discounts have stacking and combination rules that can rival the tax code; fulfillment options explode with runaway permutations." The conclusion is the sentence worth keeping: "This complexity is not a bug, it's an emergent property of diverse retailers."

That single line explains the entire architecture. If you accept that merchants are irreducibly different, you cannot standardise the behaviour. You can only standardise how a merchant declares its behaviour, and how an agent finds out what it just agreed to.

The structure a business publishes at /.well-known/ucp. Source: UCP specification 2026-04-08, Overview.

Discovery happens before the conversation starts

Here is the flow, as the spec and Google's walkthrough describe it. It is worth following literally, because the ordering is the argument.

1. The business publishes a profile at /.well-known/ucp. It declares a protocol version, one or more services (dev.ucp.shopping), the capabilities inside them, the transports and endpoints, the available payment handlers, and — this matters later — its public signing_keys.
2. The agent announces its own profile on every request, via a UCP-Agent header using RFC 8941 dictionary syntax: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". On MCP transport the same thing rides in a meta object.
3. The business computes the intersection. For every capability it supports, it keeps the ones the platform also declares; for each survivor it selects the highest version present in both arrays; if there is no mutual version, the capability is dropped entirely.
4. Orphaned extensions are pruned. An extension declaring extends: "dev.ucp.shopping.checkout" disappears if checkout did not survive. The pruning repeats until nothing more is removed, which handles transitive chains.
5. The business selects. UCP uses a server-selects architecture: the merchant, not the agent, decides what is live for the session, and echoes the active capability registry back in the response.

Naming is governed rather than conventional. Every capability is {reverse-domain}.{service}.{capability} — dev.ucp.shopping.checkout for the standard one, com.example.payments.installments for a merchant's own. A retailer can invent a capability nobody else has without asking permission and without colliding with anyone, because the reverse domain is the authority.

Failure has its own taxonomy, and the split is instructive. The spec separates discovery failures (transport errors — invalid_profile_url returns 400, profile_unreachable returns 424, profile_malformed returns 422) from negotiation failures, which are business outcomes and come back as a normal 200 with capabilities_incompatible in the body. "I could not reach you" and "we have nothing in common" are different events, and UCP refuses to blur them into one 400.

Four headers ride on every mutating request

Now look at an actual call. This is Google's own launch-day example, creating a checkout session against a sample flower shop:

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Four headers. Ask what each one is for, and a pattern falls out.

Three of the four are not for the transaction. They are for the disagreement about the transaction.

That is not an accident of API hygiene. Idempotency keys and request IDs are ordinary good practice in payments, yes — but the spec goes considerably further, and the further it goes, the clearer the intent becomes.

Non-repudiation is a design goal, not a compliance afterthought

UCP lists four authentication mechanisms a business may accept: API keys, OAuth 2.0, mTLS, and HTTP Message Signatures per RFC 9421. Three of those are ordinary. The fourth is doing something specific.

Under message signatures, both parties publish public keys in the signing_keys array of the very same profile document that declares their capabilities. A verifier pulls the keyid out of the Signature-Input header, matches it to a kid in the signer's published key set, and checks the signature. No shared secret, no registration, no account. The spec calls the result permissionless onboarding: "any platform with a discoverable profile can interact with any business without prior registration."

Identity binding closes the obvious hole. Whatever mechanism is used, verifiers must confirm that the authenticated principal is actually authorised to act for the profile named in UCP-Agent, and reject the request where the two conflict. You cannot authenticate as yourself and then claim to be someone else's agent.

And webhooks going from business to platform must be signed. Not should — must. Order-lifecycle updates about shipping, delivery and returns are the one place in the protocol where the requirement is absolute, because they are the messages that arrive after the money moved and that nobody is watching in real time.

Source: UCP specification 2026-04-08, Identity & Authentication and Transaction Integrity sections.

Then there is the top of the ladder. For autonomous agents and high-value transactions, UCP defines an optional extension, dev.ucp.shopping.ap2_mandate. When both sides negotiate it:

• the business provides a cryptographic signature on the checkout terms, and
• the platform provides cryptographic mandates proving the user authorised them.

The agent signs the mandate objects using the user's private key on a non-agentic surface — that is, the human authorises on a screen they control, not inside the agent loop that is about to spend their money. The spec's own statement of purpose is worth quoting exactly, because it is not a security boilerplate sentence: this "provides strong, end-to-end cryptographic assurances about transaction details and participant consent, significantly reducing risks of tampering and disputes."

Here is the point. A protocol designed only to let agents shop would need none of this. Signed terms on the merchant side and signed mandates on the user side are not features of buying. They are features of arguing about buying, six weeks later, in front of someone who has to decide who was right.

Where the framing outruns the evidence

Three things get repeated about UCP that the primary sources do not support as stated.

"20+ partners" is an endorsement count. Google's wording is that UCP was "co-developed and endorsed by more than 20 partners." Endorsement is a public statement of support. It is not a shipped integration, and it is certainly not a live merchant. We looked for a primary source giving the number of merchants transacting over UCP and did not find one.

"Open standard" and "Google's standard" are both true, and the tension is real. The spec is open-source, the GitHub repo takes pull requests, and the naming convention deliberately lets anyone claim their own namespace. Also: Google built the first reference implementation, and to participate in that implementation a business needs an active Google Merchant Center account with checkout-eligible products. Neutral protocol, gated first venue.

UCP does not remove the merchant. This gets garbled often enough to be worth stating plainly: under UCP the business keeps its own business logic and remains the Merchant of Record. Shopify's Embedded Checkout Protocol makes the same commitment in the other direction — when a flow needs a human, the agent loads a continue_url and the merchant's real checkout renders inside the agent's surface over a JSON-RPC 2.0 channel, with the merchant finalising the transaction. The agent is a surface, not a substitute.

Four things we could not verify, marked as such

The spec published at ucp.dev at retrieval time is version 2026-04-08, and its standard capability list — Cart, Checkout, Identity Linking, Order — differs from the January 11 walkthrough, whose examples run version 2026-01-11 and show checkout, discount and fulfillment. Something was added between those dates. We could not find a primary changelog identifying when, or a dated release note for the intervening versions, so we are reporting the difference rather than a release event.

We found no published count of merchants live on UCP, from Google, Shopify, or any of the endorsing partners. Absence of a number is not evidence of a small number, but it is the reason we are not printing one.

Google states it built the first reference implementation powering purchases inside AI Mode in Search and the Gemini app. We have not independently verified the availability, geography or scale of that rollout.

Whether UCP becomes the agentic commerce standard is, at the time of writing, unknowable, and any post that tells you otherwise is guessing. The honest read is narrower: a specification exists, it is public, it is unusually careful about proof, and several very large companies signed the announcement.

The unsigned half

Step back from commerce, because the interesting part generalises.

UCP describes a world in which a machine acts on your behalf and every step of that action leaves something behind: who asked, signed; what terms, signed; how many times, keyed; in what order, correlated. Six weeks later, when the charge is disputed, there is an artifact. Nobody has to remember.

Now think about where the authority for those actions actually comes from. An agent buys 400 units because a procurement decision was made. A vendor contract renews because someone agreed to a term. A scope changes because two people talked it through on a Thursday and one of them said yes.

Those conversations are the unsigned half of the same workflow. The machine end of it is being built with cryptographic receipts and a specification that treats disputes as a first-class scenario. The human end of it, in most organisations, is somebody's memory, somebody else's different memory, and a summary written from both.

The asymmetry is going to get worse before it gets better, because the machine half is improving on a specification's timeline and the human half is not improving at all. And the failure mode is specific: it is not that people lie. It is that a derived artifact — a summary, a set of minutes, an action-item list — gets treated as the record once the thing it was derived from is gone. Summaries are lossy by construction. That is what makes them useful. It is also what makes them a bad primary source, and there is no way to tell a lossy summary from an accurate one after the original has been discarded.

UCP's designers understood this at the protocol layer and wrote it down: keep the signed original, derive whatever you like from it, and make sure the derivation can always be checked against something that has not moved. It is a discipline, not a technology, and it applies exactly as well to an hour of people talking as it does to a POST /checkout-sessions.

The bottom line: agentic commerce is a receipts standard wearing a shopping costume

The Universal Commerce Protocol is usually described as a way for AI agents to buy things. Read end to end, it is better described as an attempt to answer a question that agentic anything is about to face constantly: when a machine acted for me, what exactly can be proven about what I agreed to?

UCP's answer is a good one — declare your capabilities in public, sign the terms, sign the consent, key the retry, correlate the call, and sign the webhook that reports what happened afterwards. Whether the protocol wins is genuinely open. The question it is built around is not going away regardless of who wins it.

Which leaves a question worth sitting with. Your agents are about to have better records of what they agreed to than you have of what you agreed to. Where does that end?

---

Where Telli.sh fits: we build the unsigned half. Telli.sh records the conversation, separates the speakers, translates across 15 languages as it happens, and keeps the original recording and full transcript alongside every summary it generates — so the derived artifact never becomes the only artifact. Telli.sh does not implement UCP and makes no claim to; it addresses the other end of the same problem, which is that the decisions authorising agent behaviour are usually made out loud and kept nowhere.

Record your next decision meeting

Sources

• Universal Commerce Protocol specification, Overview, version 2026-04-08 — services, capabilities and extensions model, naming convention, date-based versioning, the capability intersection algorithm, negotiation and signature error codes, standard capabilities (Cart, Checkout, Identity Linking, Order), transports, the UCP-Agent header and RFC 8941 syntax, authentication mechanisms and permissionless onboarding, key discovery via signing_keys, identity binding, mandatory webhook signing, and the Transaction Integrity and Non-Repudiation section; retrieved September 5, 2026
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)," January 11, 2026 — the partner list and 20+ endorsement figure, AP2/A2A/MCP compatibility, the N×N framing, the /.well-known/ucp manifest, the five-step walkthrough and the POST /checkout-sessions header set, Merchant of Record and the embedded option, the Google reference implementation in AI Mode and Gemini, and the Merchant Center requirement; retrieved September 5, 2026
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol," January 11, 2026 — the 20+ years / billions of transactions / millions of merchants framing, the "not a bug, it's an emergent property of diverse retailers" argument, the four design principles, and the Embedded Checkout Protocol handoff over JSON-RPC 2.0 via continue_url; retrieved September 5, 2026
• Agent Payments Protocol (AP2) — the payments protocol UCP declares compatibility with
• Universal Commerce Protocol on GitHub — the open-source repository named in both announcements
• Our read of GPT-6 Astra and what the capture layer still decides — the same argument from the model side: reasoning quality is capped by whatever produced the record it reasons over