DEV Community: MPP TestKit

Machine-to-Machine Payments Are Coming Faster Than Anyone Prepared For

MPP TestKit — Wed, 06 May 2026 11:20:22 +0000

There is a quiet infrastructure crisis unfolding in AI development that nobody is talking about loudly enough.

AI agents are getting good - fast. They can write code, browse the web, book appointments, analyze data, and chain together complex multi-step workflows without human input. The tooling around them is evolving at a pace that would have seemed absurd three years ago.

But there is one thing they cannot do cleanly: pay for things.

Not because the technology doesn't exist. Because the payment infrastructure was never designed with machines in mind.

The Problem Nobody Built For

Every payment system we have today was designed for humans. Credit cards require billing addresses and CVV codes. PayPal requires a login flow. Stripe requires a server-side integration with API keys, webhook endpoints, and a merchant account that takes days to verify.

When a human wants to pay for something, these friction points are annoying but manageable. When an autonomous AI agent needs to pay for a single API call - at 2 AM, without a human in the loop - the entire stack collapses.

The agent needs to:

Hold credentials it can use programmatically
Initiate a payment without a UI flow
Receive instant confirmation
Retry the original request automatically

None of the existing payment rails were built for this sequence. They were built for checkout pages.

HTTP 402 Has Been Waiting Since 1999

Here is the part that makes this problem both frustrating and exciting: the HTTP spec saw this coming.

In 1999, when the HTTP/1.1 specification was published, the authors included status code 402 - Payment Required. The note in the RFC reads:

"This code is reserved for future use."

Twenty-five years later, it is still reserved. No major implementation. No standard. No tooling.

The reason is straightforward: in 1999, there was no programmable money. No way for a server to say "send me exactly $0.003 and I'll give you the data" and have a machine comply without a human typing in a card number.

That changed with blockchain. Specifically, it changed with Solana.

Why Solana Is the Right Layer for This

Not all blockchains are equal for this use case. Machine-to-machine payments at the API layer have strict requirements:

Speed. An API client waiting on payment confirmation cannot wait 10 minutes. Solana finalizes transactions in 400–800 milliseconds. That is fast enough to fit inside a single HTTP request-response cycle.

Cost. Paying $15 in gas fees to access a $0.001 API endpoint is absurd. Solana transaction fees are fractions of a cent - typically $0.00025 or less.

Programmability. The payment needs to be verifiable on-chain without a trusted third party. Solana's account model makes it straightforward to confirm a transfer happened, to whom, and for exactly how much.

Developer tooling. Solana has a mature JavaScript/TypeScript SDK, widespread RPC access, and faucets on devnet and testnet that make testing free and instant.

No other chain checks all four boxes at the level of maturity Solana does today.

The 402 Flow, Concretely

Here is what the machine-to-machine payment protocol looks like when properly implemented:

1. Client → GET /api/data
2. Server → 402 Payment Required
           Payment-Request: solana; amount="0.001"; recipient="9WzDX..."; network="devnet"
3. Client → builds and signs a Solana transaction
           sends 0.001 SOL to the recipient address
4. Client → GET /api/data
           Payment-Receipt: solana; signature="3xKm7..."; network="devnet"
5. Server → verifies the transaction on-chain
           confirms correct recipient and amount
6. Server → 200 OK + data

No human. No UI. No stored credentials that can be stolen. No subscription to manage.

The agent generates an ephemeral keypair per session, gets funded from a faucet (on test networks) or a pre-loaded wallet (on mainnet), makes the payment, and moves on.

Who Builds This Infrastructure First, Wins

We are in a narrow window. AI agents are proliferating. The companies building them are running into the payment problem right now - and solving it badly, with workarounds like pre-purchased credit bundles, API key sharing, and centralized billing dashboards.

These are fine stopgaps. They are not the endgame.

The endgame is a world where any API can declare its price in a Payment-Request header, any agent can pay it atomically, and the entire interaction is settled on-chain without a third party in the middle.

That world creates:

A long tail of micro-API businesses that are uneconomical today because per-user billing infrastructure costs more than the service itself
Agent-native services that don't bother with human-facing dashboards because they only serve machines
Composable payment flows where one agent pays another, which pays a third, all within a single user-initiated task

The infrastructure for this needs to be built now, while the norms are still forming. Whoever defines the standard shapes how the next decade of API economics works.

What We're Building

MPP Test Kit is our contribution to this problem. It is an open-source SDK that makes testing the 402 payment flow trivial - for both sides of the transaction.

On the client side:

import { mppFetch } from "mpp-test-sdk";

// No wallet setup. No config. One line.
const res = await mppFetch("https://api.example.com/data");
const data = await res.json();

The SDK generates a Solana keypair, airdrops SOL from the devnet/testnet faucet, handles the 402 response, executes the payment, and retries the request - all automatically.

On the server side:

import { createTestServer } from "mpp-test-sdk";

const mpp = createTestServer();

app.get("/api/data",
  mpp.charge({ amount: "0.001" }),
  (req, res) => {
    res.json({ data: "premium content" });
  }
);

One middleware line. The server auto-generates its recipient wallet, returns 402 with the payment details, and verifies the Solana transaction on-chain before serving the response.

The goal is to make the 402 flow so easy to test that developers start building against it - and in doing so, establish what the real-world implementation of machine-to-machine payments looks like.

The Stakes

This is not a niche developer tool story. This is an infrastructure story.

The internet runs on HTTP. HTTP has a status code explicitly reserved for payments. Solana has the performance characteristics to make that status code real. AI agents have the economic incentive to use it.

The pieces are all here. What has been missing is the tooling that makes it easy to build and test.

We are building that tooling. But more than that, we are trying to establish a pattern - a shared understanding of how machines should pay each other - before that pattern gets defined by a centralized intermediary who extracts a fee from every transaction.

The window is open. It will not stay open forever.

MPP Test Kit is open source. Try the playground at mpptestkit.com or install the SDK: npm i mpp-test-sdk

Pay-Per-Request APIs Are the Next Primitive of the Internet

MPP TestKit — Wed, 06 May 2026 11:17:43 +0000

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