Universal Commerce Protocol: The Open Standard Breaking Down E-Commerce Silos

The Universal Commerce Protocol (UCP) is an open-source specification that addresses one of the most persistent problems in digital commerce: fragmentation. Backed by co-developers including Shopify, Google, Etsy, Target, Walmart, and Wayfair, and endorsed by payment giants like Visa, Mastercard, Stripe, Adyen, and PayPal, UCP provides a standardized common language and functional primitives that enable platforms, businesses, Payment Service Providers (PSPs), and Credential Providers (CPs) to communicate effectively without building custom one-off integrations.

As commerce becomes increasingly agentic – with AI agents acting on behalf of users to discover products, fill carts, and complete purchases – the need for a universal protocol has never been more critical. UCP is designed from the ground up to support this new paradigm while maintaining backward compatibility with traditional commerce flows.

Understanding the Four Primary Actors

The architecture diagram above illustrates the four primary actors in the UCP ecosystem and how they interact. Let’s break down each participant:

Platform (Application/Agent) The platform is the consumer-facing surface – an AI shopping assistant, a super app, or a search engine – acting on behalf of the user. Platforms are responsible for discovering business capabilities via profiles, initiating checkout sessions, and presenting the user interface. In the agentic commerce model, the platform is the AI agent that autonomously finds products and completes transactions.

Business (Merchant of Record) The business is the entity selling goods or services. In UCP, businesses retain financial liability and ownership of the order as the Merchant of Record. They expose commerce capabilities like inventory, pricing, and tax calculation through standardized profiles, and they process payments through their chosen PSP.

Credential Provider (CP) A trusted entity responsible for securely managing and sharing sensitive user data, particularly payment instruments and shipping addresses. Credential Providers like Google Wallet and Apple Pay authenticate users, issue payment tokens to keep raw card data off the platform, and hold PII securely to minimize compliance scope for other parties.

Payment Service Provider (PSP) The financial infrastructure provider that processes payments on behalf of businesses. PSPs like Stripe, Adyen, and PayPal authorize and capture transactions, handle settlements, and communicate with card networks. They often interact directly with tokens provided by the Credential Provider.

Why UCP Matters: The N-to-N Problem

In today’s commerce landscape, every platform that wants to integrate with every business must build a custom integration. If there are N platforms and M businesses, that is potentially N x M custom integrations. UCP solves this by providing a single, standardized protocol that all parties implement once, reducing the integration surface from N x M to N + M.

Core Concepts: Capabilities, Extensions, and Services

UCP revolves around three fundamental constructs that define how entities interact:

Understanding the Capability Model

The diagram above shows how UCP organizes its protocol into three distinct layers, each serving a specific purpose in the commerce stack.

Capabilities: The Verbs of the Protocol

Capabilities are standalone core features that a business supports. They represent the fundamental actions in the commerce lifecycle:

• Checkout (dev.ucp.shopping.checkout) – Facilitates checkout sessions including cart management and tax calculation, supporting flows with or without human intervention
• Identity Linking (dev.ucp.common.identity_linking) – Enables platforms to obtain authorization to perform actions on a user’s behalf via OAuth 2.0
• Order (dev.ucp.shopping.order) – Webhook-based updates for order lifecycle events (shipped, delivered, returned)
• Cart (dev.ucp.shopping.cart) – Enables basket building before purchase intent is established
• Payment Token Exchange – Protocols for PSPs and Credential Providers to securely exchange payment tokens and credentials

Extensions: Modular Enhancements

Extensions are optional capabilities that augment another capability via the extends field. This composable design keeps core capabilities lean while allowing rich functionality:

• Discount extends Checkout – Adds discount and promotion logic
• Fulfillment extends Checkout – Adds shipping and delivery options
• AP2 Mandates extends Checkout – Adds cryptographic proof of user authorization for autonomous commerce

Extensions can even extend multiple parent capabilities. For example, a Discount extension could augment both Checkout and Cart capabilities simultaneously.

Services: The Transport Layer

UCP is transport-agnostic by design. Services define the API surface for a vertical (shopping, common, etc.) and specify bindings for multiple transports:

• REST API – OpenAPI 3.x (JSON format), the primary transport
• MCP – Model Context Protocol (JSON-RPC), enabling AI agent integration
• A2A – Agent-to-Agent Protocol (Agent Card Specification)
• Embedded Protocol – OpenRPC for host-embedded contexts

This transport-agnostic approach means businesses can offer capabilities via REST APIs for traditional integrations, MCP for AI agent interactions, or A2A for agent-to-agent communication, all from the same protocol definition.

Namespace Governance: No Central Registry Needed

UCP uses reverse-domain naming to encode governance authority directly into capability identifiers, eliminating the need for a central registry:

{reverse-domain}.{service}.{capability}

Examples:

Name	Authority	Service	Capability
dev.ucp.shopping.checkout	ucp.dev	shopping	checkout
dev.ucp.shopping.fulfillment	ucp.dev	shopping	fulfillment
dev.ucp.common.identity_linking	ucp.dev	common	identity_linking
com.example.payments.installments	example.com	payments	installments

The dev.ucp.* namespace is reserved for capabilities sanctioned by the UCP governing body. Vendors use their own reverse-domain namespace for custom capabilities, ensuring extensibility without conflicts.

Discovery and Negotiation: How Parties Find Each Other

The discovery and negotiation process is the foundation of UCP’s permissionless onboarding model. Businesses publish their profile at /.well-known/ucp, and platforms discover capabilities dynamically.

Understanding the Commerce Flow

The diagram above illustrates the four-phase lifecycle from discovery to transaction completion. Here is a detailed breakdown of each phase:

Phase 1: Discovery

Platforms fetch the business’s UCP profile from /.well-known/ucp. This profile contains everything the platform needs to know: protocol version, supported services, available capabilities, payment handlers, and signing keys. The profile is a single JSON document that serves dual purpose – declaring capabilities for negotiation and publishing signing keys for identity verification.

Phase 2: Negotiation

The capability intersection algorithm determines which capabilities are active for a session:

1. Compute intersection – For each business capability, include it if a platform capability with the same name exists
2. Select version – For each capability in the intersection, compute the set of version strings present in both parties. If non-empty, select the highest version. If empty, exclude the capability
3. Prune orphaned extensions – Remove any extension where none of its parent capabilities are in the intersection
4. Repeat pruning – Continue until no more capabilities are removed (handles transitive extension chains)

This server-selects architecture means the business determines the active capabilities from the intersection of both parties’ declared capabilities, ensuring the business retains control.

Phase 3: Checkout

The platform initiates a checkout session by sending a request with its profile URI in the UCP-Agent header. The business processes the request, computes the capability intersection, and returns a response that includes:

• Active capabilities for this session
• Available payment handlers with configuration
• Line items, totals, and checkout details

Phase 4: Payment

UCP adopts a decoupled payment architecture that solves the N-to-N complexity problem between platforms, businesses, and payment credential providers. The payment process follows a three-step lifecycle:

1. Negotiation – The business advertises available payment handlers in their UCP profile
2. Acquisition – The platform executes the handler’s logic directly with the credential provider (the business is not involved, ensuring raw data never touches the platform’s API)
3. Completion – The platform submits the opaque credential (token) to the business, which uses it to capture funds via their backend integration

Payment Architecture: Security by Design

The payment architecture is built on a “Trust-by-Design” philosophy with three key security principles:

Unidirectional Credential Flow – Credentials flow from Platform to Business only. Businesses never echo credentials back in responses.

Opaque Credentials – Platforms handle tokens (network tokens, encrypted payloads, or mandates), not raw PANs. This minimizes PCI-DSS compliance scope for platforms and businesses.

Handler ID Routing – The handler_id in the payload ensures the business knows exactly which payment credential provider key to use for decryption or charging, preventing key confusion attacks.

Payment Handler Pattern

Payment Handlers are specifications (not entities) that define how payment instruments are processed. The pattern involves three distinct responsibilities:

Role	Responsibility	Example
Credential Provider	Defines the Spec	“Here is the schema for the tokenization handler”
Business	Configures the Handler	“I accept Visa using this handler with this public key”
Platform	Executes the Protocol	“I see the handler config and will acquire a token”

This separation of concerns means a Credential Provider like Google Pay defines the handler specification, a business configures it with their specific merchant ID and keys, and the platform executes the protocol to acquire a token.

AP2 Mandates for Autonomous Commerce

For scenarios requiring cryptographic proof of user authorization – such as autonomous AI agents making purchases – UCP supports the AP2 Mandates Extension. This optional extension provides non-repudiable authorization through verifiable digital credentials, enabling safe autonomous processing where the agent can cryptographically prove the user authorized the specific transaction.

Transport Layer: REST, MCP, A2A, and Embedded

UCP supports multiple transport protocols, with platforms and businesses negotiating the transport via services on their profiles:

REST Transport (Core) Uses standard HTTP/1.1 or higher with JSON content type. Platforms include their profile URI in the UCP-Agent header using Dictionary Structured Field syntax per RFC 8941.

MCP Transport Uses JSON-RPC with the tools/call method. UCP capabilities map 1:1 to MCP tools, enabling seamless AI agent integration. The platform profile is included in the meta object of the request.

A2A Transport Uses the Agent Card Specification for agent-to-agent communication, allowing businesses to expose UCP as an A2A Extension.

Embedded Protocol Uses OpenRPC for host-embedded contexts, where a business embeds an interface onto an eligible host that receives events as the user interacts.

Profile Structure: The Single Source of Truth

Both businesses and platforms publish UCP profiles that serve as the single source of truth for discovery, negotiation, and identity verification. A business profile published at /.well-known/ucp contains:

{
  "ucp": {
    "version": "2026-01-23",
    "services": {
      "dev.ucp.shopping": [
        {
          "version": "2026-01-23",
          "transport": "rest",
          "endpoint": "https://business.example.com/api/v2",
          "schema": "https://ucp.dev/2026-01-23/services/shopping/rest.openapi.json"
        }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": [
        {
          "version": "2026-01-23",
          "spec": "https://ucp.dev/2026-01-23/specification/checkout",
          "schema": "https://ucp.dev/2026-01-23/schemas/shopping/checkout.json"
        }
      ],
      "dev.ucp.shopping.fulfillment": [
        {
          "version": "2026-01-23",
          "spec": "https://ucp.dev/2026-01-23/specification/fulfillment",
          "schema": "https://ucp.dev/2026-01-23/schemas/shopping/fulfillment.json",
          "extends": "dev.ucp.shopping.checkout"
        }
      ]
    },
    "payment_handlers": {
      "com.example.processor_tokenizer": [
        {
          "id": "processor_tokenizer",
          "version": "2026-01-23",
          "available_instruments": [
            {"type": "card", "constraints": {"brands": ["visa", "mastercard", "amex"]}}
          ],
          "config": {
            "type": "CARD",
            "tokenization_specification": {
              "type": "PUSH",
              "parameters": {
                "token_retrieval_url": "https://api.psp.example.com/v1/tokens"
              }
            }
          }
        }
      ]
    }
  },
  "signing_keys": [
    {
      "kid": "business_2025",
      "kty": "EC",
      "crv": "P-256",
      "x": "WbbXwVYGdJoP4Xm3qCkGvBRcRvKtEfXDbWvPzpPS8LA",
      "y": "sP4jHHxYqC89HBo8TjrtVOAGHfJDflYxw7MFMxuFMPY",
      "use": "sig",
      "alg": "ES256"
    }
  ]
}

The profile simultaneously declares capabilities for negotiation and publishes signing keys for identity verification – enabling both capability negotiation and cryptographic authentication from a single document.

Versioning: Date-Based and Independent

UCP uses date-based versioning in the format YYYY-MM-DD, providing clear chronological ordering and unambiguous version comparison. The protocol separates version compatibility from capability negotiation:

• Protocol version governs core mechanisms – discovery, negotiation flow, transport bindings, and signature requirements
• Capability versions are negotiated independently, with each capability versioning separately from other capabilities

Businesses that support older protocol versions declare them in a supported_versions object mapping each version to a profile URI, enabling platforms to discover exact capabilities for a specific protocol version.

The UCP Ecosystem

Understanding the Ecosystem

The ecosystem diagram above shows the breadth of UCP’s adoption and its expanding scope. The protocol has been co-developed by major commerce platforms including Shopify, Google, Etsy, Target, Walmart, and Wayfair – companies that collectively process billions of transactions. On the endorsement side, payment infrastructure providers like Visa, Mastercard, PayPal, Stripe, Adyen, Klarna, Block, and Fiserv have backed the standard, ensuring it works with the payment rails that power global commerce.

The roadmap extends beyond shopping into new verticals (Travel, Services), loyalty programs, personalization signals, and global market support including India, Indonesia, and Latin America.

Getting Started with UCP

To start implementing UCP:

1. Explore the Documentation – Visit ucp.dev for the complete specification, tutorials, and guides
2. Review the Samples – Check the UCP samples repository for implementation examples
3. Use the SDKs – Build integrations using the UCP SDKs
4. Check Conformance – Validate your implementation with the conformance tests
5. Join the Discussion – Participate in GitHub Discussions to shape the future of the protocol

Security Considerations

UCP incorporates multiple security layers:

• HTTPS Required – All UCP communication must occur over HTTPS
• HTTP Message Signatures – Per RFC 9421, enabling permissionless onboarding where businesses can verify platforms by their advertised public keys
• OAuth 2.0 and mTLS – Supported as alternative authentication mechanisms
• PCI-DSS Scope Management – The decoupled payment architecture minimizes compliance scope for platforms and businesses
• Fraud Prevention – Signals (IP, user agent) and AP2 mandates provide transaction integrity and non-repudiation

Conclusion

The Universal Commerce Protocol represents a fundamental shift in how digital commerce operates. By providing a standardized, transport-agnostic protocol with built-in support for agentic commerce, UCP eliminates the N-to-N integration problem and enables any platform to interact with any business without prior registration or custom integrations.

The protocol’s composable architecture – with capabilities, extensions, and services – ensures it can grow with the ecosystem while maintaining backward compatibility. The payment architecture’s decoupled design keeps sensitive data out of the hands of intermediaries while enabling seamless transactions. And the namespace governance model ensures extensibility without a central registry.

Whether you are building an AI shopping agent, running an e-commerce platform, or processing payments, UCP provides the building blocks for the next generation of commerce interoperability. The specification is open source under the Apache License 2.0, and the community welcomes contributions.

Links

• UCP Official Documentation
• UCP GitHub Repository
• UCP Specification
• UCP Samples
• UCP Conformance Tests
• UCP GitHub Discussions

Enjoyed this post? Never miss out on future posts by following us