Every major shift in how software is sold follows the same arc.
Packaged software gave way to SaaS. SaaS gave way to usage-based billing. Usage-based billing is now giving way to something most developers haven't named yet - but it is already visible in the infrastructure being built around AI agents and autonomous systems.
The name, when it comes, will probably just be pay-per-request.
What's Wrong With Subscriptions
Subscriptions are not natural. They are a workaround.
The natural model for an API is: you call it, you pay for what you used, you stop paying when you stop calling it. Like electricity, water, or compute time on a cloud provider.
The reason APIs don't work this way is a payment infrastructure problem, not a product design problem. Per-request payments require:
- Instant settlement (no 3-day card processing window)
- Near-zero transaction cost (paying $0.30 Stripe fee on a $0.001 API call is absurd)
- No account creation required on either side
- Machine-readable payment confirmation
None of the legacy payment rails support all four. So the industry invented subscriptions - a bulk pre-purchase that amortizes transaction overhead across many calls.
Subscriptions work well for humans who plan their usage in advance. They work terribly for machines that call APIs sporadically, unpredictably, and at scale.
The API Economy Has a Composition Problem
Here is a concrete version of the problem.
Imagine building an AI research agent. It needs to:
- Call a semantic search API (5 cents per query)
- Call a web scraping API (2 cents per page)
- Call a summarization API (1 cent per 1,000 tokens)
- Call a fact-checking API (3 cents per claim)
To use all four today, you need four accounts, four API keys, four separate billing relationships, four different rate limit tiers to reason about, and four monthly invoices to reconcile.
This is not a scalability problem. It is a compositional friction problem. The more services an agent needs to call, the worse it gets.
Pay-per-request eliminates this entirely. The agent holds a single funded wallet. Every API call that costs money just costs money - atomically, on-chain, without prior registration.
HTTP 402 Is the Missing Standard
In 1999, the HTTP specification reserved status code 402 - Payment Required for future use.
The spec authors were not being naive. They correctly anticipated that some HTTP resources would need to be paid for. What they could not anticipate was the 25-year gap before programmable money existed at the performance level required to make it work.
That gap is now closed.
A properly implemented 402 flow looks like this:
Client: GET /api/research-data
Server: 402 Payment Required
Payment-Request: solana; amount="0.005"; recipient="7xKp..."; network="devnet"
Client: [generates keypair, sends 0.005 SOL on Solana]
Client: GET /api/research-data
Payment-Receipt: solana; signature="4mNw..."; network="devnet"
Server: [verifies transaction on-chain]
Server: 200 OK + data
No accounts. No API keys for billing. No subscriptions. The payment IS the authentication. The blockchain IS the receipt.
Why This Is a Primitive, Not a Feature
The word "primitive" in computing refers to a foundational building block - something other things are built on top of, rather than something built on top of other things.
TCP/IP is a primitive. HTTP is a primitive. JSON is (informally) a primitive.
Pay-per-request APIs, when implemented via HTTP 402 with on-chain settlement, have the properties of a primitive:
Composable. Any agent, in any language, on any platform, can participate. The protocol is defined at the HTTP layer - nothing above it needs to change.
Permissionless. An API server can start charging per-request without registering with any payment processor. A client can start paying without creating an account. The blockchain handles settlement.
Verifiable. Payment proofs are public and immutable. Both sides can independently verify that a transaction happened, when, for how much, and to whom. There is no "trust the payment processor."
Atomic. Payment and data delivery are coupled. Either the payment goes through and the data is returned, or neither happens. No disputed charges. No refund processes.
These four properties - composability, permissionlessness, verifiability, atomicity - are what make something a primitive. They are also exactly what existing payment rails lack.
The Solana Advantage
Pay-per-request only works if the payment layer is fast enough to fit inside an API call and cheap enough to be economically rational at small amounts.
Solana is currently the only public blockchain that meets both requirements in production:
| Property | Solana | Ethereum L1 | Bitcoin |
|---|---|---|---|
| Finality | ~800ms | ~12 seconds | ~60 minutes |
| Tx fee | ~$0.00025 | ~$1–50+ | ~$1–5+ |
| TPS | 65,000+ | ~15 | ~7 |
The numbers are not close. A Solana transaction settles in under a second for a quarter of a cent. That is the only option that makes paying $0.001 for an API call economically rational - Ethereum L1 gas fees would cost 10,000x the payment itself.
Solana also has:
- First-class JavaScript/TypeScript SDK (
@solana/web3.js) - Free devnet and testnet faucets for development
- Widespread RPC infrastructure with low latency globally
- A mature ecosystem of wallets and tooling
This matters for developer adoption. The easier it is to test and build, the faster the pattern spreads.
What the Ecosystem Looks Like at Scale
Imagine a world where pay-per-request is a standard pattern, not an exotic experiment.
For API providers: Zero billing infrastructure. No Stripe integration, no subscription tiers, no dunning emails, no churn analysis. Set a price per request in a header and start earning.
For developers: Access any API with a single funded wallet. No account creation, no trial limitations, no credit card required. Call it, pay for it, move on.
For AI agents: Fully autonomous operation. An agent can access any pay-per-request API in the world without human intervention - no approval flows, no credential management, no budget alerts.
For the long tail: APIs that are uneconomical today because the billing overhead exceeds the value per call become viable. A highly specialized data endpoint that serves 50 requests a day at $0.05 each can now exist as a business.
This is not incremental. It is a different model for how API services work.
Building the Tooling First
The pattern will not spread without tooling. No developer integrates a protocol that requires them to write 200 lines of wallet management code before their first test.
That is what MPP Test Kit addresses.
For clients testing a 402-enabled API:
import { mppFetch } from "mpp-test-sdk";
const res = await mppFetch("https://api.example.com/query");
const data = await res.json();
// SDK handled the entire 402 → pay → retry cycle automatically
For servers exposing a paid endpoint:
import express from "express";
import { createTestServer } from "mpp-test-sdk";
const app = express();
const mpp = createTestServer();
app.get("/api/query",
mpp.charge({ amount: "0.001" }),
(req, res) => {
res.json({ result: "data" });
}
);
Both sides work on devnet (free), testnet (free), and mainnet (real SOL). The SDK generates wallets, handles faucet airdrops, verifies transactions on-chain, and surfaces the full payment lifecycle through observable events.
The goal is zero-friction testing. If the integration is easy to test, it becomes easy to ship. If it becomes easy to ship, it becomes a standard.
First Mover Dynamics
Standards coalesce around implementations. The team that makes HTTP 402 easy to use will have outsized influence on how the standard evolves.
This is not theoretical. JSON won over XML partly because of better tooling. REST won over SOAP for the same reason. npm won because it was simpler to publish and consume than what came before.
Pay-per-request APIs need a moment like that - a tooling layer that makes the right way easier than the wrong way. When that exists, developers start building against it. When developers build against it, APIs start implementing it. When APIs implement it, agents start relying on it.
The flywheel starts with tooling.
Where This Goes
The trajectory is clear even if the timeline is uncertain.
AI agents will proliferate. They will need to pay for services. The services they pay for will need a standard way to declare their prices and verify payment. HTTP 402 with on-chain settlement is that standard.
The developers building this infrastructure now - the SDK authors, the API providers experimenting with 402, the protocol researchers documenting the patterns - are defining the economic layer of the agentic internet.
Pay-per-request is not a startup idea. It is a primitive. And primitives, once established, become load-bearing infrastructure for everything built on top.
The window to define it is now. After that, we just use it.
MPP Test Kit is open source. Try the live playground at mpptestkit.com or get started in seconds: npm i mpp-test-sdk
Top comments (0)