Commerce 3.0 - How Agentic Commerce Will Transform the Digital Economy

Digital commerce stands on the eve of its third paradigm shift since the mobile internet revolution. If the first generation of e-commerce was "people finding products" (search), and the second generation was "products finding people" (recommendation feeds), then the emerging third generation—Agentic Commerce—represents "machines finding products, machines negotiating, machines transacting." In this new paradigm, artificial intelligence is no longer merely a decision-support tool; it becomes an autonomous economic actor with independent execution capabilities. However, the current landscape of fragmented e-commerce APIs, closed ecosystem walls, and the absence of a unified machine-readable language creates an "N × N" integration bottleneck that blocks large-scale AI agent deployment.

Google released UCP/AP2 in January 2026, following closely after OpenAI and Stripe's announcement of ACP (Agentic Commerce Protocol) in September 2025. This timing reflects not just a product competition, but a fundamental clash of business philosophies.

What is UCP (Universal Commerce Protocol)?

Core Architecture: Extensions, Capabilities, and Services

UCP is built on a layered architecture that provides flexibility while maintaining interoperability. Understanding these three foundational concepts is essential for working with the protocol.

• Extensions: Optional modules that augment another capability via the extends field. Extensions appear in ucp.capabilities[] alongside core capabilities, allowing businesses to add functionality incrementally.
  • Examples: Discounts (extends Checkout), AP2 Mandates (extends Checkout).
• Capabilities: Standalone core features that a business supports. Think of these as the "verbs" of the protocol—the actions a business can perform.
• Services: The lower-level communication layers used to exchange data. UCP is transport-agnostic but defines specific bindings for interoperability across different communication paradigms.
  • Examples: REST API (primary), MCP (Model Context Protocol), A2A (Agent2Agent).

Services: The Communication Layer

A service defines the API surface for a vertical domain (shopping, common, etc.). Services include operations, events, and transport bindings defined via standard formats. This transport-agnostic design means the same commerce logic can be exposed through multiple channels:

• REST: OpenAPI 3.x (JSON format) — The primary interface for traditional HTTP-based integrations
• MCP: OpenRPC (JSON format) — For AI model context integration
• A2A: Agent Card Specification — For autonomous agent-to-agent communication
• EP (embedded): OpenRPC (JSON format) — For embedded contexts

"services": {
  "dev.ucp.shopping": {
	"version": "2026-01-11",
	"spec": "https://ucp.dev/specification/overview",
	"rest": {
	  "schema": "https://ucp.dev/services/shopping/rest.openapi.json",
	  "endpoint": "https://business.example.com/ucp/v1"
	},
	"mcp": {
	  "schema": "https://ucp.dev/services/shopping/mcp.openrpc.json",
	  "endpoint": "https://business.example.com/ucp/mcp"
	},
	"a2a": {
	  "endpoint": "https://business.example.com/.well-known/agent-card.json"
	},
	"embedded": {
	  "schema": "https://ucp.dev/services/shopping/embedded.openrpc.json"
	}
  }
}

Capabilities: What a Business Can Do

• A Capability is a feature within a service. It declares what functionality is supported and where to find documentation and schemas.
• UCP uses reverse-domain naming to encode governance authority directly into capability identifiers.
  • This eliminates the need for a central registry—anyone can define capabilities under their domain.
  • Platforms must verify the origin of spec URLs to match the namespace authority, ensuring authenticity.
• Naming convention: {reverse-domain}.{service}.{capability}, e.g., dev.ucp.shopping.checkout

The two core capabilities that every UCP-compliant business should support are checkout and order:

• Checkout: Allows platforms to facilitate checkout sessions. The checkout must be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported (for autonomous agent transactions). Critically, the business remains the Merchant of Record (MoR), and they don't need to become PCI DSS compliant to support this capability—the protocol handles sensitive data securely.
• Orders: Represent confirmed transactions resulting from a successful checkout submission. This provides a complete record of what was purchased, how it will be delivered, and what has happened since order placement.

{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ]
  }
}

Extensions: Modular Feature Additions

An extension is an optional module that augments another capability. Extensions use the extends field to declare their parent capability, creating a composable system where businesses can adopt features incrementally.

Extensions can be either official or vendor-defined:

• Official: dev.ucp.shopping.fulfillment extends dev.ucp.shopping.checkout
• Vendor: com.example.installments extends dev.ucp.shopping.checkout

In the example below, fulfillment, discount, buyer_consent, and ap2_mandates are all extensions of the checkout capability.

Let's examine ap2_mandates as a concrete example. For scenarios requiring cryptographic proof of user authorization (e.g., autonomous AI agents making purchases on behalf of users), UCP supports the AP2 Mandates Extension (dev.ucp.shopping.ap2_mandate). This optional extension provides non-repudiable authorization through verifiable digital credentials, enabling truly autonomous commerce.

{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      },
      {
        "name": "dev.ucp.shopping.fulfillment",
        "extends": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/fulfillment",
        "schema": "https://ucp.dev/schemas/shopping/fulfillment.json"
      },
      {
        "name": "dev.ucp.shopping.discount",
        "extends": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/discount",
        "schema": "https://ucp.dev/schemas/shopping/discount.json"
      },
      {
        "name": "dev.ucp.shopping.buyer_consent",
        "extends": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/buyer_consent",
        "schema": "https://ucp.dev/schemas/shopping/buyer_consent.json"
      },
      {
        "name": "dev.ucp.shopping.ap2_mandates",
        "extends": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/ap2_mandates",
        "schema": "https://ucp.dev/schemas/shopping/ap2_mandates.json"
      }
    ]
  }
}

Roles and Responsibilities in the UCP Ecosystem

UCP defines clear roles with distinct responsibilities, ensuring that each participant knows exactly what they need to implement and what they can rely on others to provide.

Platform (Application/Agent): The User's Representative

The platform is the consumer-facing surface (such as an AI agent, mobile app, or social media site) acting on behalf of the User. It orchestrates the commerce journey by discovering businesses and facilitating user intent.

• Responsibilities: Discovering business capabilities via profiles, initiating checkout sessions, and presenting the UI or conversational interface to the user.
• Examples: AI Shopping Assistants, Super Apps, Search Engines.

Platform profiles include signing keys for capabilities requiring cryptographic verification. Capabilities MAY include a config object for capability-specific settings (e.g., callback URLs, feature flags).

{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.fulfillment",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/fulfillment",
        "schema": "https://ucp.dev/schemas/shopping/fulfillment.json",
        "extends": "dev.ucp.shopping.checkout"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json",
        "config": {
          "webhook_url": "https://platform.example.com/webhooks/ucp/orders"
        }
      }
    ]
  },
  "payment": {
    "handlers": [
      {
        "id": "gpay",
        "name": "com.google.pay",
        "version": "2024-12-03",
        "spec": "https://developers.google.com/merchant/ucp/guides/gpay-payment-handler",
        "config_schema": "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/gpay_config.json",
        "instrument_schemas": [
          "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/gpay_card_payment_instrument.json"
        ]
      },
      {
        "id": "business_tokenizer",
        "name": "dev.ucp.business_tokenizer",
        "version": "2026-01-11",
        "spec": "https://example.com/specs/payments/business_tokenizer-payment",
        "config_schema": "https://ucp.dev/schemas/payments/delegate-payment.json",
        "instrument_schemas": [
          "https://ucp.dev/schemas/shopping/types/card_payment_instrument.json"
        ]
      }
    ]
  },
  "signing_keys": [
    {
      "kid": "platform_2025",
      "kty": "EC",
      "crv": "P-256",
      "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
      "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
      "use": "sig",
      "alg": "ES256"
    }
  ]
}

Business: The Merchant of Record

The entity selling goods or services. In the UCP model, businesses act as the Merchant of Record (MoR), retaining financial liability and ownership of the order. This is a crucial distinction from marketplace models where the platform takes on MoR status.

• Responsibilities: Exposing commerce capabilities (inventory, pricing, tax calculation), fulfilling orders, and processing payments via their chosen PSP.
• Examples: Retailers, Airlines, Hotel Chains, Service Providers.

Businesses publish their profile at /.well-known/ucp, making their capabilities discoverable to any platform or agent that knows their domain.

{
  "ucp": {
    "version": "2026-01-11",
    "services": {
      "dev.ucp.shopping": {
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/overview",
        "rest": {
          "schema": "https://ucp.dev/services/shopping/rest.openapi.json",
          "endpoint": "https://business.example.com/ucp/v1"
        },
        "mcp": {
          "schema": "https://ucp.dev/services/shopping/mcp.openrpc.json",
          "endpoint": "https://business.example.com/ucp/mcp"
        },
        "a2a": {
          "endpoint": "https://business.example.com/.well-known/agent-card.json"
        },
        "embedded": {
          "schema": "https://ucp.dev/services/shopping/embedded.openrpc.json"
        }
      }
    },
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.fulfillment",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/fulfillment",
        "schema": "https://ucp.dev/schemas/shopping/fulfillment.json",
        "extends": "dev.ucp.shopping.checkout"
      },
      {
        "name": "dev.ucp.shopping.discount",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/discount",
        "schema": "https://ucp.dev/schemas/shopping/discount.json",
        "extends": "dev.ucp.shopping.checkout"
      }
    ]
  },
  "payment": {
    "handlers": [
      {
        "id": "business_tokenizer",
        "name": "com.example.business_tokenizer",
        "version": "2026-01-11",
        "spec": "https://example.com/specs/payments/business_tokenizer",
        "config_schema": "https://example.com/specs/payments/merchant_tokenizer.json",
        "instrument_schemas": [
          "https://ucp.dev/schemas/shopping/types/card_payment_instrument.json"
        ],
        "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"
    }
  ]
}

Credential Provider (CP): The Trust Anchor for Payments

UCP adopts a decoupled architecture for payments to solve the "N-to-N" complexity problem between platforms, businesses, and payment credential providers. This design separates Payment Instruments (what is accepted) from Payment Handlers (the specifications for how instruments are processed), ensuring security and scalability. The architecture assumes that while the business and payment credential provider have a trusted legal relationship, the platform (Client) acts as an intermediary that SHOULD NOT handle raw financial credentials.

A crucial distinction: Payment Handlers are specifications (not entities) that define how payment instruments are processed. They serve as the contract that binds the three participants together.

The Credential Provider is the trusted entity responsible for securely managing and sharing sensitive user data, particularly payment instruments and shipping addresses. Its responsibilities include authenticating the user, issuing payment tokens (to keep raw card data off the platform), and holding PII securely to minimize compliance scope for other parties.

The three key relationships in UCP payments:

1. Business ↔ Payment Credential Provider: A pre-existing legal and technical relationship. The business holds API keys and a contract with the payment credential provider.
2. Platform ↔ Payment Credential Provider: The platform interacts with the payment credential provider's interface (e.g., an iframe or API) to tokenize data but is not the "owner" of the funds.
3. Platform ↔ Business: The platform passes the result (a token or mandate) to the business to finalize the order.

Examples: Digital Wallets (e.g., Google Wallet, Apple Pay), Identity Providers.

Why This Architecture Matters: PCI Compliance and Security

Handling raw credit card numbers (Primary Account Numbers or PANs) makes a system "in-scope" for PCI compliance. This requires expensive audits, secure environments, and carries massive liability in case of a data breach. UCP is designed to "descope" the Platform so it never touches raw data.

The protocol enforces three critical security principles:

1. Unidirectional Flow (One-Way Traffic)

• The Rule: Sensitive credentials (like payment tokens) must move in one direction only: from the Platform to the Business. The Business is strictly forbidden from "echoing" (returning) these credentials back to the Platform in their API responses.
• The Technical Rationale:
  • Logging Hygiene: Most API systems automatically log HTTP requests and responses for debugging.
  • If a Business echoes the payment token back in a success response (HTTP 200), that sensitive token might be written into the Platform's server logs in plain text.
  • By enforcing a strict "fire and forget" mechanism, the token enters the Business environment and never leaves, preventing accidental data leakage into log files or analytics systems.

2. Opaque Credentials (The "Sealed Courier" Model)

• The Rule: The Platform never sees the raw credit card number (PAN). Instead, it only handles "Opaque" data structures—such as Network Tokens (e.g., from Visa/Mastercard) or encrypted blobs (e.g., from Apple Pay/Google Pay).
• The Technical Rationale:
  • Liability Shielding (Descoping): Because the data is "opaque" (meaning the Platform cannot read or decrypt it), the Platform is treated merely as a transporter, not a processor.
  • Analogy: The Platform acts like a courier delivering a locked titanium briefcase. The courier doesn't need to know the combination to the lock; they just need to get it to the destination. Since the Platform can't open the briefcase, hackers breaking into the Platform can't steal the money inside.

3. Handler ID Routing (Cryptographic Certainty)

• The Rule: Every payment payload must carry a handler_id (e.g., "handler_id": "gpay" or "shop_pay"). This tells the Business exactly which "key" to use to unlock the opaque credential.
• The Technical Rationale:
  • Multi-Processor Complexity: A single Business might use Stripe for cards, Adyen for Google Pay, and Affirm for loans. Each of these providers (Credential Providers/PSPs) uses different decryption keys and APIs.
  • Preventing "Key Confusion" Attacks: Without the explicit handler_id, the Business might try to decrypt a Stripe payload using a Google Pay key. This is inefficient (guessing games). More importantly, it prevents sophisticated cryptographic attacks where bad actors send malicious payloads to trick the server into using the wrong key, which can sometimes reveal system secrets via error messages (Oracle Attacks).
  • Determinism: The handler_id acts as a router, ensuring the payload goes immediately to the correct decryption service without ambiguity.

End-to-End Transaction Workflow

This section walks through a complete UCP transaction, from capability discovery to order fulfillment. Understanding this flow is essential for implementing UCP in practice.

Step 1: Platform Defines Its Profile

The platform establishes which capabilities it supports. This determines which extensions (e.g., fulfillment, discounts) will be negotiated with businesses.

{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ]
  }
}

Step 2: Capability Discovery via Well-Known Endpoint

The Platform fetches the business profile from /.well-known/ucp. The response is filtered to show the intersection of the Business's capabilities and the Platform's profile.

Business-Side Requirements:

• Upon receiving a request with a platform profile URI, businesses MUST fetch and validate the platform profile unless already cached.
• Businesses MUST compute the intersection of platform and business capabilities.
• Extensions without their parent capability in the intersection MUST be excluded.
• Businesses MUST include the ucp field in every response containing: version and capabilities.

Platform-Side Requirements:

• Platforms MUST include their profile URI in every request using the transport-appropriate mechanism.
• Platforms MAY fetch the business profile from /.well-known/ucp before initiating requests. If fetched, platforms SHOULD cache the profile according to HTTP cache-control directives.
• Platforms MUST validate that capability spec URI origins match namespace authorities.
• Platforms MUST fetch and compose schemas for negotiated capabilities before making requests.

{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ]
  },
  "payment": {
    "handlers": [
      {
        "id": "shop_pay",
        "name": "com.shopify.shop_pay",
        "version": "2025-12-08",
        "spec": "https://shopify.dev/ucp/shop_pay",
        "config_schema": "https://shopify.dev/ucp/handlers/shop_pay/config.json",
        "instrument_schemas": [
          "https://shopify.dev/ucp/handlers/shop_pay/instrument.json"
        ],
        "config": {
          "shop_id": "shopify-559128571"
        }
      },
      {
        "id": "gpay",
        "name": "com.google.pay",
        "version": "2026-01-11",
        "spec": "https://pay.google.com/gp/p/ucp/2026-01-11/",
        "config_schema": "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/config.json",
        "instrument_schemas": [
          "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/card_payment_instrument.json"
        ],
        "config": {
          "api_version": 2,
          "api_version_minor": 0,
          "environment": "TEST",
          "merchant_info": {
            "merchant_name": "Example Merchant",
            "merchant_id": "01234567890123456789",
            "merchant_origin": "checkout.merchant.com",
            "auth_jwt": "edxsdfoaisjdfapsodjf...."
          },
          "allowed_payment_methods": [
            {
              "type": "CARD",
              "parameters": {
                "allowed_auth_methods": [
                  "PAN_ONLY",
                  "CRYPTOGRAM_3DS"
                ],
                "allowed_card_networks": [
                  "VISA",
                  "MASTERCARD"
                ]
              },
              "tokenization_specification": {
                "type": "PAYMENT_GATEWAY",
                "parameters": {
                  "gateway": "example",
                  "gatewayMerchantId": "exampleGatewayMerchantId"
                }
              }
            }
          ]
        }
      }
    ]
  }
}

Step 3: Capability Negotiation

The protocol computes the intersection of Platform and Business capabilities. Orphaned extensions (those whose parent capability is not in the intersection) are automatically pruned.

The negotiation algorithm:

• For each business capability, include it in the result if a platform capability with the same name exists.
• Prune orphaned extensions: Remove any capability where extends is set but the parent capability is not in the intersection. Continue until no more capabilities are removed (handles transitive extension chains).

## Business Capabilities
[
  {
    "name": "dev.ucp.shopping.checkout",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/checkout",
    "schema": "https://ucp.dev/schemas/shopping/checkout.json"
  },
  {
    "name": "dev.ucp.shopping.order",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/order",
    "schema": "https://ucp.dev/schemas/shopping/order.json"
  },
  {
    "name": "dev.ucp.shopping.fulfillment",
    "extends": "dev.ucp.shopping.checkout",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/fulfillment",
    "schema": "https://ucp.dev/schemas/shopping/fulfillment.json"
  },
  {
    "name": "dev.ucp.shopping.discount",
    "extends": "dev.ucp.shopping.checkout",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/discount",
    "schema": "https://ucp.dev/schemas/shopping/discount.json"
  },
  {
    "name": "dev.ucp.shopping.buyer_consent",
    "extends": "dev.ucp.shopping.checkout",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/buyer_consent",
    "schema": "https://ucp.dev/schemas/shopping/buyer_consent.json"
  },
  {
    "name": "dev.ucp.shopping.ap2_mandates",
    "extends": "dev.ucp.shopping.checkout",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/ap2_mandates",
    "schema": "https://ucp.dev/schemas/shopping/ap2_mandates.json"
  }
]

## Resulting Intersection
[
  {
    "name": "dev.ucp.shopping.checkout",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/checkout",
    "schema": "https://ucp.dev/schemas/shopping/checkout.json"
  },
  {
    "name": "dev.ucp.shopping.order",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specs/order",
    "schema": "https://ucp.dev/schemas/shopping/order.json"
  }
]

Step 4: Create Checkout Session

The Platform initiates a checkout session by submitting the shopping cart and payment instrument information.

## Request Payload
{
  "line_items": [
    {
      "item": {
        "id": "sku_stickers"
      },
      "quantity": 2
    },
    {
      "item": {
        "id": "sku_mug"
      },
      "quantity": 1
    }
  ],
  "buyer": {},
  "payment": {
    "instruments": [
      {
        "handler_id": "shop_pay",
        "type": "shop_pay",
        "email": "buyer@example.com",
        "id": "instr_sp_1338ef2c-3913-4267-83a2-a84d07d9a6a6"
      }
    ]
  }
}

## Response
{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ]
  },
  "id": "chk_77d201eb",
  "status": "incomplete",
  "line_items": [
    {
      "id": "li_1",
      "item": {
        "id": "sku_stickers",
        "title": "UCP Demo Sticker Pack",
        "price": 599,
        "image_url": "https://example.com/images/stickers.jpg"
      },
      "quantity": 2,
      "totals": [
        {
          "type": "subtotal",
          "amount": 1198
        },
        {
          "type": "total",
          "amount": 1198
        }
      ]
    },
    {
      "id": "li_2",
      "item": {
        "id": "sku_mug",
        "title": "UCP Demo Mug",
        "price": 1999,
        "image_url": "https://example.com/images/mug.jpg"
      },
      "quantity": 1,
      "totals": [
        {
          "type": "subtotal",
          "amount": 1999
        },
        {
          "type": "total",
          "amount": 1999
        }
      ]
    }
  ],
  "currency": "USD",
  "totals": [
    {
      "type": "subtotal",
      "amount": 3197
    },
    {
      "type": "total",
      "amount": 3197
    }
  ],
  "messages": [
    {
      "type": "error",
      "code": "missing",
      "path": "$.buyer.email",
      "severity": "requires_buyer_input",
      "content": "Buyer email is required for checkout."
    }
  ],
  "payment": {
    "handlers": [
      {
        "id": "shop_pay",
        "name": "com.shopify.shop_pay",
        "version": "2025-12-08",
        "spec": "https://shopify.dev/ucp/shop_pay",
        "config_schema": "https://shopify.dev/ucp/handlers/shop_pay/config.json",
        "instrument_schemas": [
          "https://shopify.dev/ucp/handlers/shop_pay/instrument.json"
        ],
        "config": {
          "shop_id": "shopify-559128571"
        }
      },
      {
        "id": "gpay",
        "name": "com.google.pay",
        "version": "2026-01-11",
        "spec": "https://pay.google.com/gp/p/ucp/2026-01-11/",
        "config_schema": "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/config.json",
        "instrument_schemas": [
          "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/card_payment_instrument.json"
        ],
        "config": {
          "api_version": 2,
          "api_version_minor": 0,
          "environment": "TEST",
          "merchant_info": {
            "merchant_name": "Example Merchant",
            "merchant_id": "01234567890123456789",
            "merchant_origin": "checkout.merchant.com",
            "auth_jwt": "edxsdfoaisjdfapsodjf...."
          },
          "allowed_payment_methods": [
            {
              "type": "CARD",
              "parameters": {
                "allowed_auth_methods": [
                  "PAN_ONLY",
                  "CRYPTOGRAM_3DS"
                ],
                "allowed_card_networks": [
                  "VISA",
                  "MASTERCARD"
                ]
              },
              "tokenization_specification": {
                "type": "PAYMENT_GATEWAY",
                "parameters": {
                  "gateway": "example",
                  "gatewayMerchantId": "exampleGatewayMerchantId"
                }
              }
            }
          ]
        }
      }
    ]
  }
}

Step 5: Update Checkout to Resolve Validation Errors

The Platform patches the checkout with missing information to resolve validation errors identified in the previous response.

## PATCH Request
{
  "id": "chk_77d201eb",
  "buyer": {
    "email": "fixed_user@example.com",
    "name": "Fixed User"
  }
}
## Response
{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ]
  },
  "id": "chk_77d201eb",
  "status": "ready_for_complete",
  "line_items": [
    {
      "id": "li_1",
      "item": {
        "id": "sku_stickers",
        "title": "UCP Demo Sticker Pack",
        "price": 599,
        "image_url": "https://example.com/images/stickers.jpg"
      },
      "quantity": 2,
      "totals": [
        {
          "type": "subtotal",
          "amount": 1198
        },
        {
          "type": "total",
          "amount": 1198
        }
      ]
    },
    {
      "id": "li_2",
      "item": {
        "id": "sku_mug",
        "title": "UCP Demo Mug",
        "price": 1999,
        "image_url": "https://example.com/images/mug.jpg"
      },
      "quantity": 1,
      "totals": [
        {
          "type": "subtotal",
          "amount": 1999
        },
        {
          "type": "total",
          "amount": 1999
        }
      ]
    }
  ],
  "currency": "USD",
  "totals": [
    {
      "type": "subtotal",
      "amount": 3197
    },
    {
      "type": "total",
      "amount": 3197
    }
  ],
  "messages": [],
  "payment": {
    "handlers": [
      {
        "id": "shop_pay",
        "name": "com.shopify.shop_pay",
        "version": "2025-12-08",
        "spec": "https://shopify.dev/ucp/shop_pay",
        "config_schema": "https://shopify.dev/ucp/handlers/shop_pay/config.json",
        "instrument_schemas": [
          "https://shopify.dev/ucp/handlers/shop_pay/instrument.json"
        ],
        "config": {
          "shop_id": "shopify-559128571"
        }
      },
      {
        "id": "gpay",
        "name": "com.google.pay",
        "version": "2026-01-11",
        "spec": "https://pay.google.com/gp/p/ucp/2026-01-11/",
        "config_schema": "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/config.json",
        "instrument_schemas": [
          "https://pay.google.com/gp/p/ucp/2026-01-11/schemas/card_payment_instrument.json"
        ],
        "config": {
          "api_version": 2,
          "api_version_minor": 0,
          "environment": "TEST",
          "merchant_info": {
            "merchant_name": "Example Merchant",
            "merchant_id": "01234567890123456789",
            "merchant_origin": "checkout.merchant.com",
            "auth_jwt": "edxsdfoaisjdfapsodjf...."
          },
          "allowed_payment_methods": [
            {
              "type": "CARD",
              "parameters": {
                "allowed_auth_methods": [
                  "PAN_ONLY",
                  "CRYPTOGRAM_3DS"
                ],
                "allowed_card_networks": [
                  "VISA",
                  "MASTERCARD"
                ]
              },
              "tokenization_specification": {
                "type": "PAYMENT_GATEWAY",
                "parameters": {
                  "gateway": "example",
                  "gatewayMerchantId": "exampleGatewayMerchantId"
                }
              }
            }
          ]
        }
      }
    ]
  },
  "buyer": {
    "email": "fixed_user@example.com",
    "name": "Fixed User"
  }
}

Step 6: Mint Payment Instrument

The Platform executes the payment handler flow to acquire a payment credential (token). This step interacts with the Credential Provider to securely tokenize the user's payment method.

## Shop Pay
{
  "handler_id": "shop_pay",
  "type": "shop_pay",
  "email": "buyer@example.com",
  "id": "instr_sp_1338ef2c-3913-4267-83a2-a84d07d9a6a6",
  "credential": {
    "type": "ShopPayToken",
    "token": "shoppay_tok_1a1f62d4-135e-4895-b732-59a135c96682"
  }
}

## Google Pay

{
  "handler_id": "gpay",
  "type": "card",
  "brand": "visa",
  "last_digits": "4242",
  "billing_address": {
    "street_address": "123 Main Street",
    "extended_address": "Suite 400",
    "address_locality": "Charleston",
    "address_region": "SC",
    "postal_code": "29401",
    "address_country": "US",
    "first_name": "Jane",
    "last_name": "Smith"
  },
  "id": "instr_gp_msg_084a3d56-3491-4b5e-ae3e-b1c45b22fa50",
  "credential": {
    "type": "PAYMENT_GATEWAY",
    "token": "gpaytok_a56f9f4d-6f61-41ed-95a1-f0fa1c4ea65d"
  }
}

Step 7: Complete Checkout and Create Order

Submit the minted payment instrument to finalize the transaction and create an order.

## Request
{
  "payment": {
    "handler_id": "gpay",
    "type": "card",
    "brand": "visa",
    "last_digits": "4242",
    "billing_address": {
      "street_address": "123 Main Street",
      "extended_address": "Suite 400",
      "address_locality": "Charleston",
      "address_region": "SC",
      "postal_code": "29401",
      "address_country": "US",
      "first_name": "Jane",
      "last_name": "Smith"
    },
    "id": "instr_gp_msg_084a3d56-3491-4b5e-ae3e-b1c45b22fa50",
    "credential": {
      "type": "PAYMENT_GATEWAY",
      "token": "gpaytok_a56f9f4d-6f61-41ed-95a1-f0fa1c4ea65d"
    }
  }
}

## Response (Order Created)
{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ]
  },
  "id": "ord_dd2f9a45",
  "checkout_id": "chk_77d201eb",
  "permalink_url": "https://example-merchant.com/orders/ord_dd2f9a45",
  "line_items": [
    {
      "id": "li_1",
      "item": {
        "id": "sku_stickers",
        "title": "UCP Demo Sticker Pack",
        "price": 599,
        "image_url": "https://example.com/images/stickers.jpg"
      },
      "quantity": {
        "total": 2,
        "fulfilled": 0
      },
      "totals": [
        {
          "type": "subtotal",
          "amount": 1198
        },
        {
          "type": "total",
          "amount": 1198
        }
      ],
      "status": "processing"
    },
    {
      "id": "li_2",
      "item": {
        "id": "sku_mug",
        "title": "UCP Demo Mug",
        "price": 1999,
        "image_url": "https://example.com/images/mug.jpg"
      },
      "quantity": {
        "total": 1,
        "fulfilled": 0
      },
      "totals": [
        {
          "type": "subtotal",
          "amount": 1999
        },
        {
          "type": "total",
          "amount": 1999
        }
      ],
      "status": "processing"
    }
  ],
  "fulfillment": {},
  "adjustments": [],
  "totals": [
    {
      "type": "subtotal",
      "amount": 3197
    },
    {
      "type": "total",
      "amount": 3197
    }
  ],
  "payment": {
    "selected_instrument_id": "instr_gp_msg_084a3d56-3491-4b5e-ae3e-b1c45b22fa50"
  }
}

Step 8: Real-Time Order Updates via Webhooks

This step demonstrates how backend events (e.g., shipping center updates) trigger webhook pushes to the Platform/Agent. This action runs on the Business server and pushes data to the Platform's registered webhook URL.

The order management module solves a critical problem in agentic commerce: "post-purchase anxiety." In traditional AI-assisted purchasing models, once an AI places an order, it often loses visibility into order status. UCP mandates standardized webhook support to address this:

• Event-Driven Architecture: When the merchant's logistics system updates package status (e.g., "shipped", "out for delivery"), the UCP adapter immediately sends a signed message to the agent's registered callback address.
• Structured Data: The pushed data strictly follows the schema definition, containing carrier codes, tracking numbers, and estimated delivery times. This enables AI agents to proactively notify users: "Your coffee beans have shipped and are expected to arrive tomorrow morning"—without the user having to repeatedly ask for updates.

## Webhook Payload (POST)
{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specs/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ]
  },
  "id": "ord_dd2f9a45",
  "checkout_id": "chk_77d201eb",
  "permalink_url": "https://example-merchant.com/orders/ord_dd2f9a45",
  "line_items": [
    {
      "id": "li_1",
      "item": {
        "id": "sku_stickers",
        "title": "UCP Demo Sticker Pack",
        "price": 599,
        "image_url": "https://example.com/images/stickers.jpg"
      },
      "quantity": {
        "total": 2,
        "fulfilled": 2
      },
      "totals": [
        {
          "type": "subtotal",
          "amount": 1198
        },
        {
          "type": "total",
          "amount": 1198
        }
      ],
      "status": "fulfilled"
    },
    {
      "id": "li_2",
      "item": {
        "id": "sku_mug",
        "title": "UCP Demo Mug",
        "price": 1999,
        "image_url": "https://example.com/images/mug.jpg"
      },
      "quantity": {
        "total": 1,
        "fulfilled": 1
      },
      "totals": [
        {
          "type": "subtotal",
          "amount": 1999
        },
        {
          "type": "total",
          "amount": 1999
        }
      ],
      "status": "fulfilled"
    }
  ],
  "fulfillment": {
    "events": [
      {
        "id": "evt_bfb5c145",
        "occurred_at": "2026-01-21T16:07:16.915Z",
        "type": "shipped",
        "line_items": [
          {
            "id": "li_1",
            "quantity": 2
          },
          {
            "id": "li_2",
            "quantity": 1
          }
        ],
        "tracking_number": "1Z999AA10123456784",
        "tracking_url": "https://example-carrier.com/track/1Z999AA10123456784",
        "carrier": "Mock Express",
        "description": "Package handed over to carrier."
      },
      {
        "id": "evt_90097722",
        "occurred_at": "2026-01-21T16:07:35.431Z",
        "type": "shipped",
        "line_items": [
          {
            "id": "li_1",
            "quantity": 2
          },
          {
            "id": "li_2",
            "quantity": 1
          }
        ],
        "tracking_number": "1Z999AA10123456784",
        "tracking_url": "https://example-carrier.com/track/1Z999AA10123456784",
        "carrier": "Mock Express",
        "description": "Package handed over to carrier."
      }
    ]
  },
  "adjustments": [],
  "totals": [
    {
      "type": "subtotal",
      "amount": 3197
    },
    {
      "type": "total",
      "amount": 3197
    }
  ],
  "payment": {
    "selected_instrument_id": "instr_gp_msg_084a3d56-3491-4b5e-ae3e-b1c45b22fa50"
  },
  "event_id": "evt_90097722",
  "created_time": "2026-01-21T16:07:35.431Z"
}

Payment Implementation Scenarios

In traditional digital commerce, we have Payment Service Providers (PSPs)—the financial infrastructure providers that process payments on behalf of businesses.

• Responsibilities: Authorizing and capturing transactions, handling settlements, and communicating with card networks. The PSP often interacts directly with tokens provided by the Credential Provider.
• Examples: Stripe, Adyen, PayPal, Braintree, Chase Paymentech.

In the context of UCP, while the specification defines the "Payment Handler" as an abstract concept, the actual code implementation typically follows one of two distinct topologies:

Scenario A: The Unified Entity (Direct Payment / Cards)

This is the most common scenario for processing raw credit cards, such as using Stripe Elements, Adyen Web Components, or Braintree directly.

• Roles: The Credential Provider (CP) and the Payment Service Provider (PSP) are the same physical entity.
• The Flow:
  1. The Platform uses the Stripe SDK to convert the PAN (raw card number) into a Token. (Here, Stripe acts as the Credential Provider.)
  2. The Platform transmits this Token to the Business.
  3. The Business uses the Stripe API to charge/capture funds using that token. (Here, Stripe acts as the PSP.)
• Conclusion: In architecture diagrams, the "PSP / Handler" represents a single provider (e.g., Stripe).

Scenario B: Distinct Entities (Digital Wallets / APMs)

This scenario applies to digital wallets like Apple Pay, Google Pay, or other Alternative Payment Methods (APMs).

• Roles: The CP and the PSP are two separate, distinct entities.
• The Flow:
  1. The Platform uses the Google Pay SDK (and biometrics) to mint a Token. (Here, Google acts as the Credential Provider.)
  2. The Platform transmits this Token to the Business.
  3. The Business receives the Google Token and sends it to a different processor, such as Adyen, to process the charge. (Here, Adyen acts as the PSP.)

UCP's Role in Agentic Commerce and Strategic Ecosystem Positioning

UCP is a specification for the information flow layer of goods transactions, but it does not define the money flow layer. For payment fund flows, Google has developed AP2 (Agent Payments Protocol). Meanwhile, UCP maintains compatibility with existing AI protocols. UCP is built on industry standards—REST and JSON-RPC transports; Agent Payments Protocol (AP2), Agent2Agent (A2A), and Model Context Protocol (MCP) support built-in—so different systems can work together without custom integration.

Agent Authentication (KYA) and Identity Compliance (KYC)

UCP's design philosophy is that only entities with specialized protective equipment (CP and PSP) should touch sensitive financial data, while others (Platform and Business) only transport sealed containers.

Who handles "touching" and "input"? → The Credential Provider (CP)

This is the first line of defense (frontend compliance) for PCI-DSS.

• Scenario: The user enters a credit card number on the interface (Stripe Elements) or confirms with biometrics (Google Pay).
• Responsible Party: The Credential Provider (e.g., Google, Stripe's SDK).
• Rationale: Their code (iframe or SDK) is what directly reads the user's raw data at that moment. They are responsible for securing the input field and instantly encrypting the raw card number into a Token.

Who handles "decryption" and "charging"? → The PSP

This is the last line of defense (backend compliance) for PCI-DSS.

• Scenario: The Business receives the encrypted Token and needs to charge the funds.
• Responsible Party: The PSP (e.g., Adyen, Stripe).
• Rationale: The PSP holds the private keys to decrypt the Token (or maintains direct connections with card networks). They need to either restore the Token to card number data or exchange it for a bank-recognizable format for settlement.

The providers that bear the ultimate compliance risk points have the deepest moats. Therefore, business providers at this critical node are positioned to be winners in the emerging ecosystem.

The Index Layer and Platform Backend Transformation

UCP's protocol design is decentralized—as long as a merchant has mounted /.well-known/ucp, platforms can interact via HTTP requests. This is very similar to browsers accessing web pages. However, in "commercial transaction" scenarios, this purely P2P model faces a discovery paradox:

• The Problem: When a user tells the platform AI "help me buy a pair of Nike sneakers," the platform cannot possibly poll 10 million UCP nodes across the internet in real-time within milliseconds to ask who has inventory and who offers the lowest price.
• Network Storm: Completely decentralized real-time retrieval would cause massive network storms and latency, making user experience completely unusable.

Furthermore, large Agent providers can build their own indexes, but smaller Agent providers may need to rely on centralized index layers for rapid matching—this layer represents the evolution of traditional trading platforms.

Therefore, centralized indexing is necessary, but what gets indexed will change:

• Traditional Indexing (Google): Indexes HTML text (SEO).
• UCP Indexing: Indexes Capabilities and Metadata. The index tells platforms: "These 50 merchants sell sneakers and support the UCP protocol."

We predict that UCP's ideal architecture will evolve into "Index-Guided P2P Transactions." In this architecture, centralization and decentralization each serve distinct purposes.

In traditional e-commerce models (like Alibaba's Taobao), the platform is centralized, monopolizing not only traffic but also the transaction system. But under the UCP model, the platform's role undergoes a massive transformation: from "mall landlord" to "super buyer agent."

• State Caching & Warm-up:
  The platform's backend periodically (asynchronously) scans popular merchants' /.well-known/ucp, caching merchant Profiles (such as whether they support Shop Pay, whether they support certain extension protocols). When users place orders, the platform no longer needs real-time negotiation for the first step, but can directly initiate optimized Checkout requests with cached Profiles.

  • This requires the platform backend to have powerful concurrent scheduling and state maintenance capabilities.

• Orchestrator Role:

  • Price Comparison Logic: The platform backend can query 5 merchants' real-time quotes in parallel within a single request.
  • Composite Transactions: When a user wants to buy "coffee machine + coffee beans," the platform backend can decompose this intent into purchasing the machine from Business A and beans from Business B, but present a unified Order to the user on the frontend.

The index helps establish connections, but the actual POST /checkout still occurs between Platform Backend <--> Business Server. However, there's no doubt that the index layer and platform backend will become the dominant players of the future.

Detailed Analysis and Investment Opportunities

KYA (Know Your Agent) and Payment Compliance: An Emerging Sector

The Fundamental Challenge: Traditional KYC Doesn't Work for AI Agents

Traditional KYC (Know Your Customer) relies on biometric features (facial scans, fingerprints), government-issued documents (passports, driver's licenses), and physical address verification. However, AI agents present fundamental challenges to this framework:

• The Biometric Paradox: AI agents have no physical form and cannot undergo liveness detection.
• The Scale Paradox: An enterprise might deploy 10,000 procurement agents. Traditional per-capita IDV (Identity Verification) pricing models become economically unviable at this scale.
• Attribution Ambiguity: When an agent commits fraud or executes erroneous transactions, how do we establish accountability through digital signatures to identify the human controller or corporate entity behind it?

Existing Fraud Prevention Systems Are Designed for Humans

Stripe, PayPal, and Visa's risk control models are trained on human behavioral characteristics:

• Behavioral Fingerprints: Mouse movement trajectories, typing speed, page dwell time. Agent operations are instantaneous and mechanical, easily triggering "Bot Attack" interception.
• High-Frequency Micropayments: Agents may conduct hundreds of micro-transactions per minute (e.g., $0.01 to purchase an API call result). Traditional payment gateway fixed fees (such as $0.30 + 2.9%) would consume all profit margins.

Regulatory Pressure Is Accelerating

With the proliferation of AI fraud and Deepfakes, regulators are rapidly tightening controls over non-human actors:

• EU AI Act: Requires high-risk AI systems to be transparent, clearly informing users when they are interacting with machines.
• US CFPB (Consumer Financial Protection Bureau): Increasingly focused on AI's role in financial services, emphasizing "algorithmic accountability."

This regulatory pressure transforms KYA from a "nice-to-have" into a "business necessity." Any enterprise seeking to deploy agents at scale for commercial activities must integrate KYA services to obtain a "compliance shield."

Benchmark Projects

Skyfire Systems

Skyfire Systems was founded by former Ripple executives Amir Sarhangi and Craig DeWitt, giving it deep fintech and blockchain payment DNA from inception. The company completed an $8.5M seed round in August 2024, with investors including Ripple, Circle (the USDC issuer), and Neuberger Berman. Skyfire's core value proposition is to provide AI agents with a fully autonomous financial operating system.

Skyfire's account architecture consists of two tiers, ensuring separation of control and execution:

• User:
  • The highest-level entity, representing a real-world person or enterprise.
  • Responsible for managing Agent accounts and providing verified real-world identity (to endorse the Agent).
• Agent Accounts:
  • The entities that actually execute operations, accessed programmatically via API Keys.
  • Role Isolation: An Agent can only be a Buyer or Seller, not both simultaneously, though a single user can own both types of Agents. Each Agent account has a Skyfire-hosted wallet.
  • Buyer Agent: Represents user spending, owns a wallet, generates Tokens.
  • Seller Agent: Provides services (APIs, MCP servers, etc.), validates tokens, receives funds.

The core of Skyfire's architecture is the KYA+Pay Protocol. It doesn't transmit plaintext data directly but uses JWT-based signed credentials (Tokens) to convey identity and payment intent.

• Standards: Compliant with the KYAPay industry standard, ensuring interoperability.
• Three Token Types:
  1. KYA (Know Your Agent): Contains only identity information. Used for automatic account registration or login.
  2. PAY: Contains only payment promise. Used for checkout by logged-in users.
  3. KYA+PAY: Contains identity + payment. Used for "guest checkout" mode (purchase without pre-registration).
• Transmission Method: After the Buyer Agent generates a Token, it sends it directly to the Seller Agent (via HTTP Header, etc.). The Skyfire platform doesn't intervene in direct token transmission—it only handles generation and settlement.

Skyfire's architecture employs an "offline exchange, online settlement" hybrid model:

1. Generation: Buyer Agent calls the Skyfire API to generate a Token (KYA or PAY).
2. Exchange: Buyer sends the Token directly to the Seller's service endpoint (e.g., MCP server).
3. Verification: Seller uses standard JWKS (JSON Web Key Set) to verify the Token's signature and confirm its legitimacy.
4. Service & Settlement:
   • Seller provides the service/product.
   • Seller calls the Skyfire API (chargeToken) to process the charge.
   • Skyfire transfers funds from the Buyer wallet to the Seller wallet in the background.

Business Model: A classic fintech "toll-booth" model layered with SaaS subscriptions:

• Transaction Commission (Take Rate): A percentage fee on funds settled through the Skyfire network. Given their projected agent commerce volume of up to $46 billion, this revenue potential is substantial.
• SaaS Subscription Fees: Enterprise fees for "console" access, used to manage multi-agent accounts, configure complex policies, and export compliance reports.

Vouched

Vouched originally focused on human identity verification (IDV), serving healthcare and financial industries. In 2025, it completed a $17M Series A round (total funding approximately $23M) and aggressively pivoted to become a leader in AI identity verification (KYA).

Vouched creatively proposed a "hybrid verification" architecture—trusting agents by verifying the humans behind them.

1. Agent Shield:

   • A defensive product deployed at enterprise website frontends. It not only identifies traditional bot attacks but also distinguishes "legitimate agents representing humans" from "malicious crawlers."
   • Mechanism: Analyzes traffic characteristics, session fingerprints, and whether the agent holds a "Vouched reputation credential" to decide whether to allow the agent to access APIs or checkout pages.

2. Agent Bouncer:

   • A continuous monitoring module. Even if an agent passes initial verification, Bouncer continues to monitor its behavior throughout the session.
   • Behavioral Compliance: If an agent authorized for "booking tickets" suddenly starts attempting SQL injection or mass data scraping, Bouncer immediately revokes its permissions.

3. KnowThat.ai (Agent Reputation Directory):

   • Vouched's most strategically significant asset. It maintains a database of verified agents.
   • Network Effects: Merchants can query KnowThat.ai to decide whether to trust an unfamiliar agent. As more agents join, the directory's value increases, forming barriers similar to credit bureaus (Equifax/Experian).

4. MCPI (Model Context Protocol Identity):

   • Vouched is driving integration of the identity layer into the MCP protocol standard proposed by Anthropic. This means identity information will flow seamlessly across different LLMs and platforms as part of the agent context.

Business Model: High-margin B2B SaaS:

• API Call Fees: Per-call charges for both human verification (ID scanning) and agent verification (reputation library queries).
• Platform Subscription Fees: Monthly fees for enterprises using Shield and Bouncer services.
• Certification Fees (Potential): Charging agent developers for the "Verified by Vouched" badge, making them more easily accepted by merchants.

Potential Investment Targets

After UCP's launch, even benchmark projects need to integrate with UCP to join the broader ecosystem. This actually benefits smaller projects, as long as they can launch quickly and flexibly.

Nevermined

Nevermined positions itself as "PayPal for AI," but its technical approach differs fundamentally from Skyfire. While Skyfire embraces the banking system, Nevermined embraces crypto-native micropayments.

Their latest round was $4M (January 2025), led by Generative Ventures with participation from Near Protocol and Polymorphic Capital. Total funding: $7M.

Core Technical Features:

• Payment Protocol (x402):
  • Based on HTTP status code 402 (Payment Required). Nevermined built a standard where when an agent accesses a resource (such as a dataset or API) and receives a 402 error, the agent automatically triggers a payment negotiation flow.
  • Smart Contract Settlement: Payments are completed instantly via blockchain (Layer 2) smart contracts at extremely low cost (<$0.0001), making "pay-per-token" or "pay-per-call" possible.
• Smart Subscriptions:
  • Allows agents to purchase time-limited or usage-limited access rights (in NFT form). This is better suited for on-demand agents than traditional monthly SaaS payments.
• Compute-to-Data:
  • Allows buyer agents to run models on seller's data and retrieve only the results, without touching the raw data. This solves privacy leakage risks and is a key feature for high-value data trading.

The Workflow is quite simple, and provide two methods for both developers and users.

1. Register what you’re charging for
   • Define the thing you want to monetize — an API endpoint, an MCP tool, or a protected asset — plus metadata for discovery.Examples: Agent endpoint, MCP tool method, gated download URL.
2. Create a payment plan
   1. Define pricing and how customers pay:
      • Credits (prepaid) or pay-as-you-go (PAYG)
      • Time-based access, credits-based usage, or trial
      • Fiat (Stripe) or crypto (including stablecoins)
3. Validate, deliver, and settle
   • At runtime, check entitlement before delivering the service/resource.
     • If entitled: deliver and meter usage (redeem credits or settle per request)
     • If not: return HTTP 402 Payment Required (especially for x402 flows)

The monetization workflow is one of the key capabilities, the other one is the compliance and traceability, built upon ERC-8004.

• ERC-8004 compliant identity that works across MCP and A2A ecosystems.
• Always-on identity that follows every deployment and fork.
• Instant look-up of any agent across environments or marketplaces.
• End-to-end trace of every request, policy change and payout
• Timestamped proofs exportable for compliance reporting.

Business Model:

• Protocol Fees: Nevermined takes a commission on each transaction settled through its protocol.
• Infrastructure SaaS: Subscription fees for dashboards, metering, and access control services for developers.

Operations and Financial Analysis:

• Financial Projection: Although individual transaction amounts are tiny (micropayments), massive concurrency creates substantial GMV. Assuming they primarily serve DeFi agents and data markets, their ARR (based on protocol revenue + SaaS) is estimated at $1.2M - $2M.
• Comparative Analysis (vs Skyfire): Skyfire is constrained by credit card fees ($0.30 minimum), making it unable to process micropayments. Nevermined has an absolute cost advantage in the high-frequency, low-value "machine-to-machine (M2M)" transaction space. If the future AI economy consists of billions of $0.01 transactions, Nevermined will be the winner.

The Index Layer and Platform Backendization

In the human-dominated internet, users access frontends through browsers, clicking buttons on visual interfaces to trigger backend logic. In an agent-dominated internet, browsers and frontend interfaces become redundant—even obstacles. AI agents expect to communicate directly with backend logic.

However, existing backend APIs are extremely fragmented:

• Semantic Inconsistency: Salesforce's "Account" and HubSpot's "Company" refer to the same entity but have completely different data structures.
• Protocol Incompatibility: Some use REST, some GraphQL, and some still rely on SOAP.
• Authentication Complexity: OAuth2, API Keys, and mTLS each go their own way.

The Index Layer and Platform Backendization are born to solve this "Tower of Babel" problem.

Benchmark Projects

Unified.to

Unified.to is a leader in the unified API space, with its core philosophy being "One API for All Integrations." Unified.to's product matrix is built around "real-time capability" and "breadth":

1. Unified API (Real-time):

   • Architectural Difference: Unlike traditional ETL tools (like Fivetran) or some competitors (like Merge), Unified.to emphasizes a Passthrough architecture. It doesn't store customer data (No-Storage) but converts and forwards API requests to source systems in real-time.
   • Advantages: This architecture solves agents' "immediacy" needs (a calendar event just created by an agent must be visible immediately), while also eliminating data compliance (GDPR/HIPAA) storage risks.
   • Coverage: Covers 18+ categories including HR, ATS, CRM, Ticketing, GenAI, with 370+ integrations.

2. Unified MCP (New):

   • This is their killer feature for the agent economy. It packages 370+ SaaS integrations into a single standard MCP Server. This means any MCP-compatible LLM (such as Claude Desktop or custom agents) can immediately gain the ability to "read" enterprise Salesforce or Jira data without writing any glue code.

3. Unified SCIM & SSO:

   • For enterprise security needs, provides standard SCIM API for automating employee account CRUD operations, as well as unified SSO authentication.

Business Model & Operating Data: A typical PLG + Usage-based model:

• Grow Plan: $750/month, includes 750,000 API calls.
• Pro Plan: $1,250/month, includes 1,250,000 calls, adds security features like AWS Secrets Manager.
• Scale Plan: $3,000/month, 6,000,000 calls.
• Overage: Charged at $0.50 - $1.00 per 1,000 calls over the limit.

They achieved explosive growth in 2025, with API usage growing 6.5x and revenue growing 4.5x. This indicates that agents consume far more data than traditional GUI applications.

Violet

Violet's architecture is essentially an API Aggregator and Data Normalization Layer. It establishes an abstraction layer between your application (Channel) and thousands of independent e-commerce stores (Merchants).

Core Architecture Components:

• Unified Data Models:

  • This is the core value of the architecture. Different e-commerce platforms define data structures for "Product," "Variant," "Cart," or "Order" in completely different ways.
  • Violet abstracts these heterogeneous data into Common Models. As an architect, you only need to interface with Violet's Offer or SKU objects; Violet handles mapping them back to Shopify's Product or BigCommerce's Item in the background.

• Bidirectional Sync Pipeline (Relay):

  • Read Path: Real-time pulling of merchant inventory, pricing, and product metadata.
  • Write Path: Converts "Checkout" actions into order injection into merchant native systems.

• Connection Layer (OAuth & Auth):

  • Handles authentication with third-party platforms.
  • Shopify Architecture Change (2026 Update): Documentation specifically mentions a key architectural constraint. Starting January 2026, Shopify mandates the use of Single-merchant custom apps. This means the architecture is no longer a simple OAuth universal application model; Channels (as platforms) must pre-register merchants in the backend and generate specific App Credentials, increasing Onboarding complexity but improving security.

Product Line:

Violet's product matrix is clearly designed, corresponding to three lifecycle stages: Onboarding, Transaction, and Data:

1. Violet Connect (Onboarding Gateway):

   • Function: An embeddable Merchant Onboarding component (similar to Stripe Connect).
   • Purpose: Solves the problem of "how to get merchants to connect their stores to your platform."
   • Features:
     • Supports white-labeling—merchants see your brand.
     • Automatically handles API Key exchange, Webhook registration, and catalog sync initialization.
     • Shopify Feature: Supports completing Custom App handshake within 2 minutes via pre-registration link.

2. Prism (Transaction Core):

   • Position: The flagship product—the Unified Commerce API.
   • Functions:
     • Full-Flow Checkout: Supports the complete chain from Create Cart -> Add Item -> Shipping -> Tax -> Payment.
     • Distributed Order Routing: If a user's cart contains items from Merchant A (Shopify) and Merchant B (WooCommerce), Prism handles splitting the order and injecting it into the corresponding backend systems.

3. Relay (Data Bus):

   • Function: Provides bidirectional real-time access to merchant data.
   • Use Cases: Not just checkout, but also keeping product information (descriptions, images, inventory status) on your platform synchronized with merchant sites in real-time.

Business Model:

Violet uses a typical B2B2B (or Platform Enablement) model:

• Role Definitions:

  • Channel (You/Developer): The traffic side. You build apps, games, or social platforms, own users, but don't have products.
  • Merchant: The supply side. Brand owners using Shopify and other site-building tools who own products and inventory.
  • Violet: The infrastructure connecting the two.

• Core Value Proposition:

  • Headless Marketplace: Enables developers to achieve closed-loop e-commerce monetization within their apps without procuring inventory or handling complex warehousing and logistics (handled by the original merchant).
  • Avoiding Redirect Churn: Compared to affiliate marketing that redirects users to Amazon to purchase, Violet allows native in-app checkout, significantly improving conversion rates.

• Revenue Logic (Inferred): Helps Channels manage Commission Rates—automatically calculating how much each transaction retains for the Channel versus the Merchant, and handling split-payment logic at the underlying level (or integrating with payment tools like Stripe Connect).

After Google's UCP emerged, it's actually a challenge for Violet, because UCP essentially aims to solve at the protocol layer what Violet tries to solve at the service layer. However, protocol adoption takes time. Violet, as an established managed service layer, has tremendous value during UCP's adoption transition period. If Violet can transform into a primary UCP "gateway," it will find new life.

Potential Investment Targets

Because e-commerce index layer and platform backend integration projects typically have high valuations, we turn to finding projects with infrastructure capabilities, such as Steel.dev.

Steel.dev

The premise of Agent Commerce is that agents can access the existing World Wide Web. However, running browsers (Chrome/Chromium) is extremely resource-intensive. For a system with thousands of concurrent agents, maintaining a browser cluster is an operational nightmare (memory leaks, zombie processes). More importantly, modern anti-bot defense systems (Cloudflare, Akamai) will intercept standard headless browsers with extreme precision.

Steel.dev provides a cloud-hosted headless browser fleet optimized specifically for LLMs. It is the "ISP" for AI agents. Steel.dev can be understood as "Browser Infrastructure as a Service for LLMs." It aims to solve the "last mile" problem that current AI Agents (such as OpenAI or Claude-based operational agents) encounter when interacting with the real internet. Steel's core architectural goal is to shield the complexity of the modern web (client-side rendering, anti-crawling strategies, authentication) and provide AI Agents with a standardized, programmable interface.

Base Infrastructure Layer (Managed Infrastructure):

• Cloud-Native Headless Fleet: Steel maintains massive browser instance pools in the cloud. Architecturally, it solves the cold start, resource contention, and horizontal scaling challenges developers face when building their own Selenium/Puppeteer clusters.
• Session Persistence: Supports cross-run-cycle Cookie and LocalStorage reuse. This means agents can "remember" login states without re-executing login flows each time—crucial for scenarios requiring complex authentication (like banks or enterprise SaaS).

Middleware & Control Layer (Control & Intervention):

• Compatibility Protocols: Supports standard Puppeteer, Playwright, and Selenium protocols. Existing automation scripts can migrate seamlessly, controlling cloud instances directly via CDP (Chrome DevTools Protocol).
• Anti-Anti-Bot Systems:
  • Fingerprint Management: Built-in Stealth configuration, rotating fingerprints to bypass anti-crawling detection.
  • Proxy Network: Integrated rotating proxies to hide real IPs.
  • CAPTCHA Solving: Automatically handles captcha challenges.
• Hybrid Execution Mode: CLI support for seamless switching between Local Mode (local debugging) and Cloud Mode (production deployment), facilitating developer debugging workflows.

Data Processing Layer (Data Optimization for LLMs): This is the most differentiated part of their architecture, optimized specifically for AI:

• Token Optimization: It can execute page JS to complete hydration, then convert complex DOM into Markdown or cleaned HTML.
• Value: This dramatically reduces the number of tokens input to LLMs (documentation claims up to 80% reduction in token costs and context usage), improving agent processing speed and accuracy.

Steel's product matrix is built around "developer experience" and "runtime capabilities":

Core Services:

• Sessions API: The core backend service. Allows creating and controlling browser sessions via API, executing screenshots, PDF generation, or data extraction.
• Steel Browser: A customized browser environment capable of handling complex modern frontend frameworks (React, Vue CSR rendering, etc.).

Developer Tools:

• Steel CLI: A powerful command-line tool and the primary entry point for developers.
  • steel forge: A scaffolding tool similar to create-react-app, with built-in templates (Playwright, Puppeteer, Python/Node SDK).
  • steel run: Instant runtime environment, supporting cloud task execution without local configuration.
  • steel settings: Environment switcher (local/cloud).
• SDKs: Python and Node.js SDKs for easy backend integration.
• Debugging Suite: Provides Live Session Viewer (real-time browser operation viewing), Replays, and embedded debugging tools, solving the pain point of headless browsers being difficult to debug.

Ecosystem Integrations: Official pre-built templates for mainstream AI Agent frameworks including:

• Browser Use (popular open-source Web Agent framework)
• OpenAI Computer Use
• Claude Computer Use
• LangChain / LlamaIndex (via related templates)

Steel's main competitor is Browserbase. Browserbase recently completed a $40M Series B at a $300M valuation. Browserbase enjoys a massive premium from being at the center of VC hype, but Steel offers highly similar "AI-oriented browser" capabilities. Steel leverages strong open-source community goodwill, typically achieving lower customer acquisition costs (CAC) through developer word-of-mouth.