How UCP over A2A Works: Checkout With a Store’s Agent, Step by Step

UCP, the open Universal Commerce Protocol, has had an A2A binding since its first release in January 2026. A2A, the Agent2Agent protocol, is older still. The idea is simple: instead of calling a store's checkout API, a shopping agent sends messages to the store's own agent, and the checkout comes back inside the replies.

We wanted to see how that works in practice, so we built both sides. UCP Playground can now check out over A2A, and UCP Sandbox has a test florist whose agent answers over A2A. This walkthrough follows one real order through it, step by step: three messages from "add these roses" to a paid order.

#What is UCP over A2A?

UCP over A2A is a way to run UCP checkout as a conversation between two agents. The store publishes an A2A agent card, its UCP profile points to that card, and the shopping agent sends A2A messages carrying UCP checkout actions. Each reply carries the checkout object, exactly as UCP's REST or MCP transports return it.

A2A covers checkout only. Finding products still happens over the store's REST or MCP service, so one order can use two transports: search over MCP, checkout over A2A.

#The setup

• The store: Northlight Flowers on flowers-a2a.ucpsandbox.com, a test florist in UCP Sandbox whose profile offers REST, MCP and A2A. Nothing is charged and nothing ships.
• The agent: UCP Playground, running Claude Sonnet 5, with checkout set to go over the store's agent.
• The task: "Buy one Bouquet of Red Roses for delivery to Sam Lee, 123 Market St, San Francisco. Choose the free delivery option and pay with the test card."

Both runs are public: over A2A 0.3 and over A2A 1.0. Each took 18 seconds and three A2A messages.

#Step 1: find the store's agent in its UCP profile

Every UCP store publishes a profile at /.well-known/ucp. When a store offers A2A, its shopping service lists a transport of a2a, and the endpoint is not an API URL but the store's agent card:

"dev.ucp.shopping": [
  { "version": "2026-08-25", "transport": "rest", "endpoint": "https://flowers-a2a.ucpsandbox.com/ucp" },
  { "version": "2026-08-25", "transport": "mcp",  "endpoint": "https://flowers-a2a.ucpsandbox.com/mcp" },
  { "version": "2026-08-25", "transport": "a2a",  "endpoint": "https://flowers-a2a.ucpsandbox.com/.well-known/agent-card.json" }
]

#Step 2: read the agent card

The agent card is A2A's description of an agent: its name, where to send messages, which A2A versions it speaks, and the extensions it supports. For UCP the important part is the UCP extension, which tells the shopping agent which UCP capabilities the store's agent handles:

{
  "name": "Northlight Flowers",
  "protocolVersion": "0.3.0",
  "url": "https://flowers-a2a.ucpsandbox.com/ucp/a2a",
  "preferredTransport": "JSONRPC",
  "capabilities": {
    "extensions": [{
      "uri": "https://ucp.dev/2026-08-25/specification/reference",
      "required": true,
      "params": { "capabilities": { "dev.ucp.shopping.checkout": [...], "dev.ucp.shopping.fulfillment": [...] } }
    }]
  }
}

Playground shows both documents side by side in the run's Discovery and negotiation tab: the UCP profile it read, then the agent card it points to.

#Step 3: search the catalog over MCP

UCP's A2A binding covers checkout, so the agent found the roses with the store's MCP service (search_catalog), exactly as it would without A2A. From here on, every checkout step is an A2A message.

#Step 4: start the checkout with one message

The agent sends a JSON-RPC message/send to the agent card's url. Two headers matter: UCP-Agent, naming the shopping platform's profile, and X-A2A-Extensions, which switches the UCP extension on. The message carries one data part with the action:

{
  "jsonrpc": "2.0", "id": 1, "method": "message/send",
  "params": { "message": {
    "role": "user", "kind": "message", "messageId": "msg-1",
    "parts": [{ "kind": "data", "data": {
      "action": "create_checkout",
      "line_items": [{ "item": { "id": "bouquet_roses" }, "quantity": 1 }]
    } }]
  } }
}

The store's agent replies with a message of its own. It starts a conversation (contextId), and its data part holds the checkout under a2a.ucp.checkout. Here the checkout is incomplete, with the reason stated the UCP way: "A delivery address is required."

{
  "kind": "message", "role": "agent",
  "contextId": "0d0f7d00-…",
  "parts": [{ "kind": "data", "data": { "a2a.ucp.checkout": {
    "status": "incomplete",
    "totals": [{ "type": "subtotal", "amount": 3500 }, { "type": "total", "amount": 3500 }],
    "messages": [{ "type": "error", "code": "missing", "content": "A delivery address is required.", "severity": "recoverable" }]
  } } }]
}

Leave out the extension header and the store's agent refuses with A2A's "extension support required" error (-32008): it won't treat the message as UCP unless the shopping agent says it speaks UCP.

#Step 5: update until it is ready to pay

The agent sends update_checkout in the same conversation (same contextId) with the buyer, the delivery address and the free delivery option. The reply comes back ready_for_complete. One checkout per conversation, so the messages never need to name it.

#Step 6: complete with a payment part

The last message carries two data parts: the action complete_checkout, and the payment under a2a.ucp.checkout.payment. The reply is the completed checkout with the order's id and link. The run's trace shows the whole conversation: three messages, each with what came back.

Every message has its own messageId, and the store's agent uses it to spot retries: if the network drops the reply to complete_checkout and the agent sends the same message again, it gets the same answer back, and the order is not placed twice.

#The same order over A2A 1.0

A2A itself has moved on: version 1.0 renamed things. The method is SendMessage instead of message/send, the header is A2A-Extensions (with an A2A-Version: 1.0 header alongside), parts drop the kind field, and roles read ROLE_USER and ROLE_AGENT. The agent card lists the versions it serves under supportedInterfaces. Our 1.0 run followed the same three steps with the new names and reached the same result.

UCP's A2A binding was written for A2A 0.3, so the stores that offer A2A today mostly speak 0.3. Our test store answers both.

#What the specification leaves open

Building both sides turned up four places where the binding is not yet precise. None stops a checkout from working, but two implementations can read them differently:

• Action names. The binding shows add_to_checkout and complete_checkout as examples and defines no list. Playground and Sandbox use create_checkout, update_checkout, get_checkout, cancel_checkout and complete_checkout, mirroring the other transports. That is our interpretation, not the specification's.
• Who starts the conversation. The binding's text says the store's agent creates the contextId, but its request schema lists contextId as required, so a correct first message fails the schema.
• Where the extension goes. UCP's agent card schema expects extensions at the top level; A2A puts them under capabilities.
• Which A2A version. The examples follow A2A 0.3, and they mix "type": "data" with "kind": "data".

The UCP project's own A2A sample is being rebuilt from scratch, which makes now a natural moment to settle them in the specification too.

#What it means for stores

• A2A is optional. REST and MCP remain the main ways agents reach a UCP store. A2A suits stores that already run their own agent and want it to handle checkout.
• Point the profile at the card. The a2a service's endpoint is the agent card, and the card must carry the UCP extension, marked required, or a careful client will refuse it.
• Keep checkout identical. The checkout inside a2a.ucp.checkout should be the same object your REST or MCP service returns. Ours is literally the same code path.

#What it means for agent builders

• Search over REST or MCP, check out over A2A: expect to hold two transports for one order.
• Keep the contextId for the conversation, a fresh messageId per message, and reuse it only when retrying.
• Check which A2A version the card offers before choosing message/send or SendMessage.

#Try it

Start a run at flowers-a2a.ucpsandbox.com in UCP Playground, and pick "Store agent · A2A 0.3" or "A2A 1.0" under UCP. Or send the messages yourself: the Sandbox quickstart lists the headers and every action. Playground's Inspect does the same by hand, with the conversation laid out message by message.

#What we'll watch

• The rebuilt A2A sample from the UCP project, and whether the binding moves to A2A 1.0.
• How many stores offer A2A, and whether their cards carry the UCP extension.
• How A2A compares with the Personal Agent Protocol, which also has agents talking to a company's agent. That comparison is next.

#FAQ

#What is UCP over A2A?

It is UCP checkout carried as A2A messages: the shopping agent sends UCP checkout actions to the store's own agent, and each reply contains the UCP checkout object.

#Does A2A replace UCP's REST or MCP transports?

No. A2A is one more transport, and it covers checkout only. Product search still uses the store's REST or MCP service.

#How does an agent find a store's A2A agent?

Through the store's UCP profile at /.well-known/ucp: the shopping service lists a transport of a2a whose endpoint is the agent card, usually at /.well-known/agent-card.json.

#What is the UCP extension in an agent card?

It is how a store's agent says it speaks UCP: an entry with the URI https://ucp.dev/2026-08-25/specification/reference listing the UCP capabilities it handles. The shopping agent activates it with a request header.

#Which version of A2A should I use?

UCP's binding was written for A2A 0.3 and most stores speak 0.3 today. A2A 1.0 renames the method, headers and part format; check the agent card to see what a store supports.

#Can I test it without a real store?

Yes. Northlight Flowers on flowers-a2a.ucpsandbox.com is a test store that answers over A2A 0.3 and 1.0, and nothing is charged. UCP Playground can run an agent against it.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• Checkout Capability: A2A Binding. UCP specification, release 2026-08-25.
• Agent2Agent (A2A) Protocol Specification, version 1.0, including Appendix A (changes from 0.3). Linux Foundation.
• Announcement: legacy A2A sample unmaintained pending v2 rebuild. UCP samples repository, 15 October 2026.
• Run over A2A 0.3 and run over A2A 1.0. UCP Playground, 30 October 2026.

Related coverage: How UCP works: a real agent buys flowers · UCP agent profiles and verifiable identity · UCP food ordering: test a pickup order end to end · What is /.well-known/ucp?