# UCP explained

The Universal Commerce Protocol: the profile a store publishes at /.well-known/ucp, the capabilities it declares there, and the checkout flow from a new basket to a placed order.

By Valerii Checha, 16 Oct 2026

An AI shopping agent that wants to buy from your store has two ways in. It can work through the website the way a person does, page by page, or it can talk to the store through an interface built for software. The Universal Commerce Protocol (UCP) is one attempt to define that second interface so that any agent and any store can use the same one. This article walks through what the specification says: where a store publishes its details, what it declares there, and how a checkout moves from a new basket to a placed order.

If you are new to the series, [the hub article](https://storewalk.ai/blog/why-agents-cant-buy) explains why agents fail on most stores today. UCP addresses two of those failures: finding out what a store offers, and getting through checkout.

## What UCP is and who is behind it

UCP is an open specification published at [ucp.dev](https://ucp.dev/) under the Apache 2.0 licence, with its source in a [public GitHub repository](https://github.com/Universal-Commerce-Protocol/ucp). Google [led its development](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/) and describes it as compatible with the Agent Payments Protocol (AP2), with integration through APIs, A2A and MCP. Shopify [writes](https://shopify.engineering/ucp) that it "co-developed UCP with Google to create an open standard for AI agents to connect and transact with any merchant". Both announcements are dated 11 January 2026.

The ucp.dev home page lists more companies as co-developers and about 50 as endorsers. That list sits on the protocol's own site, and we have not checked it against each company's own announcement, so this article names only Google and Shopify as backers.

Who governs the specification is not published. The site's footer reads "Copyright 2026 UCP Authors". The specification reserves the `dev.ucp.*` namespace for "capabilities sanctioned by the UCP governing body", but it does not say who that body is.

The specification calls the store the business, and the agent's side, the software that calls the store on a shopper's behalf, the platform. The person the purchase is for is the buyer. This article uses the same words.

## How an agent finds your store's profile

Discovery starts at a fixed address. The [specification overview](https://ucp.dev/latest/specification/overview/) puts it in one line: "Businesses publish their profile at `/.well-known/ucp`." For a store at `example.com`, that is `https://example.com/.well-known/ucp`. An agent that knows your domain therefore knows where to look. The wider practice of publishing machine-readable files under `/.well-known/` is the subject of [how agents discover a store](https://storewalk.ai/blog/how-agents-discover-a-store).

The exchange runs in both directions. When a platform sends a request to your store, it puts the address of its own profile in a `UCP-Agent` request header, so your store can look that profile up.

The overview then lists what a platform must do with your profile, in this order. A schema here is a machine-readable description of what each message must contain.

1. Discovery: fetch the business profile from `/.well-known/ucp`.
2. Negotiation: compute the capability intersection, the set of features both sides support.
3. Schema fetch: "Fetch base schema and all active extension schemas".
4. Version compatibility: check that each extension works with the versions agreed. Incompatible extensions are excluded.
5. Compose: merge the schemas into one.
6. Validate: "Validate requests and responses against the composed schema".

The agent reads your profile, works out which features the two of you have in common, and then checks every message it sends you, and every reply, against published schemas.

## What the profile contains

The profile is a JSON document. The overview says it is "a JSON object with a required `ucp` member", and that this member holds the protocol version, services, optional capabilities and payment handlers. The [profile schema at the 2026-08-25 release](https://github.com/Universal-Commerce-Protocol/ucp/blob/v2026-08-25/source/schemas/ucp.json) requires `services` and `payment_handlers` in a business profile. The overview adds that both "MUST be present even when empty".

Here is the outline of the document. It shows the shape only and is not a working profile; the `…` parts are where each entry's details go.

```json
{
  "ucp": {
    "version": "2026-08-25",
    "services": { "…": ["…"] },
    "capabilities": { "dev.ucp.shopping.checkout": ["…"] },
    "payment_handlers": { "…": ["…"] }
  }
}
```

What each part is for:

- `version` is the protocol version, written as a date in `YYYY-MM-DD` form. A business that still supports older versions can list them in `supported_versions`, which maps each older version to a profile for that version.
- `services` says how a platform reaches the store. A transport is the channel the messages travel over, and the specification defines four: `rest`, `mcp`, `a2a` and `embedded`. MCP is listed there as one way to carry UCP messages. [UCP vs ACP vs MCP vs AP2](https://storewalk.ai/blog/ucp-vs-acp-vs-mcp-vs-ap2) sets out which layer each one covers.
- `capabilities` says what the store can do, such as checkout. The schema marks it optional.
- `payment_handlers` lists the store's payment handlers, which the checkout specification says "are discovered from the business's UCP profile at /.well-known/ucp".

Below is a fuller example, also made up. Choosing a key shows what it is for, first in our words and then in the specification's.

A UCP business profile, key by key.

Example profile, shortened and made up for this figure; “…” marks details left out. It is not a working profile. Fetched from https\://example.com/.well-known/ucp:

```json
{
  "ucp": {
    "version": "2026-08-25",
    "services": { "…": ["…"] },
    "capabilities": {
      "dev.ucp.shopping.checkout": ["…"],
      "dev.ucp.common.identity_linking": ["…"],
      "com.example.installments": ["…"]
    },
    "payment_handlers": { "…": ["…"] }
  }
}
```

- /.well-known/ucp. In our words: The fixed address where an agent looks first. It needs only your domain to find it. What the specification says: “Businesses publish their profile at /.well-known/ucp.” Platforms send the address of their own profile in the UCP-Agent request header. Source: [UCP specification overview](https://ucp.dev/latest/specification/overview/).
- ucp. In our words: The one member every profile has. Everything else sits inside it. What the specification says: “A profile document is a JSON object with a required ucp member”, holding the protocol version, services, optional capabilities and payment handlers. Source: [UCP specification overview](https://ucp.dev/latest/specification/overview/).
- version. In our words: Which protocol version the store speaks, written as a date. What the specification says: Versions are dates in YYYY-MM-DD form; the current release is v2026-08-25. “Businesses that support older protocol versions SHOULD include a supported_versions object mapping each older version to a version-specific profile URI.” Sources: [UCP specification overview](https://ucp.dev/latest/specification/overview/) and [UCP releases on GitHub](https://github.com/Universal-Commerce-Protocol/ucp/releases).
- services. In our words: How an agent reaches the store: which channels the messages can travel over. What the specification says: Required: “The services and payment_handlers registries MUST be present even when empty.” A registry “keyed by reverse-domain name”. The transports are “rest, mcp, a2a, embedded”. Sources: [UCP specification overview](https://ucp.dev/latest/specification/overview/) and [UCP profile schema, v2026-08-25](https://github.com/Universal-Commerce-Protocol/ucp/blob/v2026-08-25/source/schemas/ucp.json).
- capabilities. In our words: What the store can do. An agent keeps only the capabilities it supports too. What the specification says: Optional. A registry “keyed by reverse-domain name”. After fetching the profile, platforms “Compute capability intersection”. Sources: [UCP specification overview](https://ucp.dev/latest/specification/overview/) and [UCP profile schema, v2026-08-25](https://github.com/Universal-Commerce-Protocol/ucp/blob/v2026-08-25/source/schemas/ucp.json).
- dev.ucp.shopping.checkout. In our words: The checkout capability: ucp.dev written backwards, then the service, then the capability. What the specification says: Names “MUST use the format: {reverse-domain}.{service}.{capability}”. Checkout has five operations: Create, Get, Update, Complete and Cancel. Sources: [UCP specification overview](https://ucp.dev/latest/specification/overview/) and [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
- dev.ucp.common.identity_linking. In our words: Lets an agent act on a shopper’s account at the store, once the shopper allows it. What the specification says: It “enables a platform to obtain authorization to perform actions on behalf of a user”, and “identity linking upgrades the experience, it does not gate it”. Sources: [UCP specification overview](https://ucp.dev/latest/specification/overview/) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- com.example.installments. In our words: A store’s or vendor’s own extension, named under its own domain. What the specification says: The overview’s example of a vendor extension, extending dev.ucp.shopping.checkout. Reverse-domain naming “eliminates the need for a central registry”. Source: [UCP specification overview](https://ucp.dev/latest/specification/overview/).
- payment_handlers. In our words: How the store takes payment: a registry of payment handlers, keyed by reverse-domain name. What the specification says: Required, even when empty. Payment handlers “are discovered from the business’s UCP profile at /.well-known/ucp”. Sources: [UCP specification overview](https://ucp.dev/latest/specification/overview/) and [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).

At the release tag, `services`, `capabilities` and `payment_handlers` are each a registry "keyed by reverse-domain name". The next section explains those names.

## Capabilities and how they are named

Every capability and service name follows one pattern: `{reverse-domain}.{service}.{capability}`. The checkout capability is `dev.ucp.shopping.checkout`: the domain `ucp.dev` written backwards, the service `shopping`, the capability `checkout`. Identity linking is `dev.ucp.common.identity_linking`. The overview says this naming "eliminates the need for a central registry": whoever owns a domain can name capabilities under it. Its example of a vendor extension is `com.example.installments`, which extends `dev.ucp.shopping.checkout`. The `dev.ucp.*` names are reserved for capabilities the UCP governing body sanctions.

The overview's navigation lists these capabilities and extensions:

| Group    | Capabilities                                               | Extensions                                                          |
| -------- | ---------------------------------------------------------- | ------------------------------------------------------------------- |
| Common   | Identity Linking, Location                                 | Loyalty                                                             |
| Shopping | Checkout, Cart, Catalog (Search, Lookup), Order, Permalink | Fulfillment, Discounts, Buyer Consent                               |
| Payment  | Payment Handlers                                           | AP2 Mandates, Payment Authentication, Payment Terms, Split Payments |

A store does not have to declare all of them. Negotiation keeps only what both the store and the platform support.

## The checkout, step by step

The [checkout capability](https://ucp.dev/latest/specification/shopping/checkout/) defines five operations: Create, Get, Update, Complete and Cancel. Each checkout carries a status, and the status tells the platform what to do next.

A UCP checkout, message by message.

1. Agent platform → Business: GET /.well-known/ucp. Businesses publish their profile at /.well-known/ucp. Platforms send their own profile URI in the UCP-Agent request header. Source: [UCP specification overview](https://ucp.dev/latest/specification/overview/).
2. Business → Agent platform: Business profile. The profile schema requires services and payment_handlers; capabilities and version are also present. Source: [UCP profile schema, v2026-08-25](https://github.com/Universal-Commerce-Protocol/ucp/blob/v2026-08-25/source/schemas/ucp.json).
3. Agent platform → Business: Create checkout. Checkout operations are Create, Get, Update, Complete and Cancel. Every checkout carries a status, and incomplete is one of them. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
4. Agent platform → Business: Update checkout. Update is a full replacement of the checkout resource. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
5. Agent platform → Business: Complete checkout. Complete finalizes the checkout and places the order. Other statuses include ready_for_complete, complete_in_progress, completed and canceled. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).

Escalation case:

1. Business → Agent platform: requires_escalation + continue_url. When a checkout is incomplete, or as a response to Complete, a business can return status requires_escalation. When it does, it must provide a continue_url. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
2. Agent platform → Buyer: Hand off at continue_url. In that state, platforms must use continue_url. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).

Here is the same flow in words, with what each status means in the specification's own terms.

The platform starts with Create. If something is missing, the status is `incomplete`: the session "is missing required information or has issues that need resolution". The platform reads the messages the business sends back and should try to fix them with Update.

Update is "full replacement of the checkout resource": the platform sends the whole checkout each time.

When the business has everything it needs, the status becomes `ready_for_complete`: the session "has all necessary information and platform can finalize programmatically". At this point the platform can call Complete.

Complete "finalizes the checkout and places the order". While the business is processing, the status is `complete_in_progress`: "the Complete Checkout request was accepted and the Business is processing the order". When it is done, the status is `completed`: "Order placed successfully".

A checkout can also be cancelled. Its status then becomes `canceled`, meaning the session "is invalid or expired". The specification's state chart says this "can occur from any state". The platform should start a new checkout if the buyer still wants to buy.

Pick a status below to see its meaning and the statuses that can follow it.

UCP checkout statuses, and which can follow each.

- incomplete: “missing required information or has issues that need resolution”. The platform “should attempt to resolve via Update Checkout”. Can move to: ready_for_complete (the chart’s arrow “all info collected”); requires_escalation (when the buyer has to take over). Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
- requires_escalation: “requires information that cannot be provided via API, or buyer input is required”. The business “MUST provide continue_url”, and the platform hands the buyer off there after resolving the errors it can fix itself. Can move to: incomplete (the state chart draws the arrow both ways); completed (the chart’s “continue_url” line ends at completed). Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
- ready_for_complete: “has all necessary information and platform can finalize programmatically”. The platform “can call Complete Checkout”. Can move to: complete_in_progress (the chart’s arrow “Complete Checkout”); incomplete (Complete comes back with a recoverable change); requires_escalation (Complete comes back needing the buyer). Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
- complete_in_progress: “the Complete Checkout request was accepted and the Business is processing the order”. The platform waits while the business processes the order. Can move to: completed (the chart’s arrow to completed). Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
- completed: “Order placed successfully”. Nothing more to do; the business should leave continue_url out from here on. Can move to: no further status. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).
- canceled: “invalid or expired”. The platform “should start a new checkout session if needed”. Can move to: no further status. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).

The state chart notes that canceled “can occur from any state”. The chart’s continue_url line ends at completed, but the text does not say whether or how the platform hears back once the buyer finishes there. Source: [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/).

## When the agent has to hand over to the buyer

The sixth status, `requires_escalation`, means the session "requires information that cannot be provided via API, or buyer input is required".

In that case the business "MUST provide continue_url", and it must include at least one message with one of two severities:

- `requires_buyer_input`: "Business requires input not available via API".
- `requires_buyer_review`: "Buyer review and authorization is required".

For both, the platform's action is the same: hand off via `continue_url`. The platform should first resolve any errors it can fix itself, and then send the buyer to that address.

The `continue_url` "enables checkout handoff from platform to business UI, allowing the buyer to continue and finalize the checkout session". It must be an absolute HTTPS URL and should preserve the checkout state, so the buyer arrives on your checkout with what the agent already set up. The specification says a business should provide a `continue_url` for the other unfinished statuses too, and should leave it out once a checkout is `completed` or `canceled`.

Escalation can come up at more than one point. The state chart links `requires_escalation` to `incomplete`, and a Complete request can itself come back with `requires_escalation` for a buyer hand-off. That is why the sequence figure draws the escalation case apart from the main path. The state chart draws the hand-off at `continue_url` ending in `completed`. The text does not say whether the agent hears back, or how.

The checkout specification states near its start: "The checkout has to be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported." Read as written, by default a person confirms the purchase in an interface they trust. An agent finishing a purchase on its own depends on the store supporting the AP2 Mandates extension.

## Who takes the payment

On who sells, the checkout specification says: "The business remains the Merchant of Record (MoR), and they don't need to become PCI DSS compliant to accept card payments through this Capability." In our words, not the specification's: the merchant of record is the party that sells to the buyer and is responsible for the sale, and PCI DSS is the security standard for handling card data.

The payment group of extensions adds AP2 Mandates, payment authentication, payment terms and split payments.

ACP, whose maintainers file lists OpenAI, Stripe and Meta, also keeps the business as merchant of record but organises checkout and payment differently. [ACP explained](https://storewalk.ai/blog/acp-explained) covers it in the same depth as this article.

## What this means for your store today

You can find out where you stand without reading the schemas. Start by opening `https://your-domain/.well-known/ucp` in a browser, using your store's domain. If it returns a JSON document with a `ucp` member, something already publishes a profile for you. If it returns an error page, nothing does yet at that address. [Agent commerce discovery documents](https://storewalk.ai/checks/DISC-007) covers the same address and its neighbours from the checking side.

The profile is a small file, but it points at checkout operations that end in a real, placed order, so someone has to implement those. On a hosted platform, ask the platform. On a custom build, ask whoever maintains your checkout. These questions map directly onto the specification:

- Do you publish a `/.well-known/ucp` profile for my store, and which protocol `version` does it declare?
- Which capabilities does it declare? Is `dev.ucp.shopping.checkout` among them?
- Which transports are listed under `services`: `rest`, `mcp`, `a2a` or `embedded`?
- Which payment handlers are listed, and does my payment provider appear among them?
- When a checkout needs escalation, where does `continue_url` send the buyer, and does that page keep the basket and the details already entered?

We do not list which platforms support UCP. None of the sources this article uses publishes such a list.

## What is not settled yet

UCP is versioned by date. The current release on GitHub is [`v2026-08-25`](https://github.com/Universal-Commerce-Protocol/ucp/releases), marked "Latest" and not marked as a pre-release. Earlier releases are `v2026-04-08`, `v2026-01-23` and `v2026-01-11`: four releases in about eight months. The core specification carries no "draft" or "released" label. The only maturity label is GitHub's "Latest". Verticals beyond shopping are earlier still: lodging is labelled "draft specification", and food "coming soon".

Several questions stay open in the published text:

- The governing body that sanctions `dev.ucp.*` capabilities is not named.
- Whether, and how, the agent hears back once a buyer finishes at `continue_url` is not specified.
- The co-developer and endorser list on ucp.dev is the protocol's own claim, not each company's.

The sources below were last checked on the date shown, and this article will be updated in place when the specification moves. For how UCP sits next to ACP, MCP and AP2, read [UCP vs ACP vs MCP vs AP2](https://storewalk.ai/blog/ucp-vs-acp-vs-mcp-vs-ap2).

## Sources

- [UCP specification overview](https://ucp.dev/latest/specification/overview/)
- [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/)
- [UCP profile schema, v2026-08-25](https://github.com/Universal-Commerce-Protocol/ucp/blob/v2026-08-25/source/schemas/ucp.json)
- [UCP releases on GitHub](https://github.com/Universal-Commerce-Protocol/ucp/releases)
- [ucp.dev](https://ucp.dev/)
- [Google for Developers: Under the hood of the Universal Commerce Protocol](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/)
- [Shopify Engineering: UCP](https://shopify.engineering/ucp)
- [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/)

Last checked 22 Oct 2026