How an agent buys from a WooCommerce store, step by step

The store we are talking about

demo.agentposhq.com is an ordinary WooCommerce store, with its theme, its pages and its permalinks, running on a server of ours. We operate it as the official demo and it is labelled as such. It sells digital products that we actually deliver. The only difference is that a second process runs next to it, the AgentPOS sidecar, which publishes the catalog in the formats an agent understands and takes the payments.

The merchant did not change checkout, did not change payment gateway and did not stop selling to people. What they gained is a second door.

1. The agent discovers the store

The agent does not need private documentation from us. It starts from the domain and reads what is published: the site's openapi.json, the UCP manifest at /.well-known/ucp and the catalog at /agentpos/catalog. That is where the products the merchant confirmed live, with their description, their attributes and their price in USDC. The ones they did not confirm are not there, and keep selling to humans as always.

There is also an MCP server at /agentpos/mcp exposing search_items, get_item, create_cart and get_order, for agents that speak that protocol rather than plain HTTP.

2. It asks for a quote

With the items chosen, the agent does a POST to /agentpos/cart with the items, the buyer details and shipping if it applies. The store answers with the quoted cart: what each line costs, what the total costs and which address is to be paid. That quote is the reference the payment will later be compared against.

3. The store asks for payment with a 402

The agent does a POST to /agentpos/checkout?cart=<id> and gets back a 402 Payment Required carrying the payment terms in the PAYMENT-REQUIRED header: the network, the asset, the amount in minor units and the seller's address. This is x402, and it is why none of this needs a prior account or a stored card: the store quotes, and whoever wants to pay, pays.

4. The buyer authorises, not the store

The agent builds the USDC transfer and signs it with its owner's key, on its owner's machine. Before that it passes through its own mandate: the limits the buyer defined. On our first mainnet purchase, on 2 September 2026, the agent's first attempt was for 6 USDC and the mandate blocked it, because its per-payment cap was 3 USDC. The second attempt, within the limit, went through. The control worked in production, not in a test.

The signed transaction goes back to the store in the PAYMENT-SIGNATURE header.

5. Verify, settle, and only then create the order

The store hands the signed transaction to the facilitator, which first verifies it and then settles it on the network. This is where the rule we care about most lives: no order is created without a settled payment. Not on a favourable verification, not on a promise: on settlement done and the hash in hand.

With settlement confirmed, the connector creates the order in WooCommerce, already paid, with payment_method = agentpos and the transaction hash in transaction_id. Creation is idempotent by hash, so a retry never produces two orders.

6. The receipt

Besides the order, the store signs a receipt and chains it to the previous one. The buyer gets it at /agentpos/orders/<id>/receipt and verifies it with SHA-256 and Ed25519, without calling any API of ours. That is the subject of another article.

The proof

On 4 September 2026 the reference agent made this whole trip from another machine and over the internet, with no prior configuration: it discovered the store through its openapi.json, quoted, paid 1 USDC under a human mandate, and the order appeared in WooCommerce with its signed receipt. The transaction featured on the home page is a later sale, one where a buyer's personalisation reached the merchant's order intact:

2e21e44dba74618d8f9a865a313ffa28d6a78c26fe898b2616f40eff6def1098

Any agent in the world can repeat it today against the same store. That, and not a number of ours, is what makes the rest verifiable.