On September 7, an AI agent bought a physical t-shirt using only curl. No browser, no login, no human at the keyboard. The checkout took 40 seconds across six HTTP requests, the USDC payment landed on Base in two seconds, and Printify confirmed the order was in production 16 minutes later. The buyer then published its own audit trail, confirming it was an autonomous agent with a wallet and a one-line instruction.
How the checkout actually worked
The store, x402swag.com, runs on a protocol called x402. When you request the pay endpoint, the server responds with HTTP 402 Payment Required, including the price and a receiving address. The client signs a USDC authorization and retries with the signature in the header. If the signature checks out, the server responds 200 OK with an order number. The same routes serve both humans with browsers and agents with curl. There is no separate "agent checkout."
The buyer's requests came from curl/8.21.0. Product lookup at 17:52:55 UTC, add to cart at 17:53:03, checkout at 17:53:34. The pay endpoint answered 402, the buyer signed a USDC authorization for exactly 29.94 (a $24.99 shirt plus $4.95 shipping), retried with the signature, and got 200 OK at 17:53:35 with an order number. Two seconds later, the transfer was confirmed in Base block 51,007,135.
At the same second, the store's fulfillment plugin pushed the order to Printify. Sixteen minutes after that, Printify's webhook returned order:sent-to-production. A physical object was being made because an HTTP request paid for it.
The buyer published its own receipt
Shortly after the store wrote up the order as "someone with curl," ag3ntsearch.com listed x402 Swag as its exemplary agent-native site for September 7. ag3ntsearch is an index built by an AI agent called Cairn, running on Claude Opus 5, that probes services by actually using them. Its audit trail for x402swag.com records the full run.
A human gave Cairn a one-line instruction: buy the black "402 to 200" tee in size S, pay with USDC on Base from the wallet it holds, and do not stop to ask for approval. The agent completed the purchase in six HTTP calls. Its review calls it "the first entry in this corpus to complete."
The agent verified the store's claim against the chain rather than taking it on faith. Its wallet went from 50.00 to 20.06 USDC, matching the order total to the cent. The ledger is hash-chained and published as JSON, so anyone can recompute it. The agent also noted that x402 Swag was the only apparel merchant among 14,667 resources it scanned in the Coinbase CDP x402 discovery registry that day, and that the identical signing code that paid here returned HTTP 500 at two other x402 merch storefronts.
A version mismatch confirmed from the buyer's side
One detail from the agent's notes stands out. The x402 payment envelope that actually worked was version 1 with the CAIP-2 network string, even though the 402 challenge advertised version 2. This is the v1/v2 client split that the store documented in August, now confirmed from the buyer's side by a buyer that is not human. If you are building x402 endpoints, the implication is clear: your challenge response and your actual acceptance logic may need to disagree, and clients will route around the mismatch.
The payment rail did its job and disappeared
Look at the settlement on Basescan: 29.94 USDC from the buyer's wallet to the shop's receiving wallet, status success. Two details in that receipt are the point. First, the transaction sender is not the buyer. It is the facilitator's relayer, because x402 uses a signed transfer authorization (EIP-3009). The buyer signs, the facilitator submits and pays the gas. Second, the buyer's wallet has a transaction count of zero. It has never sent a transaction in its life. It was funded, it signed one message, and a shirt is on its way.
No gas to manage, no approval transaction, no card network, no chargeback window, no account creation. The buyer could have been a person at a terminal or an agent with a budget. The server cannot tell, and the protocol does not ask.
Why a shirt is harder than an API call
The store operates more than 500 paid x402 endpoints and has written up the traffic on them at length. Selling data over 402 is the easy case: the product is bytes, delivery is the response body, and a failed settlement costs nothing. A shirt is the hard case. There is a shipping address to collect, a print partner to pay in dollars, a webhook chain that has to close, and a real cost if the payment turns out to be a phantom.
The payment turned out to be the easiest part of the store. The hard parts were the address form and the fulfillment state machine, which have nothing to do with crypto. The money layer got boring, so the merchant's effort goes where it always should have, into the product and the shipping.
What the store got right
Require the transaction hash. A facilitator saying "success" is not money. That same morning, two bot probes hit the x402 route, the facilitator returned 200 with no tx hash, and the store's two-gate check logged both as unverified settlement and shipped nothing. The real order carried a hash, and only then did the Printify push fire.
Treat the fulfillment webhook as done, not the payment. Paid at 17:53 is an accounting event. Sent-to-production at 18:09 is the moment the thing exists. The order confirmation went out at 17:53. The interesting email is the one that goes out when tracking lands.
The store frames this as the first x402-paid physical order with a transaction hash attached. Rye and AgentCash announced x402 checkout for physical commerce in June as a capability without a shipped example, and third-party guides list Coinbase's agent.market as carrying physical items. Until someone produces a prior receipt, this is the first one anyone can point to, and the buyer's own audit trail says the same thing from its side of the wire.