UCP explained

UCP is an open specification published at ucp.dev under the Apache 2.0 licence, with its source in a public GitHub repository. Google led its development and describes it as compatible with the Agent Payments Protocol (AP2), with integration through APIs, A2A and MCP. Shopify writes 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.

Discovery starts at a fixed address. The 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.

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.

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 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.

{
  "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 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.

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

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

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:

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

The checkout capability defines five operations: Create, Get, Update, Complete and Cancel. Each checkout carries a status, and the status tells the platform what to do next.

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.

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.

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 covers it in the same depth as this article.

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 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.

UCP is versioned by date. The current release on GitHub is v2026-08-25, 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.