Two Patterns for Agent Purchasing: Micropayments vs. Authorized Checkout
The commercial agent economy runs on two different purchasing models: autonomous per-call micropayments and human-authorized checkout flows. Each has distinct design requirements. Knowing which model applies to your agent avoids building the wrong one.
· 679 words
When your agent needs to buy something, the design question is not whether it can pay. It is who authorizes the payment and when.
Two patterns dominate how agents pay today, and they are not interchangeable. Building an agent that treats a $0.01 per-call service the same way it handles a high-value product checkout will fail in one direction or the other, either adding unnecessary friction to routine operations or moving money without the human who will be billed ever knowing.
Pattern one: autonomous micropayments
The commercial index currently records 264,675 USDC transfers to agent payment addresses in the trailing week. 1,229 distinct services received payment in that period. The median paid endpoint charges $0.01 per call. That is a large volume of small, autonomous transactions. The concentration caveat from the pipeline applies: the top service alone accounts for a large share of all measured transfers, so this is not evenly distributed activity. But the structure is consistent: a call happens, a payment happens, no human approves the individual transaction.
This pattern fits a specific context. The agent has a pre-authorized budget. Each call costs a known, small amount. The action is reversible in the sense that a single call's outcome can be discarded if the agent decides not to use it. Endpoint selection, web search, data retrieval, classification, translation: these are the services where micropayment autonomy is appropriate.
The design requirements are correspondingly simple: a funded wallet, a budget cap, and a record of what was spent. The agent does not pause to ask. It pays, uses the result, and continues.
Pattern two: human-authorized checkout
Shopify's WebMCP checkout addition is an example of the second pattern. The agent's tools (get_checkout, update_checkout, complete_checkout) cover the full checkout workflow, but complete_checkout requires buyer authorization before it fires. The agent does the work of building and verifying the order. The human confirms the final action.
This pattern fits different context: higher-value purchases, irreversible commitments, and situations where the human bears the consequence if something goes wrong. A product purchase that ships to a physical address, a subscription that charges a credit card, a booking that locks a date: these are the actions where the authorization moment is not friction to be eliminated. It is the correct design.
The design requirements are correspondingly different. The agent must know how to surface the authorization request in a way the human can act on. It must present the material details (what is being bought, what it costs, what delivery option is selected) without burying them. And it must handle the case where the buyer declines. A declined authorization is a valid outcome, not an error to retry. It ends that branch of the workflow.
Choosing between them
The practical question is which pattern applies to a given purchase. Three factors determine it.
Value. A $0.01 API call is a fundamentally different risk profile from a high-value product purchase. The threshold where autonomous payment becomes uncomfortable is not universal, but it exists. For payments above that threshold, build in the authorization step.
Reversibility. An API call that returns a result the agent decides not to use carries no lasting consequence. A product order that ships carries consequences the buyer will live with. Irreversibility is a proxy for when human authorization is appropriate regardless of price.
Platform availability. As of today, Shopify-hosted merchants support structured agent checkout. Amazon does not. Other platforms will make their own choices. An agent shopping across platforms needs to know which ones support the structured path and fall back to a different approach (or no purchase) on the others. The distinction between platforms that offer structured agent APIs and platforms that block automated purchasing is a runtime environment check, not a design decision you make once.
Builders who conflate the two patterns end up with agents that either annoy users with confirmation dialogs for routine $0.01 calls or that charge credit cards without adequate notice. The patterns are different enough that each deserves its own code path. They share nothing except that both involve the agent spending money.