What makes a merchant ready for agents?
An agent-ready merchant lets a buyer or agent discover a real offer, understand eligibility and price, submit valid inputs, pay through an authorized route, receive the promised output, and obtain status, receipt, refund, and support information. Every machine-readable claim must match the live service.
Begin with the Agent Business Readiness Scan. For implementation and test-purchase support, see Agent Merchant Activation.
What belongs in the service catalog?
Each sellable service needs a canonical record:
| Catalog field | What good looks like |
|---|---|
| Service ID | Stable, versioned, and not reused for a different offer |
| Name and description | Plain language describing the actual deliverable |
| Eligibility | Countries, entity types, prerequisites, and exclusions |
| Inputs | Required fields, format, size, and validation rules |
| Output contract | Format, contents, quality boundary, and delivery timing |
| Price | Fixed amount or a server-controlled quote rule |
| External fees | Government, provider, partner, tax, or network fees separated |
| Fulfillment | Milestones, expected processing range, and customer actions |
| Refund boundary | What is refundable and when work becomes irreversible |
| Support | Contact, response path, escalation, and incident reporting |
High-ticket or identity-bearing services should create a quote or deposit flow. Do not present a variable formation or activation case as if it were an instant digital download.
Which discovery surfaces are relevant?
Use only the surfaces that match the deployed product.
| Surface | Purpose | Readiness test |
|---|---|---|
| OpenAPI | Describe HTTP operations | Every documented route, schema, and status is live |
| MCP | Expose agent-callable tools | Tool inputs, authorization, side effects, and outputs are explicit |
| A2A Agent Card | Describe an agent service and its skills | Card uses the current schema and points to real interfaces |
| ACP or UCP | Support agentic catalog and checkout | Catalog, checkout, payment, order, and webhook behavior conform to the selected version |
| x402 or MPP | Charge for deterministic HTTP resources | 402 challenge, payment, delivery, receipt, and failure paths pass |
A2A version 1.0 specifies /.well-known/agent-card.json for public discovery. Protected MCP servers should follow the current authorization specification rather than embedding secrets in tool descriptions. (A2A Protocol Specification; MCP authorization)
What does validate before charge mean?
Validate all information needed to decide whether the request can be fulfilled before creating a non-refundable charge. Check input shape, eligibility, availability, price version, output capability, rate limit, and any required authority.
For a deterministic API, validation can often finish synchronously. For a high-touch service, validation may produce a quote and a human-reviewed case. Charging first and discovering later that the request is unsupported creates refund, support, and trust failures.
How should payment and fulfillment connect?
The server should control the final price and create one order for one verified payment event. Browser redirects and agent claims are not payment evidence. Use signature-verified webhooks or the protocol’s verified receipt, plus idempotency keys and replay handling.
The evidence chain should connect:
catalog version
-> validated request
-> quoted or fixed price
-> authorized payment
-> fulfillment version
-> delivered output
-> receipt and settlement
-> refund or support stateIf delivery fails after payment, the system needs an explicit retry, recovery, or refund path. Silent partial delivery is not acceptable simply because the buyer is an agent.
How do ACP and UCP differ from x402 and MPP?
ACP and UCP cover broader commerce functions such as catalog, cart, checkout, payment handlers, orders, and updates. x402 and MPP focus on paying for a programmatic resource through an HTTP 402 flow. A merchant may support one family, both, or neither.
Stripe’s agentic-commerce documentation currently maps UCP or ACP to selling through agent platforms and x402 or MPP to machine payments. Program access and eligibility can change, so do not advertise compatibility until the selected path passes with the merchant’s real account and service category. (Stripe, Agentic commerce)
What should the test matrix include?
Test more than a successful purchase:
- valid purchase and correct delivery;
- missing or malformed input;
- unsupported customer or jurisdiction;
- stale catalog or price version;
- underpayment or wrong payment method;
- expired or replayed challenge;
- duplicate webhook or retry;
- payment success followed by delivery failure;
- refund before work and after an irreversible milestone;
- revoked buyer or merchant authority;
- discovery file that points to a disabled capability;
- monitoring alert and route shutdown.
A conformance report should name the tested version, date, environment, cases, and results. It is not a blanket certification of security or legal compliance.
Who owns support after an agent buys?
The merchant still owns the customer relationship, fulfillment, refunds, complaints, and dispute response unless a clearly disclosed provider contract says otherwise. Agents do not remove the need for readable terms or a reachable support channel.
Provide status that an authorized agent can read, but keep customer identity, documents, secrets, and unrelated case data private.
What is the next step?
Inventory one real offer and trace it from discovery through settlement and support. Use the readiness scan to identify missing business prerequisites. Then request an Agent Merchant Activation assessment for catalog normalization, protocol selection, conformance, and a controlled test purchase.
Last updated August 2026. Protocol versions, provider programs, eligibility, and pricing can change. Confirm current primary documentation before production use. This is not legal, tax, financial, or security advice.
Primary sources:
