# Descubrimiento de comercio
> How to publish a UCP commerce profile so an agent can complete a purchase: services, schemas, payment handlers and keys.
Esta comprobación informa sin mover la puntuación.
*Estas guías de corrección están escritas en inglés.*
An agent asked to buy something has to find the shop, understand the offer, and complete a payment. The first two it can do from your pages. The third it cannot, unless you publish how.
UCP is the profile at `/.well-known/ucp`, without an extension, that declares which commerce services you speak and which payment handlers you accept. This check applies only to a site that looks like a shop: a `Product` or `Offer` block, or a link to a cart or checkout. Everything else reports not applicable.
---
## No commerce profile found
Your pages say you sell something and nothing says how an agent completes a purchase. It can reach your checkout and then has to drive a form built for a person.
```
GET /.well-known/ucp
{
"ucp": {
"version": "2026-08-25",
"services": {
"com.example.catalog": {
"rest": { "schema": "https://example.com/openapi.json" }
}
},
"payment_handlers": [{ "name": "stripe" }]
}
}
```
---
## The profile is not valid JSON
Note that the path has no extension, which makes it a common victim of a server that decides content type from the filename and serves it as HTML. Check what it actually returns before looking for a syntax error.
---
## No ucp object
Everything lives under a top-level `ucp` key, so that the file can carry other things beside it later. A profile with the fields at the root will not be read.
---
## No version
UCP is young and moving. Without `ucp.version` a client cannot tell which revision your shapes follow.
---
## A version that is not a date
UCP versions are dates, not semantic versions: `2026-08-25`, not `1.0.0`. The same convention MCP uses, for the same reason.
---
## No services declared
The profile exists and offers nothing. An agent learns you have a commerce profile and still cannot call anything.
---
## A service key that is not reverse-DNS
Service keys are reverse-DNS, like `com.example.catalog`, so that two vendors cannot claim the same name in a profile that aggregates several.
---
## A service with no schema
A service names a transport and no description of what it accepts. An agent knows something is there and not how to call it, which is the same as not knowing.
---
## A schema URL that does not resolve
The profile points at a description that cannot be fetched. Same failure as a catalog entry pointing at nothing, with money at the end of it. Fetch every schema URL in your own profile from outside your network.
---
## No payment handlers
The profile describes a catalog and no way to pay for anything in it. An agent can browse and cannot buy, which is the half of the journey this file exists to complete.
---
## An unnamed payment handler
A handler entry with no name cannot be matched against the methods an agent holds credentials for, so it is skipped.
---
## No keys
Informational. `keys` carries the public keys a counterparty uses to verify signed messages from you. Without them every exchange has to be trusted on transport security alone, which is thinner than most people want at a checkout.
---
## The profile itself requires authentication
The discovery document answered `401` or `403`. A profile is how an agent learns you exist as a merchant, so gating it means only clients that already know about you can discover you.
> **Public, like robots.txt**
>
> Discovery documents are the one part of a commerce surface that has to be readable by everybody. The services behind them can require whatever you like.
---
Representación en Markdown de https://axrush.com/guides/commerce-discovery