What is the Universal Commerce Protocol
January 13, 2026
What is the Universal Commerce Protocol (UCP)?
UCP is an open-source standard that gives AI agents, apps, merchants, and payment providers a common language for commerce. Instead of building custom integrations for every store, an agent can discover a merchant, understand what they offer, and complete an entire shopping flow, from checkout to order updates, using one consistent interface.
UCP what the problem does it solves
Today's e-commerce is built for humans. Buttons, layouts, dynamic UIs, all designed for people clicking around. AI agents can reason through problems, but they hit a wall when it comes to actually buying things online. They can't reliably figure out what a merchant supports or complete a purchase without resorting to fragile scraping or store-by-store integrations.
UCP changes this by making commerce machine-readable. With UCP, an agent can:
Discover merchants programmatically by reading a standard profile
Understand capabilities like checkout options, payment methods, shipping rules, and discount systems
Execute full purchase flows from cart to checkout to order tracking through standardized APIs
Skip the integration headache because every merchant speaks the same protocol
Handle edge cases through built-in negotiation and extensions for different markets, cart types, or buyer contexts
UCP turns "figuring out how to shop on this specific website" into "shopping through a universal interface." Agents can buy things reliably.
How does UCP work?
UCP is essentially a capability-negotiated, schema-driven handshake between an agent and a merchant. Instead of scraping websites, the agent and merchant exchange machine-readable profiles, agree on what they both support, and then run checkout and order flows through stable, versioned schemas.
Profiles: where discovery starts
A merchant publishes a JSON profile at /.well-known/ucp. This profile declares the UCP version, service endpoints (REST, MCP, A2A, embedded checkout), supported capabilities, extensions, payment handler config, and signing keys. Agents and Merchants publish their own profiles describing what they can handle.
Negotiation: skipping one-off integrations
When an agent makes a request, it includes its profile URI. The merchant fetches that profile and computes the capability intersection, what both sides support. Extensions only activate when their parent capability is also shared. The merchant then responds using this negotiated set for the session.
Schema resolution: staying flexible without breaking things
UCP separates transport from the data model. The agent fetches base schemas plus any active extension schemas, composes them using allOf, and validates requests and responses against the result. This is how UCP can evolve through extensions without breaking existing integrations.
Checkout: the core loop
The merchant exposes checkout as a structured resource, line items, totals, messages, links, and status. The agent creates and updates the checkout until it's ready to complete. The response always makes clear what the next required action is.
Handoff when needed
If the merchant needs user input (for capability gaps), it returns a continue_url and sets checkout status to requires_escalation. The user picks up in a browser at that URL without losing any state.
Embedded checkout
If the merchant supports Embedded Checkout Protocol, the agent can load the continue_url inside its own interface and maintain a live two-way channel using JSON-RPC 2.0 for events and delegated actions like address or payment selection.
Payments and trust
UCP treats payments as negotiable per transaction through payment handlers. For stronger authorization and auditability, UCP is designed to work with Agent Payments Protocol as a trust layer—enabling verifiable exchange of intents and authorizations.
What are UCP's core capabilities?
UCP defines three main capabilities that let an agent complete a real commerce flow without custom integrations:
Checkout: Start and manage a checkout session. This covers building the cart, calculating totals, collecting buyer details, selecting fulfillment options, and completing or cancelling the purchase.
Orders: Work with orders after purchase. Retrieve order details, track fulfillment and status changes, and receive updates through standardized events or webhooks.
Identity Linking: Connect a buyer's agent or platform identity to the merchant. This enables authenticated experiences like account-based checkout, personalized options, and logged-in commerce actions.
Why was UCP needed?
Websites aren't a reliable interface for AI agents. Modern ecommerce sites rely on visual UI elements, dynamic HTML, personalization, A/B tests, popups, and frequent redesigns. Agents can reason, but navigating a constantly shifting interface is fragile.
Computer use is too fragile for real payments. Computer use agents can automate clicks and form fills, but checkout is exactly where reliability matters most. Fraud checks, CAPTCHAs, 2FA, and policy gates can block automation. And a single wrong action can mean buying the wrong item, wrong quantity, wrong address, or wrong payment method.
Custom integrations don't scale. The reliable alternative is building a custom API integration for each merchant. It works, but it's expensive and slow. Every merchant has different endpoints, data models, discount rules, and fulfillment logic.
Commerce is universal, but not uniform. Payments vary by market and cart. Discounts have stacking rules and edge cases. Fulfillment can mean shipping, pickup, split shipments, delivery windows, subscriptions, and more. This complexity isn't a bug. It's how commerce actually works. UCP was built to model this reality with a flexible standard instead of pretending it doesn't exist.
Why not use computer use
Why not just use computer use for agentic shopping?
Short answer: it works sometimes, but it's not reliable enough to be the default.
Computer use can handle agentic shopping in demos and simple cases. But in practice, it runs into a set of hard problems:
Websites are moving targets. A/B tests, redesigns, random popups, any small UI change can break the flow.
Every user sees a different page. Content shifts based on location, inventory, login state, cookies, device type. The "same" checkout page isn't actually the same across sessions.
Security systems get in the way. CAPTCHAs, 2FA, fraud detection, rate limits, bot detection. These all trigger most often at checkout, exactly when you need things to work.
Payments leave no room for error. One wrong click can place an order to the wrong address or buy the wrong item. Merchants add confirmation steps specifically to catch these mistakes.
It's slow and expensive. Vision models plus step-by-step clicking costs more and takes longer than a single API call.
You can't easily prove what happened. With UI automation, auditing is difficult. APIs give you structured receipts, state transitions, and signatures.
This is why protocols like UCP exist. They turn shopping from "clicking around hoping nothing breaks" into structured, negotiated, auditable transactions. While still allowing human handoff when needed.
Here’s a side-by-side comparison of Computer Use vs UCP (Universal Commerce Protocol) for agentic shopping:
Computer Use vs UCP: Side by Side
Computer Use vs UCP: Side by Side | Computer Use | Universal Commerce Protocol(UCP) |
|---|---|---|
How it works | Agent drives the website like a human—clicking, typing, scrolling | Agent talks to merchants through standardized API endpoints |
Reliability | Brittle. Breaks with UI changes, A/B tests, popups | Stable. Versioned APIs with negotiated capabilities |
Payments & security | Risky. CAPTCHAs, 2FA, fraud checks, misclicks | Safer. Structured checkout with wallet/credential flows |
Speed | Slow. Many steps, page loads, waiting | Fast. A few API calls |
Cost | Higher. Vision models + step-by-step interaction | Lower. Structured requests and responses |
Merchant coverage | High. Works anywhere a website exists | Growing. Depends on merchant adoption |
Auditability | Weak. Screenshots and logs, hard to prove anything | Strong. Explicit states, receipts, structured logs |
Error recovery | Messy. Agent gets stuck or wanders | Clean. Explicit states, predictable retries |
Human in the Loop | Ad-hoc. Agent sends a link or asks user to take over | Built-in. Escalation states and continuation URLs |
When to use what
Use UCP when you need production reliability, speed, auditability, and secure payment handling.
Use Computer Use as a fallback for merchants that don't support UCP yet, or edge cases that genuinely require a human-style UI interaction.
Human in the loop
One reason UCP works in the real world is that it doesn't assume every purchase can be fully autonomous. Commerce has moments where a human needs to step in, either because the merchant requires it or because the agent can't safely complete the flow yet. UCP treats this as a normal part of checkout, not an exception.
Agents run into situations like:
Buyer consent or review steps that must be completed by a person
Extra authentication during payment
Merchant policy or regulatory requirements
Checkout features the agent doesn't support yet
Edge cases in shipping or fulfillment options
How UCP models escalation
UCP treats checkout as a stateful process where the merchant clearly communicates what's happening and what needs to happen next. Key states include:
incomplete: Required information is missing; the agent should try to resolve it
requires_escalation: Buyer action is required; the flow must be handed off
ready_for_complete: Everything is collected; the agent can finalize the purchase
UCP also represents outcomes like completion in progress, completed, or canceled. The key point: checkout is never ambiguous. The merchant response includes structured messages explaining what's missing, what the agent can fix, and what requires the buyer.
What handoff looks like
When buyer input is required, the merchant provides a continue_url. The user follows that link and picks up exactly where the agent left off in the same checkout session. No lost cart, no repeating steps. The transaction continues without starting over.
How UCP Handles Real-World Payment Complexity
One of the most important parts of real commerce is that payments aren't static. Available payment methods can change from one checkout to the next based on the cart, the buyer, and the market. UCP covers this.
Dynamic payments, per transaction
In practice, merchants don't offer the same payment options to everyone. What's available can shift based on:
The buyer's country and currency
Cart total
Product type (digital vs physical, restricted goods, subscriptions)
Risk and fraud rules
Local payment networks and wallet support
So the payment methods an agent sees should be treated as "what's valid for this specific checkout right now" not a permanent list.
Payment Method Negotiation Between Agents and Merchants
UCP doesn't mandate a single payment provider or wallet. Instead, it gives both sides a standard way to express what they support:
The agent declares which credentials or payment options it can use
The merchant declares which payment processors are available for this transaction
The checkout response then reflects the negotiated set of options that actually apply to that cart and buyer.
What UCP means for Payment System Providers(PSPs)
For payment service providers, UCP isn't just another integration standard, it's a shift in how payments get distributed and selected in the agent economy.
The new architecture
In UCP, payments work as a three-way negotiation:
The merchant decides which payment options are allowed for a specific cart and buyer
The agent platform works within that set to find the best option for the buyer
The PSP provides a payment handler specification that both sides can reference
One thing to be clear about: the agent doesn't get to pick whatever payment method it wants. It selects from what the merchant offers. The merchant's "allowed payment options" is the boundary, the agent optimizes within it, not around it.
Integration is no longer your moat
Historically, PSPs won deals partly because they had better plugins or easier API docs. UCP changes this.
Once a PSP publishes a compliant handler spec, it becomes technically compatible with any UCP merchant that supports it. But "technically compatible" isn't "commercially live." Merchants still need a business relationship with the PSP. Contracts, KYB, merchant onboarding.
What shifts: the competitive battleground moves from "ease of integration" to "performance of transaction." Agents will programmatically select the best route for their user. Your handler needs to signal that you're the highest-success, lowest-friction path for that specific cart.
API quality becomes table stakes. Authorization rates, smart routing, and fraud performance become the differentiators.
Dynamic payments as the default
UCP treats it as normal that available payment methods change per transaction - based on buyer country, currency, risk level, cart amount, product type, or merchant routing rules.
This isn't new for PSPs. But it does mean your real-time eligibility and routing logic needs to be cleanly expressible in a handler. The agents will be reading it.
Liability in an agent-driven world
When an agent initiates a transaction and fraud occurs, who holds the liability?
UCP supports human handoff for step-up authentication, 3DS, bank OTP, compliance checks. But liability shift rules don't disappear just because an agent is involved.
PSPs need to be explicit about:
Authentication responsibilities
Tokenization boundaries
What happens when escalation is required
This isn't abstract risk. It's about who pays when something goes wrong.
Build UCP with Upsonic
Upsonic provides an agent framework designed for fintech and banking. We've built UCP integration into the platform, so your agents can discover merchants, negotiate capabilities, and execute checkout flows without stitching together one-off integrations.
If you're building agents that need to transact, we'd like to help. Check out our documentation, explore the UCP integration, or get in touch to talk about your use case.
The protocol is open. The tooling is ready. Start building.
FAQs
What is the Universal Commerce Protocol (UCP)?
UCP is an open protocol that standardizes how AI agents, platforms, and merchants discover each other and complete commerce flows using a shared, machine readable interface. It enables consistent shopping experiences without building custom integrations for every merchant.
What problem does UCP solve for agentic commerce?
UCP solves the reliability and scalability problem of agent shopping. It replaces brittle website automation and one off merchant integrations with a standardized discovery, negotiation, and checkout flow that works across UCP compatible merchants.
How does UCP work in simple terms?
A merchant publishes a machine readable profile that lists supported commerce capabilities and endpoints. An agent shares its own profile. The merchant and agent negotiate what both support, then the agent runs a structured checkout and order flow. If a human step is required, UCP provides a continuation handoff path.
What are UCP core capabilities?
UCP core capabilities are the main standardized functions merchants expose for agents. The core set includes Checkout, Orders, and Identity Linking. These cover purchasing, post purchase order management, and authenticated account linking.
What is a UCP merchant profile and why is it important?
A UCP merchant profile is a public document that declares the merchant’s identity, supported capabilities, extensions, and service endpoints. It is the discovery layer that lets agents know how to transact with the merchant in a reliable way.
How does negotiation work in UCP?
Negotiation means the merchant and agent determine the shared set of capabilities, extensions, and payment handlers they both understand for a specific transaction. The merchant then responds using only the negotiated features, which prevents unsupported flows and improves completion rates.
How does UCP handle human in the loop and escalation?
If a checkout requires buyer input or review, the merchant signals escalation and provides a continuation link that preserves the checkout state. The buyer completes the required step, then the flow can continue without restarting or losing context.
How does UCP support flexible payments?
UCP does not force a single payment method. Payment options can change per cart, buyer, and market. The merchant can return the valid payment handlers for that specific checkout, and the agent selects from those options based on buyer preference and available credentials.
What are UCP extensions and why do they matter?
Extensions let UCP model real world commerce complexity without bloating the core protocol. Merchants or vendors can add domain specific schemas such as fulfillment, discounts, or loyalty, and agents only use extensions they understand. This allows the ecosystem to evolve without breaking compatibility.
When should I use UCP instead of computer use shopping?
Use UCP when you need production reliability, speed, auditability, and safer payment flows. Use computer use shopping as a fallback for merchants that do not support UCP yet, or for edge cases that require interacting with a human only interface.