Treat commerce as a changing state, not a single tool call
Agentic payments enter after discovery and continue into assurance. A product result becomes a quote, cart, order, payment attempt, settlement, shipment or delivery, and possibly a return. Each transition can change the fields the principal cared about. The system needs stable identifiers and a rule for when changed terms require new approval.
Commerce protocols can make catalogs, carts, and orders machine-readable. Payment and authorization protocols solve different responsibilities. The orchestrator must join them without treating a discoverable product as an authorized purchase or a completed payment as successful fulfillment.
| State | Material fields | Control question |
|---|---|---|
| Discovery | Seller, item, price indication | Is this source and seller eligible? |
| Cart | Exact items, quantity, fees, shipping | Does the assembled order fit intent? |
| Order | Final terms, cancellation, delivery | Is approval bound to this version? |
| Payment | Amount, asset, destination, rail | Can the narrow credential execute it? |
| Fulfillment | Receipt, shipment, delivery, return | Did the merchant satisfy the purchased outcome? |
Merchant identity and terms are first-class inputs
An agent needs more than a product name and price. It needs the legal merchant, payment recipient, total cost, availability, delivery promise, refund rules, and evidence it will receive. Marketplace seller identity and fulfillment responsibility must remain visible when the platform controls checkout.
Merchant readiness includes stable product and order APIs, deterministic totals, signed or versioned terms, idempotent checkout, machine-readable receipts, and support paths that do not assume a human remembers the browser session.
- Bind approval to the final merchant and order, not a search result.
- Re-check material changes in price, quantity, fees, seller, or delivery.
- Record why the selected option satisfied the principal's constraints.
- Preserve refund and cancellation rights after the agent completes checkout.
Compose protocols by responsibility
UCP and ACP can carry commerce state; AP2 can represent intent and mandate artifacts; agent-recognition systems can help a merchant identify automated traffic; scoped payment credentials and rails can execute value movement. None of those pieces alone provides the whole purchase lifecycle.
Use an internal order and authority model between protocols. That translation layer should preserve source fields and signatures, reject lossy mappings, and make clear which protocol is authoritative for each fact.
Optimize for the outcome after checkout
The useful success metric is not payment completion; it is the intended product or service received under acceptable terms. Join rail receipts to merchant fulfillment, delivery, return, and refund events. When the outcome diverges, the agent should surface options within policy rather than silently spending again.
Post-purchase agents can monitor delivery, request invoices, cancel within a window, or initiate a return, but each action has its own authority and evidence requirements. A purchase mandate should not automatically grant permission to accept a replacement, pay an extra fee, or send refund value to a new destination.
Agentic commerce succeeds when the system can explain the choice, prove the authority, reconcile the money, and repair the outcome.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.