How to accept x402 payments: one endpoint, one price

The smallest deployment that actually works

One endpoint. One price. One facilitator. Resist adding anything to that until you have watched a settlement land.

The protocol charges no fee of its own: payers cover network fees only (x402.org). The facilitator does the verification and settlement work. Coinbase's seller documentation states that the CDP facilitator verifies and settles payments on Base and Solana, and that CDP has processed more than 100 million x402 payments (Coinbase Developer Platform, docs.cdp.coinbase.com). There is a longer piece on this blog about what an x402 facilitator is, and do you need one? if you are choosing between running your own and paying someone else's.

The code path is short. Your route returns HTTP 402 carrying a PaymentRequirements object when a request arrives unpaid. The client builds a PaymentPayload against those requirements. The facilitator verifies, then settles. Start with the exact scheme, which transfers a specific amount (Coinbase, x402 Foundation, github.com/coinbase/x402). Reference SDKs and middleware exist for TypeScript, Python and Go, so the smallest working deployment is usually a middleware line in front of a route you already run.

Pick one route. Pick one asset. Make sure you can read the whole payment path in one sitting, because every failure mode below lives in the gap between those two objects.

Pick the unit before you pick the number

Per-call pricing is usually the wrong unit.

CoinDesk, citing Artemis, reports around $28,000 of real daily x402 volume and an average payment of around $0.20 against roughly 131,000 daily transactions (CoinDesk). That average is low because much of the traffic is probing, discovery and retries rather than purchase. Charge per HTTP call and you also charge for retries, and your buyer has to model your retry behaviour before they can budget.

The value that moves sits at the other end of the distribution. Chainalysis reports that payments of $1 or more rose from 49% of value in early 2025 to 95% by early 2026 (Chainalysis). Buyers are consolidating into fewer, larger payments, which is what you would expect from agents doing paid work rather than scraping.

So price a unit of work: a document, a 1,000-token inference call, a dataset slice, a day of crawl access. Price stays tied to the thing the buyer values, retries stop mattering, and you can change the number without changing the integration.

Before you publish a price, answer two questions. What does the buyer receive? What happens when they receive nothing after paying?

What breaks in production

Settlement fails after verification passes

Verification and settlement are separate steps. Verification passing tells you the payload is well formed, not that money moved. Log the facilitator's settle response and the settlement transaction hash against the request. When a buyer says they paid and got nothing, that pair is the difference between a refund and an argument.

The quote goes stale

Whatever validity window you set in your PaymentRequirements, agents do not pay instantly. An agent that fetched your 402 at 09:00 may submit at 09:20. Log the issue time and the window you set. If a payload arrives outside it, return a fresh 402 at the current price rather than honouring the old one. You cannot tell a slow agent from a replay by looking at the payment alone.

The same payload gets served twice

A signed payment authorisation behaves like a bearer instrument until it settles. Two concurrent requests carrying the same payload can both pass verification before either settles. Hash the PaymentPayload and use that hash as a unique key in your store before you do any work. First writer wins. The second caller gets a conflict response.

You serve before settlement confirms

Decide this deliberately and write it down. Serving on verification accepts the risk that settlement later reverts. Waiting for settlement adds latency your buyer will notice. Either way, log the two events separately, because a single "payment ok" flag cannot tell you which of them your system actually did.

The 402 body changes shape

Agents cache what they parse. If your PaymentRequirements fields move between deploys, clients holding a cached schema break in ways your own logs will not show. Version the body. Keep field names stable.

What to log from day one

None of this is exotic. It is the field set you would log for any payment integration, and it is the field set most x402 write-ups skip.

Make it findable once it works

Discovery is a separate job from settlement. The x402 Bazaar is the machine-readable discovery layer: sellers list an endpoint with its schema, price and description, and agents find services programmatically (Coinbase Developer Platform, x402 Bazaar). One practical note: that page returns 403 to scripted agents, so a human fetches it, not your bot.

Standardisation is arriving behind the protocol. The Linux Foundation announced the operational launch of the x402 Foundation on 14 July 2026, with 40 member organisations and 17 premier members including Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, MoonPay, Ripple, Shopify, Stripe and Visa (The Linux Foundation). That matters for procurement more than for code. When a buyer's compliance team asks who stands behind the protocol, there is now a list to point at.

What nobody can tell you yet

Whether anyone will pay you.

TRM Labs measured roughly $52.7M settled across 198.9 million x402 settlements on Base, Solana and Polygon since May 2025, screening down to $25.62M of plausible commerce, of which 0.6% to 7.5% appears agentic. $52.47M of the $52.68M total, or 99.6%, settled in USDC (TRM Labs). BlockEden.xyz reports daily x402 transactions fell from about 731,000 in December 2025 to about 57,000 in February 2026, a decline of over 92% (BlockEden.xyz).

Read those together and the honest conclusion is that the rail works while demand stays thin and uneven. Build the endpoint because your agents or your buyers are already asking for it. Instrument it so you can tell the difference between nobody wanting this and nobody finding this. The table above is the whole answer to that question.

If your problem is that AI systems describe your product badly rather than that they cannot pay for it, that is a different measurement problem. There is answer engine optimisation, defined and the free AI visibility audit for that side, and what AI recommends instead if you want to see how answer engines pick favourites in a category.