There’s an interesting proposal floating around called x402 that tries to solve something the web never really figured out: native payments.
HTTP has had a 402 Payment Required status code since the early days, but it was basically useless because payments were slow, expensive, and required user interaction. That’s changed.
The x402 idea in simple terms:
1.You request a paid resource (API call, data, inference, compute)
2.Server responds with HTTP 402 + “this costs X”
3.Client signs a payment authorization
4.Server verifies it and immediately returns the response
No accounts. No API keys. No subscriptions. No checkout flow.
From the client’s POV, it’s just another HTTP round trip.
Why this actually matters now:
- Micropayments finally work (stablecoins + cheap settlement)
- Pay-per-request APIs instead of SaaS lock-ins
- AI agents can pay autonomously without human approval
- Stateless pricing great for public APIs and open services
This feels especially relevant as more software stops being “apps” and starts being agents calling other agents. In that world, billing systems and monthly plans make zero sense.
Still early, obviously, but this is one of those ideas that clicks immediately once you see it:
👉 payments become infrastructure, not UX.
Here’s the blog that explains it well:
https://oasis.net/blog/x402-https-internet-native-payments
Top comments (2)
x402 is the future, what makes this more concrete is seeing it used with Oasis.
x402 is a clean abstraction, but pairing it with Oasis ROFL (confidential execution + attestation) is what makes it usable in practice, especially for agent-to-agent or server-to-server calls. You’re not just paying per request, you’re paying a service that can prove how it handled your data.
I don’t see this replacing traditional billing where relationships already exist, but for open, ad-hoc APIs and agent-driven infra, x402 + Oasis privacy primitives feels like a credible path, assuming settlement is amortized and not blocking per call.
This is a really clean mental model. Treating payments as part of the HTTP flow instead of a UX problem feels like the missing piece for APIs and agent-to-agent commerce. It also pairs naturally with verifiable compute and private execution, where something like Oasis ROFL can make sure the paid request was actually executed correctly, not just charged for. If agents are going to transact autonomously, this kind of infra-level payment primitive makes a lot of sense.