The problem, in store terms
All of your current checkout assumes a person: someone opens the page, types a card, gets a code on their phone, presses a button. When the buyer is a program, that path breaks at step one. There is no phone, no card in the agent's name, and handing a program its owner's card is an idea nobody wants to defend in front of a bank.
x402 answers that with something far older than artificial intelligence: the HTTP
status code 402 Payment Required, reserved in the web
specification and never used. The idea is literal. Your server answers "this costs
that much", and a client who wants to continue pays and asks again.
What it looks like, without jargon
- The agent asks for your quoted cart.
-
Your store answers
402with the terms: how much, in which currency, to which address. - The agent signs the payment with its owner's key, on its owner's computer, and repeats the request carrying that signature.
- Your store checks and settles the payment, and only then creates the order, with the transaction record attached.
There is no account to open, no subscription between the parties, no prior agreement. It is as anonymous or as identified as you want: you can require the agent to sign its requests and bring an attestation from its owner, or you can sell to whoever arrives, as your store does today.
The three things a merchant cares about
First, the money is yours from second zero. The payment goes from the buyer to your wallet inside a single transaction. It does not pass through an intermediate account, ours or anyone's. There is no balance to withdraw and no release period, because there was no custody.
Second, settlement is the condition, not the promise. With cards, the order is created on an authorisation, the money arrives later, and a chargeback is possible weeks after. Here the order is reversed: first the payment settles on the network, then the order exists. That is a hard rule in our code, not a setting.
Third, it replaces nothing. Your checkout, your card gateway, your transfers and your human customers stay intact. Agent orders land in the same order list of your store, already paid and marked so you can tell them apart.
What USDC is, in one line
A dollar stablecoin: one USDC is meant to be worth one US dollar. If your catalog is in dollars, the USDC price is one to one and you confirm it. If it is in another currency, you set the price, because only you know the exchange rate you want to sell at. No price is ever published to an agent without a human confirming it.
What is worth asking first
- Who pays the network fees. In this scheme the facilitator sponsors them, which means whoever runs that service pays. On a real transaction of ours, that fee was 0.0023 XLM. The point is not the amount: it is knowing whose account it is.
- What happens if the payment does not match. In our implementation, a payment that does not match the quote leaves the order under review and nothing is fulfilled. Silence never approves.
- Tax and invoicing. It is an ordinary paid order in your system, with its amount and its transaction record, and your usual tax process applies the same way. What treatment a stablecoin payment deserves is a question for your accountant, not for us.
Why now
Because agents are already buying. Whether they do it well or badly depends on there being formats merchants can adopt without giving up control: without handing over custody, without paying a percentage of every sale and without entering someone else's marketplace. x402 is the payment piece. The catalog, the selling rules, human approval and the receipt are the others, and the rest of this blog is about them.