Universal Commerce Protocol (UCP) - Coming to an agent near you

Overview

Agentic payment ideas predate even agents themselves. But now that they exist, how do you ensure they do what they are supposed to? That is, in the direction of a human, provide accurate information and securely process the payment. In another one of my blog posts, How x402 Will Change The World , I cover x402 as one piece of this puzzle. Another approach has come from Google’s orbit addressing a different layer of agentic commerce.

The Universal Commerce Protocol is a new open source protocol for agent-to-agent payments positioned as an industry-led effort, with Google and a set of large merchants and platforms publicly listed as collaborators (Shopify, Etsy, Wayfair, Target, Walmart). The interesting part isn’t that agents can shop but rather that UCP tries to make agent commerce legible: explicit user intent, constrained authority, and cryptographic receipts that can survive disputes.

What's UCP Made Of?

The protocol is built on Agent Payments Protocol (AP2), an extension of Agent2Agent (A2A) protocol. While A2A is how agents communicate, AP2 adds a standard way to express purchase authority, user presence, and proofs of intent. That's a lot of acronyms to say: the language between AI agents is being standardized to increase interoperability and reduce dependency on a probabilistic model to “do the right thing.”

The best agent is the one least used. The forefront of agentic development tells us to limit agent interpretation as much as possible to maintain bounded execution. LLMs are probabilistic and give you the likely best response, not necessarily the accurate one. We as developers can mitigate this greatly by pulling core functionality into code and relegating the AI to simply pull the right levers to move the data around without even needing to read it.

What UCP Aims to Deliver

Surface-agnostic (channel-independent)

In practice: the same purchase flow should work whether the user is in chat, voice, a browser, or an embedded assistant without rewriting merchant commerce logic for every UI surface. Additionally, the protocol should be unopinionated about the underlying technology, allowing for a wide range of use cases. Businesses own their own logic and data and remain the Merchant of Record; the legal entity responsible for selling goods or services to a customer and processing their payments.

A business should be able to use UCP without the outside influence of Google or otherwise.

Open and interoperable

The protocol is open source for anyone to review and contribute to. It's designed to be extensible to allow for continued improvement and modularity for future use cases.

Secure and private

The abstraction of the identification and payment facilitation details is implemented through the use of the protocol, but not defined by it. In this way there is security and a separation of concerns between parties, maximizing privacy.

Verifiable intent (not inferred action)

Purchases should be verifiable and auditable from both the user and the merchant. An agent should not be trusted to give correct information but should instead pass verifiable information to the counterparty.

Find more information about the goals at ucp.dev

Is UCP x402?

Not really. They solve adjacent problems at different layers.

x402 is about making this request payable. UCP/AP2 are about making agent commerce verifiable and permissioned across parties. Further, UCP aims to delegate authority with constraints, capture explicit user intent, and produce receipts that hold up in audits and disputes.

Under The Hood

If we peek under the hood, we see the protocol services these goals by using what is called verifiable digital credentials (VDCs). AP2 breaks the intents down succinctly as follows:

The Intent Mandate: This VDC captures the conditions under which an AI Agent can make a purchase on behalf of the user, particularly in "human-not-present" scenarios. It provides the agent with authority to execute a transaction within defined constraints.

The Cart Mandate: This VDC captures the user's final, explicit authorization for a specific cart, including the exact items and price, in "human-present" scenarios. The user's cryptographic signature on this mandate provides non-repudiable proof of their intent.

The Payment Mandate: A separate VDC shared with the payment network and issuer, designed to signal AI agent involvement and user presence (human-present or not) to help assess transaction context.

Found at ap2-protocol.org

The mandates work as signed objects passed between the parties. The intent is to be verifiable and deterministic. If an agent were to change the payload of the mandate, it would invalidate the object and thus invalidate the transaction. The signed objects double as dispute resolution mechanisms, showing what each party signed for and providing an audit trail for remediation.

The UCP Happy Path

User grants an agent limited authority (budget, merchant whitelist, category constraints).
Agent builds a cart with the merchant and requests explicit user approval (human-present) or uses delegated authority (human-not-present).
The approval is encoded as a signed credential/mandate.
Payment proceeds using existing rails, but carries “agent context” for risk and dispute handling.
Everyone keeps a signed receipt trail for audits, chargebacks, and “who authorized what.”

Practical Considerations

UCP/AP2 point at the right shape of a solution: verifiable intent, bounded authority, and shared vocabulary between agents, merchants, and payment networks. But a few details matter in practice:

Truthful UI is not the same as signed intent. Even if the mandate objects are cryptographically intact, an agent can still describe them incorrectly (“it’s $12” when the cart is $120). The protocol can prove what was authorized, but it can’t guarantee what the user is told.
Auditability doesn’t assign accountability. Signed receipts are great for disputes and forensics. They don’t automatically prevent bad outcomes, and remediation is still policy, customer support, and risk ops.
It’s a standard interface, not a turnkey implementation. Today it reads more like “here’s how the pieces should talk” than “here’s the reference implementation you can ship.” That’s fine as a protocol, but it’s something implementers should plan around.
It's not payments, it’s ‘delegation.’ This is less about moving money and more about safely delegating authority: constraints, revocation, presence (human vs agent), and liability boundaries. Payments are just where those delegations become expressed in monetary terms.

None of these are a red flag. It’s just what becomes real once you try to make “agent magic” something a merchant, a bank, and a support inbox can live with.

Conclusion

The agent economy won’t be won by smarter agents but instead by better constraints. UCP/AP2 are compelling because they treat agent commerce like an infrastructure problem.

Next, I want to take UCP for a test drive and validate the details that matter in production: who issues mandates, how revocation and expiry work, what merchants are expected to verify server-side, and what data needs to be retained for refunds, chargebacks, and support.