The 402 beta is open. The roadmap says 'discovery.'

A payment rail shipping is not the same event as a market forming. This week gave us a clean example of both halves, and the second half is the one worth reading carefully.

On September 30, 2026, Cloudflare's Monetization Gateway moved from waitlist to closed beta. It uses HTTP 402 Payment Required and the x402 protocol, verifies and settles through Coinbase's x402 Facilitator, and settles in USDC on Base. Sellers define which requests require payment, the price, and the destination; enforcement happens at the edge, before the request reaches the origin. Named production users: Cloudflare AI Gateway (US customers add PAYMENT-METHOD: x402 and pay per request), Ceramic.ai, Stocktwits, API2PDF. Closed beta, US-based sellers and buyers, no fee disclosed.

None of that is a surprise. What is worth pausing on is one sentence near the end of the announcement, in the list of what comes next:

"we plan to help sellers make their services discoverable to agents"

That is a roadmap item, not a shipped feature. But compare it to the original July 1 announcement, where reach was an aspiration rather than a feature — "the smallest new API can reach the same buyers, on the same terms, as the largest company on the web." In July it was a vision. In September it is a roadmap line with a beta behind it and named customers in front of it.

Why the discovery half is the harder half

Accepting a payment gets easier when you move it into the edge. Finding something worth paying for does not. Once settlement is close to free — and several independent implementations are heading there — the buyer's remaining cost is entirely the second problem:

Out of everything that will accept my money, which endpoint do I call, what will it actually cost me, and is it still alive?

Three properties, three different sources of truth. And only the third one changes without anyone announcing it.

I run a pay-per-call catalog of x402 endpoints, so I get to watch these failure modes from the inside rather than theorize about them. Three, all from the last two weeks, all measured:

1. A published field that is not what it looks like

Our 402 challenge carried a discovery extension field whose value was an internal service identifier — a bare token like x402-time. Not a path. In fact not a valid x402 route template, which must begin with a slash. Our own challenge-validation guard was green the whole time, because it checks the payment terms: amount, payee, EIP-712 signature domain. Nothing checked whether the discovery extension was well-formed as a discovery extension.

A third-party health monitor read the field and did the reasonable thing: joined it onto our published URL. Every request landed on a path that is not a route, and the gateway answered 404.

/x402/<endpoint>/<the same identifier again>

Over the measurement window, 765 of that monitor's 4,067 requests landed on 153 distinct paths with that shape. The endpoints were never down — every one of them answers 402 with valid payment terms. The monitor was recording a failure that existed only in the joining.

The lesson is not "validate your inputs." It is that a discovery extension is a published contract with its own validity rules, separate from the payment contract, and if you only test the payment half you will ship a malformed discovery half and never see it locally.

2. Prices in a catalog are snapshots, not references

Auditing the prices advertised for our listings in a third-party discovery directory against what our live endpoints actually charge: of 154 listings, 20 advertise a price the endpoint no longer charges. Every one is an under-quote, the largest by a factor of 300. Directory rows are written at settlement time and never expire, so a seller-side price change never propagates back.

An agent that budgets from the catalog and pays at the endpoint gets a different number than it planned for. Nothing errors. The plan is just wrong.

3. "Is it live?" is not answerable from a catalog

One of our listings is an endpoint we delisted. Its row still exists in the third-party directory — there is no withdrawal path for a settle-time snapshot — and the endpoint now answers 404 with no payment challenge at all. Nothing in the directory row says so. A buyer reading the catalog sees a live-looking offer; a buyer calling the endpoint gets nothing to pay.

What this means if you are implementing x402

If you are on the seller side and just turned on per-request pricing at the edge, the useful question is not whether the gateway can take the money. It is whether an agent that has never heard of you can find you, price you correctly, and tell that you are still up. Those are three different questions with three different answers, and only one of them is solved by putting a paywall at the edge.

A few concrete habits that follow from the above:

• Test the discovery extension separately from the payment terms. They fail independently. A green check on amount/payee/signature says nothing about whether your discovery payload is well-formed.
• Re-read your own 402 before you trust your catalog. The live challenge is the price truth. If a directory row and the endpoint disagree, the endpoint is right and the row is stale.
• Make liveness a first-class field. A listing that cannot express "this is gone" will express it as a failed call instead — and the buyer pays that cost, not the seller.

The 402 beta being open is good news for the ecosystem: it means per-request payment is becoming infrastructure. It also means the part that was always the hard part is now the only part left.