Why UCP
- Rail-agnostic — same token can settle via stablecoin, card, ACH, wire, or on-chain
- Human-and-agent compatible — works for both AI buyers and traditional checkout
- Discoverable — merchants publish their capabilities at
/.well-known/ucp - Programmable — settlement rules, windows, and reconciliation built in
Anatomy
Create a UCP token (merchant side)
token to the buyer.
Settle a UCP token (buyer side)
Key endpoints
| Endpoint | Purpose |
|---|---|
POST /v1/ucp/tokens | Merchant creates a checkout token |
POST /v1/ucp/settle | Buyer settles a token |
GET /v1/ucp/settlements/:id | Poll settlement status |
POST /v1/ucp/merchants | Register a merchant catalog |
GET /v1/ucp/merchants | List merchants (discovery) |
POST /v1/ucp/checkouts | Full checkout session (cart model) |
POST /v1/ucp/orders | Order tracking + fulfillment events |
POST /v1/ucp/identity | Link buyer identity for compliance |
GET /.well-known/ucp | Merchant capability discovery (public) |
GET /ucp/schemas | JSON schemas for all UCP objects |
Settlement rules
Merchants can define rules that automatically route or split settlements:Discovery
Merchants publish their UCP capabilities at a well-known URL:When to use UCP vs. others
- Use UCP when the merchant wants flexibility on settlement rails (stablecoin OR card OR ACH) or needs programmable fee splits
- Use ACP or AP2 when integrating into Stripe/OpenAI or Google ecosystems specifically — those protocols are prescribed for those marketplaces
- Use x402 when the purchase is per-API-call micropayment
- Use A2A when the purchase is from another AI agent
