FeedBridge.ai Knowledge Base Blog AI Readiness Score

UCP Across the Full Shopping Journey

Hub8 min read2,000 wordsReviewed 2026-04-07

UCP Across the Full Shopping Journey

> UCP covers the entire commerce lifecycle — from the moment an AI agent discovers a merchant's capabilities through product search, catalog lookup, cart management, checkout, identity linking, and post-purchase order tracking — using a single consistent protocol that merchants implement once and agents consume across all supported phases.

---

What Does Full Shopping Journey Coverage Mean?

Most commerce protocols are point solutions: a product feed format handles discovery, a payment API handles checkout, a tracking system handles post-purchase. UCP is different in that it was designed from the outset to handle the full shopping journey as a connected lifecycle. The ucp.dev specification site describes UCP as designed to facilitate the entire commerce lifecycle, from initial product discovery and search to final sale and post-purchase support.

This matters for two reasons. First, it means an AI agent using UCP does not need to switch protocols, data formats, or API architectures as a buyer moves from discovery to purchase to order tracking. The same UCP interaction model — manifest-based capability discovery, consistent endpoint structures, standardised data schemas — applies at every stage. Second, it means merchants who implement UCP fully gain a single integration path that covers all the commerce interactions an AI agent might need, rather than building separate connectors for each phase.

The lifecycle is defined by capabilities. Each phase of the journey corresponds to one or more declared capabilities in the `/.well-known/ucp` manifest. An agent reads the manifest to know which phases the merchant supports and invokes only those capabilities. Merchants who implement more capabilities are reachable for more of the buyer's journey.

---

Phase 1: Discovery

Discovery is the entry point to the UCP journey. An AI agent that wants to interact with a merchant fetches the `/.well-known/ucp` manifest from the merchant's domain. This JSON manifest declares everything the agent needs to begin: which UCP services are supported, what endpoints are available, what capability versions are in use, what payment handlers are configured, and what public keys are used for signature verification.

The manifest also serves a competitive filtering function. When a buyer's intent is expressed to an AI assistant — "find me a running shoe under ₹4,000 in size 10" — the agent queries merchants whose UCP manifests indicate they support product search. Merchants without a manifest are not queryable; merchants with a manifest but no search capability are not searchable; merchants with a manifest and search capability are evaluated against the buyer's intent.

FeedBridge generates the `/.well-known/ucp` machine-readable manifest as a live platform capability. Merchants using FeedBridge have their capability declarations managed through the UCP Dashboard Hub.

---

Phase 2: Search

Once discovery confirms a merchant supports the Catalog Search capability, the agent calls the Catalog Search API — a `POST` endpoint that accepts free-text search queries with optional filters (category, price range, availability) and returns paginated product results. Cursor-based pagination allows agents to retrieve large result sets incrementally.

The quality of search results depends entirely on the richness of the underlying product data. An agent searching for "noise-cancelling headphone for travel under ₹8,000" against a catalog with complete titles, descriptions, intent tags, and structured attributes will return more accurate, more confident results than a search against a catalog with minimal fields. This is where AI enrichment — intent tags, persona arrays, use case descriptions — directly affects search performance.

FeedBridge's Catalog Search API is live, implementing the UCP POST endpoint with free-text search, filters, and cursor pagination.

---

Phase 3: Catalog Lookup

Catalog Lookup is the precision complement to search. Where search is open-ended, lookup is exact: the agent provides a specific `item_id` or barcode (GTIN or MPN) and receives back the full product record for that specific item. This capability is used when the agent already knows which product the buyer wants — perhaps from a prior recommendation, a previous purchase, or a scanned barcode — and needs to retrieve current pricing, availability, and variant options.

The Catalog Lookup API is particularly important for maintaining data accuracy at the point of purchase. By calling lookup immediately before initiating a cart or checkout session, the agent can confirm that the product is still in stock and the price has not changed since the feed was last indexed.

FeedBridge's Catalog Lookup API is live, supporting lookup by `item_id` and barcodes (GTIN/MPN).

---

Phase 4: Cart Management

Cart management is the phase where the buyer's selection becomes a defined basket before purchase commitment. The UCP Cart API provides four operations: create a cart session (with initial items), update the cart (add/remove items, change quantities), get the current cart state (retrieve session by ID), and checkout from cart (transition the cart into a checkout session).

The cart phase is designed for multi-item, multi-step selection. A buyer shopping for a complete home office setup might add a monitor, a keyboard, and a chair to a single cart across several agent turns before committing to checkout. The Cart API preserves this session state across turns, making complex multi-item agentic shopping coherent.

FeedBridge implements the full Cart API — create, update, get, and checkout — as a live capability.

---

Phase 5: Checkout

Checkout is the transactional phase where the cart becomes an order. UCP supports two checkout paths:

Native checkout involves three REST endpoints (create session, update session, complete session) that the agent calls programmatically. The merchant processes payment via Google Pay tokenisation and returns an order confirmation. This path supports both guest and account-linked checkout and provides the most seamless in-assistant purchase experience.

Redirect checkout is the lighter-weight alternative. The agent redirects the buyer to the merchant's checkout page with cart contents pre-loaded. The buyer completes checkout on the merchant's site. FeedBridge's redirect checkout is auto-enabled with privacy and ToS URLs as a live capability.

---

Phase 6: Identity Linking

Identity linking is the capability that enables personalised, account-aware commerce within the UCP model. When a buyer has an existing account with a merchant, identity linking allows the agent to authenticate the buyer's identity against the merchant's system — without exposing passwords — enabling access to stored addresses, loyalty rewards, order history, and personalised pricing.

Google's UCP identity linking documentation specifies that the implementation requires OAuth 2.0 Authorization Code flow (RFC 6749) with HTTP Basic Authentication at the Token Endpoint. Google uses JWT assertions to combine intent checks and token exchange, covering `check`, `create`, and `get` intent operations. FeedBridge supports identity linking as part of the UCP implementation, with an OAuth 2.0 stub live on the platform.

Identity linking is optional for merchants who want to support guest checkout only — Google's implementation guide notes that guest checkout requires no extra steps. Merchants who want account-linked checkout must implement the OAuth 2.0 identity linking capability.

---

Phase 7: Post-Purchase

Post-purchase order tracking and status updates are the final phase of the UCP journey. After checkout is completed, the merchant pushes order status updates to Google's webhooks, covering status transitions from `created` through `confirmed`, `shipped`, and `fulfilled`. These updates keep the buyer's view in the AI interface in sync with the real-world order state.

A merchant who pushes reliable order updates closes the loop on the agentic purchase experience — the buyer who purchased through Google AI Mode receives fulfilment updates within the same assistant interface where they made the purchase, creating a coherent end-to-end experience that reinforces trust in the agentic channel.

---

Journey Phases at a Glance

| Phase | UCP Capability | FeedBridge Support | |---|---|---| | Discovery | `/.well-known/ucp` manifest | ✅ Live | | Search | Catalog Search API (POST) | ✅ Live | | Lookup | Catalog Lookup API (POST) | ✅ Live | | Cart | Cart API (create, update, get, checkout) | ✅ Live | | Checkout — native | Create/update/complete session endpoints | ✅ Live | | Checkout — redirect | Redirect URL with cart pre-load | ✅ Live | | Identity linking | OAuth 2.0 / JWT intent flow | ✅ Live (OAuth 2.0 stub) | | Post-purchase | Order status webhooks | Merchant-side (not FeedBridge scope) |

---

Why It Matters for Merchants

Full journey coverage gives merchants a progressive adoption path. A merchant can start with discovery and search — implementing only the manifest and Catalog Search API — and immediately gain presence in AI-powered product discovery on Google surfaces. They can then add cart management for multi-item exploration, redirect checkout for purchasability, native checkout for a fully seamless experience, and identity linking for personalisation. Each phase adds value independently while building toward a complete agentic commerce presence.

This progressive model also reduces implementation risk. Merchants do not need to build every UCP capability before benefiting from the protocol. The capability declaration model means partial implementations are valid and functional, not broken.

---

FeedBridge Relevance

FeedBridge covers all phases of the UCP journey through its live protocol stack. The manifest, search API, lookup API, cart API, redirect checkout, and identity linking stub are all live. The UCP Dashboard Hub gives merchants a capability checklist that maps directly to the journey phases described on this page, showing which phases are active and which have outstanding implementation steps. The AI Readiness Score's Protocol Compliance dimension (30% of total score) validates whether the product data and protocol endpoints are correctly configured across the phases the merchant has declared support for.

---

Frequently Asked Questions

Q: Can I implement UCP phases one at a time? A: Yes. UCP uses a capability declaration model. Merchants declare which phases they support in the `/.well-known/ucp` manifest. Agents work within declared capabilities. Adding a new phase requires implementing the corresponding API and updating the manifest declaration.

Q: Does UCP require identity linking for all checkout flows? A: No. Google's UCP guide explicitly states that guest checkout is the default path and requires no extra steps. Identity linking is an optional capability for merchants who want to support account-linked checkout experiences.

Q: Which phase has the highest implementation complexity? A: Native checkout is typically the most complex phase, requiring three REST endpoints, Google Pay integration, and order webhook delivery. Identity linking is the second most complex, requiring OAuth 2.0 implementation. Discovery, search, and catalog lookup are the most straightforward starting points.

Q: Is post-purchase tracking part of the UCP protocol or a separate integration? A: Post-purchase order status updates are managed via webhook calls that the merchant pushes to Google's endpoint after order creation. This is part of the UCP integration but implemented as a webhook push from the merchant's OMS rather than as a merchant-hosted API endpoint.

Q: Can I use FeedBridge to test my UCP implementation before going live? A: Yes. The API Playground in FeedBridge allows merchants to test Catalog Search, Catalog Lookup, and Cart API responses in-dashboard. The UCP Dashboard Hub's compliance scorecard shows the current active status of each capability. Merchants can use these tools to verify their implementation before submitting for Google's integration approval.

---

Related Topics

Parent hub: UCP Foundations

Related concepts:

Prerequisites (read first): Next steps (read after): ---

Breadcrumb:

---

Source Documentation

| Claim | Source | Source Class | Reference | |---|---|---|---| | UCP covers full commerce lifecycle: discovery through post-purchase | ucp.dev | T1 – Official UCP Docs | http://ucp.dev | | Identity linking: OAuth 2.0 Authorization Code flow, JWT assertions, check/create/get intents | Google UCP Identity Linking Guide | T1 – Official UCP Docs | https://developers.google.com/merchant/ucp/guides/identity-linking | | UCP checkout: create, update, complete; guest checkout default; account-linked optional | Google UCP Guide | T1 – Official UCP Docs | https://developers.google.com/merchant/ucp/guides | | FeedBridge: manifest, search, lookup, cart, redirect checkout, identity linking stub | FeedBridge Platform Capabilities April 2026 v2.0 | T1 – FeedBridge Internal | FeedBridge-Platform-Capabilities-April2026.md |

---

Related Topics

How UCP Powers Agentic Checkout
Checkout · UCP
What Is the Universal Commerce Protocol (UCP)?
Foundations · UCP
UCP Identity Linking Overview
Identity · UCP
UCP Merchant Center Onboarding Explained
Implementation · UCP
ACP Checkout API Overview
Checkout · ACP
ACP Delegated Payment Flow Explained
Checkout · ACP
← Back to UCP