Back to Build
Engineering · 10 min read

Beyond the Storefront: Building Bespoke, UCP-Native Commerce

The web was built for human eyes, but the future of commerce is being built for agents.

Traditional e-commerce is a Pull model: a human navigates a UI, clicks buttons, and fills out forms. The Universal Commerce Protocol (UCP) flips this, creating a Push model where stores expose their business logic as a set of programmable tools that any AI agent can understand and execute.

If you're building a bespoke e-commerce stack, implementing UCP is the single most effective way to make your inventory pluggable into the emerging ecosystem of autonomous shopping. Here's how to build a UCP-compliant store from the ground up, based on the core principles at ucp.dev.

1. The Entry Point: Semantic Discovery

In the UCP world, an agent doesn't "scrape" your site - it performs Discovery.

The first requirement for a bespoke store is hosting the discovery pointer at a standardised location:

https://your-store.com/.well-known/ucp

This file points to your discovery endpoint - the "front door" of your protocol implementation. When an agent calls it, your backend returns a Merchant Profile: not just a list of links, but a cryptographic declaration of your identity and your capabilities.

2. The Negotiation: Tools over Endpoints

A fundamental principle of UCP is that it is negotiated. Instead of the store forcing a static API on the agent, the store and agent negotiate a set of tools based on the Model Context Protocol (MCP).

Your bespoke store implements a negotiated block in its discovery response. This block describes your search, cart, and checkout functions as MCP tools.

The power of schema

Each tool includes an inputSchema (JSON Schema). This lets your store have unique requirements - a mandatory loyalty ID, a specific delivery window, a wholesale-only flag - and the agent will learn to provide them just by reading your schema. No SDK update required.

3. Implementing the Lifecycle (Capabilities)

UCP breaks commerce down into modular capabilities. To be fully compliant, your stack must implement these namespaces:

A. The Catalog Capability - dev.ucp.shopping.catalog

Your "read" layer. You map search_catalog and get_product calls to your internal search engine.

Principle: return products in the standardised UCP shape - id, title, variants, price_range. Even if your database uses custom fields, the agent sees a familiar structure.

B. The Cart Capability - dev.ucp.shopping.cart

Carts in UCP are stateful. Your backend generates a unique id (often a gid:// string) and manages a persistent session.

The update pattern: UCP cart updates are full-replace. When an agent updates a cart, it sends the entire intended state of the line items - not a diff. Your logic reconciles the new state against current inventory in real time and returns the resolved cart.

C. The Checkout Capability - dev.ucp.shopping.checkout

This is where your business logic lives. Your checkout tool is responsible for three things:

  • Fulfillment - calculating shipping rates based on the destinations provided.
  • Taxes - applying regional tax rules.
  • Discounts - validating and allocating promo codes.

4. The Security Model: The Escalation Bridge

The most misunderstood part of UCP is escalation. Many developers treat a handoff to a website as a failure. In UCP, it's a security-first principle.

Because agents cannot always satisfy browser-based fraud checks (Riskified, Signifyd, 3D Secure), your bespoke store implements severity levels on every message:

recoverable - the agent can fix this

Example: "Invalid postal code." The agent corrects the field and retries the same operation.

requires_buyer_input - the agent must stop

You provide a continue_url. The human takes over in a secure browser environment to finish the transaction.

By using this escalation model, you protect your bespoke store from bot-driven fraud while still letting the agent do 90% of the manual labor - finding items, building the cart, entering addresses, calculating shipping.

5. Payment Handlers: Decoupling the Transaction

A bespoke UCP store doesn't ask for a credit card number. It negotiates payment handlers.

In your profile, you declare support for handlers like com.google.pay or dev.shopify.card. The agent then provides a secure payment token. Your backend takes that token and passes it to your gateway (Stripe, Adyen, Braintree, etc.).

This zero-knowledge approach ensures that sensitive data never touches the agent's context. Card numbers stay in the buyer's wallet provider; tokens travel through the agent; only the gateway sees the underlying instrument.

Conclusion: The Universal Buy Button

Building a UCP-compliant bespoke store is about more than just adding an API. It's about standardising your intent.

When you implement the discovery, negotiation, and escalation principles of UCP, you're essentially publishing a "user manual" for your store that only AIs can read. The result is a storefront that's open for business 24/7 to every agent on the planet, without you ever having to build a single "human" interface for them.

Building a bespoke UCP store? Let's talk.

We've shipped UCP implementations on Shopify-native and fully bespoke stacks. Happy to compare architecture notes, review your discovery profile, or walk through escalation patterns. Free consultation.