UCP Capability Profiles Explained: 9 You Must Know

A few months ago we were debugging a merchant integration that looked perfect on paper. The manifest validated. The product feed was clean. An automated checker gave it a green badge. Then we pointed a real buying agent at it and watched the agent stall at the payment step, unable to figure out whether the store could tokenize a card, hold an authorization, or split a payment across two handlers. The store had declared almost nothing about what it could actually do. That gap between “I have a valid UCP manifest” and “an agent can complete a purchase here” is exactly why UCP capability profiles explained properly is one of the most important things we teach every client. Capability profiles are the contract that tells an agent what your storefront can and cannot handle before it ever tries.

In our experience building UCP infrastructure for real stores, the manifest is the easy part. The hard part is declaring your capabilities honestly and completely so agents do not guess. This article walks through the nine capability profiles and payment handler patterns that we see decide whether agentic checkout succeeds or silently fails, ordered roughly by how often they cause problems in the field.

TL;DR

Capability profiles are machine-readable contracts: A UCP capability profile is a structured declaration of exactly what your store supports, from inventory checks to payment tokenization, so agents never have to guess or probe blindly.
Payment handlers are where most agentic checkouts break: In our experience the gap between a valid manifest and a completed purchase almost always lives in the payment capability declaration, not the product data.
Declare less than you support and you lose sales; declare more than you support and agents abandon mid-checkout: The entire discipline of UCP capability profiles explained here is about matching your declared profile to your real runtime behavior within a tight tolerance.

Why Capability Profiles Decide Whether Agents Buy or Bounce

Before the list, one framing point we repeat to every merchant. An AI agent shopping on behalf of a human does not want to explore your site. It wants a contract. It reads your capability profile, decides in milliseconds whether a transaction is even possible, and either proceeds or moves to a competitor that declared itself more clearly.

According to UCP Checker, which independently monitors 23,785+ storefronts, roughly 69% pass full UCP validation (16,376 verified). We want to be careful with that number: it reflects the stores UCP Checker tracks, which skew heavily toward Shopify, and it does not mean 69% of all ecommerce has UCP. More importantly, a conformant UCP manifest is not the same thing as an agent being able to complete a real checkout. We have seen plenty of “valid” stores that fail at the capability layer, which is exactly the problem this article addresses. If you want the broader context first, our definitive guide to what UCP is covers the protocol end to end.

1. The Discovery Profile: How Agents Learn You Exist

Standout feature: The discovery profile is the front door. It tells an agent which UCP version you speak, which other profiles you support, and where to find your endpoints. Get this wrong and nothing downstream matters.

In our implementations the discovery profile is the first thing we validate and the first thing we lock down. It declares your protocol version (we tell clients to pin a specific minor version rather than a floating “latest”), the list of supported capability profiles by name, and the authentication scheme agents must use to talk to you. When agents hit a malformed discovery document, they do not retry patiently. They disqualify the store.

We have found the most common discovery mistake is version drift. A store upgrades its commerce backend, the supported-profiles array falls out of sync with what the backend actually implements, and agents start requesting capabilities the store no longer honors. The fix is simple but disciplined: treat the discovery profile as a generated artifact, not a hand-edited file, and regenerate it on every deploy.

Best for: every single UCP store, with no exceptions. There is no valid UCP implementation without a discovery profile, which is why it sits at number one. For the deeper mechanics of how discovery fits the overall stack, our UCP technical architecture deep dive maps the full request flow.

Capability checklist for discovery:

Version pinning: Declare an exact UCP protocol version, not a floating alias.
Profile enumeration: List every capability profile you genuinely support, nothing aspirational.
Endpoint accuracy: Point to live endpoints that respond under 500ms at the p95.
Auth clarity: Name one authentication scheme and document token lifetime.
Regeneration on deploy: Rebuild the discovery document automatically with each release.

2. The Catalog and Product Profile: Machine-Readable Truth

Standout feature: The catalog profile exposes structured product data, variants, attributes, and availability in a form an agent can reason about without scraping your HTML.

This is the profile most merchants think they already have handled because they run a product feed. They do not. A marketing feed is built for ranking and display. A UCP catalog profile is built for a machine that needs to resolve a specific SKU, confirm it exists, and understand its purchasable attributes before committing to a cart. The two overlap but are not interchangeable, a distinction we unpack in our piece on how UCP changes SEO, feeds, and product data.

We tell clients the catalog profile has one job above all others: never lie about availability. An agent that adds an item to cart based on your declared availability and then fails at checkout because the item was actually out of stock will not just abandon; the orchestration layer behind it may deprioritize your store for future queries. We target availability accuracy within a 60 second staleness window for fast-moving inventory.

Best for: stores with more than a few hundred SKUs or any store with variant-heavy products where agents need deterministic attribute resolution.

Catalog profile checklist:

Deterministic SKU resolution: Every declared SKU must resolve to a real purchasable unit.
Variant completeness: Expose all purchasable variant axes, not just the default.
Availability freshness: Keep stock status within a 60 second window for fast movers.
Attribute typing: Use typed fields for size, color, and dimensions, never free text.
Price currency clarity: Declare currency explicitly on every price.

3. The Inventory and Availability Profile: Real-Time Truth Under Load

Standout feature: A dedicated availability capability that answers “can I buy exactly this, right now, in this quantity” with a yes or no an agent can trust.

We separate this from catalog deliberately because in practice they fail for different reasons. The catalog is relatively static; inventory is volatile. During a flash sale we have watched stores with perfect catalog profiles still lose agentic sales because their availability endpoint could not answer fast enough under concurrent agent load. Agents time out at surprisingly tight thresholds, often under one second.

Why capability profiles are important in UCP shows up most clearly here. If you declare a real-time availability capability, agents will depend on it and skip their own defensive checks, which makes your checkout faster and more likely to convert. If you declare it but cannot honor it under load, you have made a promise you break at exactly the wrong moment. Our advice: only declare real-time availability if your p99 response stays under 800ms during your peak concurrency.

Best for: high-velocity stores, limited-drop merchants, and anyone running promotions where stock changes by the second.

Availability profile checklist:

Honest capability flag: Only declare real-time availability if you can serve it under peak load.
p99 latency budget: Keep availability responses under 800ms at the 99th percentile.
Quantity-aware answers: Respond to “can I buy 3 of this” not just “is this in stock.”
Graceful degradation: Return a clear soft-unavailable rather than a timeout when stressed.
Reservation signaling: Indicate whether a yes implies a short hold or none at all.

4. The Cart and Order Composition Profile: Where Intent Becomes a Transaction

Standout feature: A capability that lets an agent build, modify, and price a cart server-side with the same rules a human checkout would enforce.

The cart profile is where discounts, bundles, minimums, and shipping thresholds all collide. We have found that stores frequently expose a cart capability that silently ignores their own promotion rules, so the agent builds a cart at one price and the store charges another at capture. Agents treat that mismatch as a trust violation. The cart you quote must equal the order you capture, within zero tolerance on the total.

Our take is that cart composition should be fully server-authoritative under UCP. The agent proposes line items; your store is the single source of truth on final pricing, applicable promotions, tax, and shipping. If you try to let the agent compute totals client-side, you will spend your life reconciling disputes. For stores moving from bespoke setups, we explain why this matters in UCP versus custom AI integrations.

Best for: any store with promotions, tiered pricing, bundles, or shipping thresholds, which is nearly everyone.

Cart profile checklist:

Server-authoritative totals: The store computes the price; the agent never does.
Promotion transparency: Reflect applied and unapplied promotions in the cart response.
Quote-equals-capture: The quoted total must match the captured total exactly.
Tax and shipping inclusion: Resolve tax and shipping before the agent commits.
Idempotent cart operations: Repeated identical requests must not duplicate line items.

5. The Payment Capability Profile: The Make-or-Break Layer

Standout feature: A precise declaration of which payment methods, tokenization schemes, and authorization models your store supports, so an agent knows how to pay before it tries.

This is the profile we flagged in the opening, and it is where we see the most silent failures. A payment capability profile has to answer several questions unambiguously: which networks and methods you accept, whether you accept tokenized credentials or require your own tokenization, whether you support delayed capture, and how you handle authorization holds. An agent carrying a tokenized payment credential needs to know in advance whether you can consume it.

The single biggest lesson we have learned shipping UCP checkouts: a store that under-declares its payment capabilities loses sales it could have won, and a store that over-declares them abandons buyers at the worst possible moment, so declare exactly what you can honor at runtime, no more and no less.

When we built our first production payment handler flow, the breakthrough was treating the payment profile as a strict contract rather than a hint. We declare only the methods we have verified end to end against a live authorization, and we test the full authorize-capture cycle, not just the token exchange. The subtlety that trips people up is partial capability: a store might support card tokenization but not delayed capture, and an agent planning a split shipment needs to know that distinction before it composes the order.

Best for: literally every store accepting agentic payment, which is the entire point of UCP. This is the profile to audit first.

Payment profile checklist:

Method enumeration: List every payment method and network you actually accept.
Tokenization clarity: State whether you consume external tokens or tokenize yourself.
Capture model declaration: Specify immediate versus delayed capture explicitly.
Authorization semantics: Declare hold duration and partial-authorization support.
End-to-end verification: Only declare a method you have tested through capture, not just auth.
Failure signaling: Return structured decline reasons an agent can act on.

Build Capability Profiles Agents Actually Trust, With UCPhub

Declaring capability profiles correctly is tedious, high-stakes work, and getting a single payment flag wrong can quietly cost you every agentic sale that touches it. This is exactly what we built the UCPhub platform to handle: our Universal Commerce Protocol infrastructure generates, validates, and continuously reconciles your capability profiles against real runtime behavior, so your declared contract always matches what agents actually experience at checkout. If you want agentic buyers to trust your store instead of bouncing to a competitor, talk to our team at UCPhub and we will map your current capabilities against the full UCP profile set.

6. The Fulfillment and Shipping Profile: Promising What You Can Deliver

Standout feature: A capability declaring shipping options, destinations, delivery windows, and constraints so an agent can factor fulfillment into its buying decision.

Agents increasingly optimize for delivery date, not just price. A store that cannot declare whether it ships to a given region, or what the realistic delivery window is, gets skipped when an agent is shopping against a deadline. We have found that fulfillment capability is underinvested precisely because humans tolerate vague shipping promises and machines do not.

The honesty discipline from the payment profile applies here too. If you declare two-day shipping as a capability and your fulfillment reality is five days, agents that complete the purchase will generate the downstream disputes and returns that poison your reputation in the orchestration layer. Declare the delivery window you actually hit at the 90th percentile, not your best case.

Best for: stores with regional restrictions, variable delivery times, or any merchant where delivery date affects conversion.

Fulfillment profile checklist:

Destination declaration: Clearly state which regions and countries you serve.
Realistic windows: Declare delivery windows you hit at the 90th percentile, not best case.
Option enumeration: Expose standard, expedited, and pickup options distinctly.
Constraint signaling: Declare oversized, hazmat, or age-restricted shipping limits.
Cost determinism: Return shipping cost before the agent commits, not after capture.

7. The Returns and Post-Purchase Profile: Trust After the Sale

Standout feature: A capability that exposes your return policy, return initiation, and refund mechanics in a form an agent can evaluate before buying and act on afterward.

This one surprises merchants. An agent making a considered purchase on behalf of a human often weighs return friction as part of the buying decision, the same way a careful shopper reads the returns policy before checkout. Stores that expose a clean returns capability win purchases that stores with opaque policies lose, even at identical prices.

Post-purchase capability also matters for the agent’s lifecycle management. In an agentic commerce world where software increasingly manages ongoing purchasing, as we explore in our look at AI agents becoming the primary shoppers, the agent may need to initiate a return programmatically. If your returns capability is a human-only web form, you have broken the loop.

Best for: considered-purchase categories, apparel, electronics, and any store where return policy is a competitive differentiator.

Returns profile checklist:

Policy transparency: Expose return window, conditions, and restocking fees as structured data.
Programmatic initiation: Allow an agent to start a return without a human-only form.
Refund timeline honesty: Declare realistic refund processing windows.
Eligibility clarity: State clearly which items are final sale or non-returnable.
Status queryability: Let an agent check return status after initiation.

8. The Identity and Consent Profile: Who Is Buying and With What Authority

Standout feature: A capability that establishes who the agent represents, what authority it carries, and what consent boundaries apply to the transaction.

As agents become real buyers, the question of authority becomes central. Is this agent acting with a spending limit? Does it have authority to store a payment credential? Can it agree to a subscription on the human’s behalf? The identity and consent profile is how your store and the agent negotiate those boundaries. We treat it as a safety layer as much as a capability.

In our experience this is the profile most stores have not even considered, because the human web handled identity implicitly through sessions and logins. Agentic commerce makes authority explicit. A store that declares clear consent requirements for recurring charges will avoid the subscription disputes that plague stores that assume consent. This distinction also shapes the broader standards debate we cover in UCP versus ACP and which standard will rule the agentic web.

Best for: subscription stores, high-ticket merchants, and any store where spending authority and recurring consent matter.

Identity profile checklist:

Authority verification: Require agents to present verifiable buying authority for high-value orders.
Consent granularity: Separate one-time purchase consent from recurring-charge consent.
Spending-limit awareness: Honor agent-declared spending limits where present.
Credential storage rules: Declare whether and how you store payment credentials.
Audit trail: Log the consent state attached to every transaction.

9. The Framework We Use: The Honest Capability Alignment Method

We promised a repeatable process, and this is the one we run on every client. We call it the Honest Capability Alignment Method, because the entire goal is to make your declared profiles match your runtime reality within a tight tolerance. Each step below has a plain-English outcome.

Step one, inventory your real capabilities. What this achieves: You replace assumptions with a verified list of what your store can actually do under load, from payment capture to returns initiation, before you declare a single thing.

Step two, declare conservatively. What this achieves: You publish only the capabilities you have verified end to end, which prevents the over-declaration that abandons agents mid-checkout and poisons your reputation with orchestration layers.

Step three, test against live agents. What this achieves: You validate every declared capability with a real buying agent completing a real transaction, catching the gap between a valid manifest and a completable checkout that automated validators miss.

Step four, reconcile continuously. What this achieves: You detect drift between your declared profile and your backend behavior on every deploy, so a backend change never silently breaks a declared capability.

Step five, expand deliberately. What this achieves: You add new capabilities only after verification, turning capability expansion into a safe, measured process rather than aspirational declarations that fail in production.

This method pairs well with choosing the right implementation path, which we compare in detail in our UCP hub versus custom integration comparison.

Alignment method checklist:

Verified inventory first: Never declare a capability you have not confirmed under load.
Conservative declaration: Under-declaring is recoverable; over-declaring burns trust.
Live agent testing: Validate with a real transaction, not just a manifest checker.
Continuous reconciliation: Catch declared-versus-actual drift on every deploy.
Deliberate expansion: Treat each new capability as a verified release, not a flag flip.

Measuring Success: 30, 60, and 90 Day Outcomes

Capability profiles are not a one-time project, they are an operational discipline. Here is how we measure whether a store’s profiles are actually working, framed as concrete outcomes over the first 90 days. The single most important metric is the gap between declared capabilities and completed agentic transactions, which should trend toward zero.

Day 30 outcomes:

Discovery pass rate: 100% of agent discovery requests resolve to a valid, version-pinned document.
Payment capability verified: Every declared payment method tested through a live authorize-capture cycle.
Quote-equals-capture integrity: Zero cart-to-capture total mismatches across test transactions.
Availability latency baseline: p99 availability response measured and documented under normal load.

Day 60 outcomes:

Agent completion rate climbing: Measurable increase in agentic checkouts that complete versus abandon.
Availability under load: p99 availability response holding under 800ms during a simulated peak.
Returns loop closed: At least one programmatic return initiated and completed end to end.
Drift detection live: Continuous reconciliation catching at least one declared-versus-actual mismatch before it reaches production.

Day 90 outcomes:

Declared-versus-completed gap near zero: The difference between declared capabilities and successful transactions approaches zero.
Identity and consent enforced: Recurring-charge consent captured and auditable on every subscription order.
Fulfillment accuracy at 90th percentile: Declared delivery windows matching actual delivery at the p90.
Reputation stability: No orchestration-layer deprioritization traced to broken capability promises.

From Getting Started to Auditing What You Have

If you are just getting started, do not try to declare every profile at once. We tell new clients to begin with the three that gate a transaction outright: the discovery profile so agents can find you, the catalog profile so they can resolve what you sell, and above all the payment capability profile, because that is where the silent failures live. Declare those three conservatively and verify each one against a live agent before touching anything else. For a gentler on-ramp, our UCP for beginners guide is the right starting point.

If you are auditing an existing implementation that already passes a validator, flip the priority. Start with the payment and cart profiles and run a real transaction end to end, because a green validation badge tells you your manifest is well-formed, not that an agent can buy from you. The gap between those two things is the single most expensive blind spot we find in the field.

Next Steps:

Audit your payment capability first: Run one live authorize-capture cycle against each declared payment method this week.
Test with a real agent, not just a checker: Point a buying agent at your store and watch where it stalls.
Map your profiles with our team: Contact UCPhub to align your declared capabilities against the full UCP profile set.

Frequently Asked Questions

What are UCP capability profiles?

UCP capability profiles are structured, machine-readable declarations of exactly what your storefront can do in an agentic commerce transaction. Rather than forcing an AI agent to explore your site and guess at what is possible, a capability profile tells the agent up front which operations you support: discovery, catalog resolution, real-time availability, cart composition, payment handling, fulfillment, returns, and identity or consent management.

Think of each profile as a contract clause. The discovery profile says “here is how to talk to me and what else I support.” The payment profile says “here is exactly how I can accept money.” The agent reads these before it attempts anything, and it uses them to decide whether a purchase is even possible on your store. In our experience, the stores that treat profiles as honest contracts win agentic sales, and the stores that treat them as marketing claims lose buyers mid-checkout.

How do UCP capability profiles work?

At a technical level, an agent first fetches your discovery profile, which enumerates the capability profiles you support and the version of the protocol you speak. The agent then consults the specific profiles relevant to its task. If it wants to buy, it reads your catalog and availability profiles to confirm the item exists and is purchasable, your cart profile to compose and price the order, and your payment profile to understand how to pay.

The critical mechanic is that your store should be the single source of truth throughout. The agent proposes; your store confirms. When the agent composes a cart, your store computes the authoritative total including tax, shipping, and promotions. When the agent presents payment, your declared payment capability governs exactly how that payment can be processed. We have found that the implementations that break are the ones that let the agent compute or assume anything that the store should own. For the full request flow, our technical architecture deep dive walks through it step by step.

Why are capability profiles important in UCP?

Capability profiles are important because they are the difference between a valid UCP store and a store that agents can actually buy from. A manifest can pass every automated validator and still fail at the capability layer, where an agent discovers that your declared real-time availability times out under load, or your payment profile claims delayed capture you do not actually support. That gap is where real revenue leaks.

They also protect your reputation in the orchestration layers that route agents. When an agent completes a purchase based on your declared capabilities and that purchase fails or produces a dispute, the orchestration layer learns to deprioritize your store for future queries. Over-declaring capabilities you cannot honor is therefore not a harmless optimism, it actively suppresses your future agentic traffic. This is why we preach conservative, verified declaration above everything else.

Are payment handlers part of capability profiles?

Yes, and they are the part we scrutinize most. The payment capability profile declares which payment methods, tokenization schemes, capture models, and authorization behaviors your store supports. A payment handler is the runtime machinery that honors what the profile declares: it consumes a tokenized credential, performs the authorization, and executes capture according to the model you declared.

The reason we treat this as make-or-break is that a payment profile is a promise an agent relies on completely. If you declare that you consume external payment tokens but your handler cannot actually process them, the agent gets all the way to the payment step before failing, which is the worst possible place to lose a buyer. We only ever declare payment capabilities we have tested through a full authorize-capture cycle against a live transaction.

How is a UCP capability profile different from a product feed?

A product feed is built for discovery and ranking, optimized to help humans and search engines find and display your products. A UCP capability profile, specifically the catalog portion, is built for a machine that needs to transact. It must resolve a specific SKU deterministically, confirm the exact purchasable variant, and declare availability accurately enough that an agent can commit to a cart without a nasty surprise at checkout.

The two overlap but serve different masters. A feed can be slightly stale and still do its job of surfacing a product. A capability profile that is slightly stale on availability causes failed transactions and lost trust. We explore the broader shift from feeds to machine-readable commerce in our article on how UCP changes SEO, feeds, and product data.

What happens if I declare a capability I cannot honor?

In the short term, agents will trust your declaration and depend on it, skipping their own defensive checks. In the moment the capability fails, the agent abandons the transaction, often at the payment or availability step where recovery is least likely. That is a lost sale you specifically invited by over-declaring.

In the longer term, the damage compounds. Orchestration layers that route agentic traffic treat broken promises as a trust signal and route future buyers elsewhere. This is why our Honest Capability Alignment Method insists on conservative declaration and continuous reconciliation. Under-declaring costs you some sales you could have won; over-declaring costs you sales and your standing with the systems that send agents your way. The asymmetry strongly favors honesty.

Do I need every capability profile to start with UCP?

No. We tell clients to begin with the three profiles that gate a transaction: discovery so agents can find you, catalog so they can resolve what you sell, and payment so they can actually pay. Declare those conservatively, verify each against a live agent, and only then expand to fulfillment, returns, and identity profiles.

Starting narrow and honest beats starting broad and aspirational every time. A store with three verified capability profiles outperforms a store with nine declared-but-unverified ones, because the three-profile store never breaks a promise. Once your core transaction path is solid, adding profiles becomes a safe, measured release process rather than a risk. If you are platform-specific, our Shopify UCP integration guide and WooCommerce UCP integration guide show where to begin on each.