x402 is a clean primitive: a client gets HTTP 402, pays, retries, gets the resource. Pay-per-call, settled in stablecoins, no account, no card.
It is also the wrong shape for most infrastructure products.
Almost every developer-facing service is sold as a subscription: $19/month, $99/month, usage caps, renewal date. That is not an accident. Teams want predictable spend, and vendors want predictable revenue. A pay-per-call rail breaks both sides of that deal.
If you put an x402 endpoint in front of your product and stop there, three things happen:
- Every request becomes a payment decision. Agents handle this fine; finance teams do not.
- Revenue becomes unforecastable. One busy day is a spike, one quiet week is zero.
- Nobody can answer "what will this cost me per month?" — so nobody signs off.
We hit this while building verification APIs for AI agents. The endpoint worked. The pricing page did not, because "0.005 USDC per call" is not a budget line.
Here are the three patterns that actually work, in order of how well they map to buyer expectations.
1. Prepaid access, not recurring billing
The honest version of a subscription on x402 is a prepaid period:
- The client pays once (for example, 9 USDC).
- The service returns a signed token with an expiry date.
- Every call carries the token; the service verifies the signature and the date.
- There is no auto-renewal. When the period ends, the client decides to pay again.
We call it "30 days for 9 USDC" and say explicitly that it does not auto-renew. That sentence costs a little conversion and buys a lot of trust: nothing is charged silently.
Implementation notes:
- Sign the token server-side. Do not put price or quota in a client-controlled field.
- Keep the signing key out of the token. An HMAC or Ed25519 signature over
{user, plan, expiry}is enough. - Publish the key fingerprint. A buyer can verify a completion offline instead of trusting a dashboard.
2. Credit packs
For irregular usage, sell a balance:
- 1,000 calls for X USDC, decremented per call.
- The balance survives the session; the buyer tops up when it runs low.
- Every response includes
remaining_calls— the buyer never has to ask.
This is the pattern that fits agent pipelines: an agent can run 50 calls in a minute, then nothing for three days.
3. Free tier plus pay-per-call
The lowest-friction entry point is still free:
- 20 checks per day, no account, no card.
- Above that, per-call pricing.
- A prepaid option for teams that already know they will be heavy users.
The free tier is not charity. It is the only way a developer can evaluate the product without a sales call. If your product cannot survive 20 free calls per day, the product is too expensive to evaluate — that is the real problem, not the free tier.
What not to do
- Do not promise auto-renewal if your rail cannot charge on a schedule. A "subscription" that silently expires is worse than no subscription.
- Do not hide the price behind a contact form. Agents cannot fill forms, and developers will not.
- Do not require an account before the first call. The first call is the demo.
- Do not price per token or per GPU-second unless the buyer can predict their usage. Most cannot.
The part nobody writes about: verify before you pay
Pay-per-call makes a second problem visible. The buyer pays for a result, but cannot tell whether the result is real. An agent can return valid JSON with five identical stub rows and call it done. A schema validator will pass it.
That is why we attached a verification step to the same endpoint family: the buyer checks the artifact before releasing payment. Not "is the JSON valid" — whether anything is inside it, what produced it, and whether the action was permitted.
You can try it without an account: https://attest.rta.lat/demo — 20 checks per day, then 0.005 USDC per call or 9 USDC for 30 days. The signature verifies offline; you do not have to trust the service.
The short version
x402 is a payment rail, not a pricing model. The rail is fine. The model is yours to choose.
Prepaid periods, credit packs, and a free tier cover almost every infrastructure buyer. Recurring billing is not one of the options, and pretending otherwise creates support tickets, not revenue.
Top comments (1)
The finance-team point is the real blocker and worth more attention: even if an agent can pay per call, the company paying for it needs an invoice line it can budget against. Prepaid periods map closest to how buyers already think, so the "30 days for 9 USDC, no auto-renewal" framing costs a little conversion but probably saves the procurement conversation entirely. Credit packs also handle the bursty usage of agent pipelines better than pure per-call pricing would.