Software has been buying things on behalf of people for years, in the narrow sense that a subscription renews or a trading bot executes. What's new is software choosing what to buy. An AI assistant that can read a catalog, compare prices, and complete a purchase without a person clicking through the checkout is a different kind of customer, and it turns out the payment rails most of commerce runs on were built with assumptions that don't survive that shift.
We run a consumer catalog on the merchant side of this, so the rest of this post is what the problem looks like from that position.
A card transaction is built around a cardholder. Someone whose identity can be verified at the point of sale, who can be challenged with a second factor, who receives a statement, and who has standing to dispute a charge for up to several months afterward. Every one of those mechanisms exists because a human is assumed to be at the other end, capable of noticing a problem and complaining about it.
Point an autonomous agent at that system and the mechanisms start returning answers that don't mean anything. There's no browser session to fingerprint. A 3DS challenge has nobody to answer it. The chargeback framework assumes a disputant who can describe what went wrong, and an agent operating from a spend allowance can't play that role in any meaningful sense.
Here is what a human checkout relies on:
Identity: a cardholder verified at the point of sale
Authorization: a second factor, usually a prompt on a phone
Settlement: days, and reversible
Dispute: a chargeback window measured in months
Delivery: confirmed by the buyer noticing it arrived
And here is what an agent checkout relies on:
Identity: a wallet signature over the payment payload
Authorization: a spend ceiling set in advance, per resource
Settlement: seconds, and final
Dispute: whatever refund policy the merchant wrote down
Delivery: confirmed by a signed receipt
Read the second list on its own and the shape of the requirement becomes clear. An agent needs a rail where authorization is cryptographic, settlement is immediate, and the receipt is machine-verifiable. Stablecoins on cheap networks satisfy all three, which is most of why agent commerce has converged on them rather than on anything issued by a bank.
x402 revives an HTTP status code that has been sitting unused since the early web: 402, Payment Required. A server protecting a paid resource answers with 402 and a structured body naming the chain, asset, amount, recipient and an expiry. The client signs a payment payload, retries the request with that payload attached in a header, and the server returns both the resource and a signed settlement receipt.
The whole exchange fits in a page of documentation. What makes it work for agents is that no account exists anywhere in it. There's no signup, no stored credential, no relationship established in advance. An agent that has never encountered a merchant before can complete a purchase on first contact, because the payment carries its own proof.
Facilitators handle the on-chain part. Coinbase runs one, Stripe runs one on Base, and that means a merchant can accept x402 without operating a node.
The autonomous version gets the attention: an agent with a configured wallet and a spend ceiling, buying without asking. It works, and it's the right fit for machine-to-machine purchases like API access.
For consumer purchases the interesting mode is the one with a person still in it. An assistant queries the catalog, retrieves live prices in whatever coin the user holds, and presents the payment for confirmation. The user describes what they want in a sentence and approves once. That collapses a checkout that normally spans several browser tabs and a wallet app into a single exchange, and it does so without handing spending authority to software.
Most of the volume we see currently sits in that second mode, which tracks with how people generally adopt this kind of thing.
We were the first merchant to operate x402 across a consumer catalog, following infrastructure adopters like Cloudflare, Firecrawl and Pinata who came to it earlier for machine-to-machine use. Consumer products raise questions that API metering doesn't.
Delivery semantics turned out to be the deepest of them. A gift card is a code, so delivery is instantaneous and irreversible. An eSIM needs a carrier to provision a QR, which can fail after payment has already settled. A mobile top-up hits a carrier API that might time out or partially succeed. A flight is a booking against live airline inventory. On a rail that settles finally in one second, every one of those creates a different gap between paid and received, and each gap needs its own resolution path written down in advance.
We've published what we worked out at github.com/Cryptorefills/agentic-commerce, CC0 licensed, covering the reconciliation patterns, the refund policy engine and the delivery semantics question. Fork it rather than asking.
The claim worth testing over the next year is whether agent-initiated volume grows as a share of stablecoin payments generally. Right now the interesting number is small enough that anyone quoting it should be treated with suspicion, including us. The infrastructure arrived first, which is the usual order of events, and the useful question is which product categories agents turn out to be good at buying. Digital goods with low dispute rates are the obvious starting point. Whether it extends past that depends less on the protocol than on what happens the first time a few thousand agents get something wrong simultaneously.
