Forem: MPP TestKit

The Infrastructure Gap: Why the Machine Economy Is Stalling and How We Fix It

MPP TestKit — Mon, 11 May 2026 14:45:47 +0000

Autonomous AI agents are no longer some far-away prediction.

They are already here.

They are making API calls, processing massive datasets, interacting with tools, executing complex workflows, and operating without a human sitting behind every click.

But while agentic activity is exploding, there is still one massive infrastructure gap that almost nobody is solving properly.

The question is no longer:

Can agents perform work?

The real question is:

How do agents pay for the services they consume?

Right now, the answer is messy.

We are trying to force autonomous machines into a financial system built for humans.

We ask agents to deal with credit cards, checkout pages, monthly SaaS plans, account creation, user databases, billing dashboards, and subscription logic.

That is not machine-native infrastructure.

That is duct tape.

And duct tape does not scale the machine economy.

The Problem Nobody Wants to Build Around

If you are an API provider today, you are standing at a very uncomfortable crossroads.

You know agents are going to become one of the biggest consumers of APIs.

But you probably do not want to build an entire billing department just to serve them.

You do not want to manage thousands of bot accounts.

You do not want to build custom payment verification logic from scratch.

You do not want to create subscription tiers for machines that may only need your endpoint for five seconds.

And you definitely do not want to spend months engineering a system that may become obsolete before it even ships.

That uncertainty is slowing the market down.

API providers are waiting.

Agent developers are hacking around the problem.

And the machine economy is being starved of the premium data, compute, and services it needs to scale.

We decided to fix that.

What MPP TestKit Actually Is

MPP TestKit is the developer infrastructure layer between autonomous agents and API endpoints.

It is not just another payment tool.

It is not a checkout page.

It is not a dashboard pretending to be infrastructure.

MPP TestKit is the payment rail for machine-to-machine commerce.

Think about what Cloudflare did for web infrastructure.

Before Cloudflare, website operators had to manually configure DDoS protection, SSL certificates, CDN caching, DNS routing, and performance optimization.

It was expensive, fragile, and deeply technical.

Cloudflare turned that complexity into an invisible layer.

You pointed your traffic through it, and the hard stuff just worked.

MPP TestKit does something similar for agentic commerce.

API providers do not need to become blockchain settlement experts.

They do not need to write custom verification logic.

They do not need to maintain bot user accounts.

They do not need to build billing systems from scratch.

They list their service, wrap their endpoint with middleware, and let the HTTP 402 payment flow handle the rest.

The provider keeps building the actual product.

Revenue flows directly to their wallet.

Agents get machine-native access.

And the API economy finally gets rails built for machines.

The Problem With Human-Centric Billing

Legacy billing is built for people.

That sounds obvious, but it matters.

Most billing systems assume there is a human on the other side.

A human can create an account.

A human can enter an email.

A human can pick a subscription plan.

A human can click through Stripe.

A human can manage invoices.

Agents do not work like that.

Autonomous systems need fast, stateless, programmable access.

The existing system breaks down in three major ways.

1. Identity Overload

Every service wants an email, password, user profile, billing address, and sometimes even KYC.

That makes sense for humans.

It makes no sense for autonomous agents.

Agents do not need traditional identities.

They need task-based access.

They need to request a resource, pay for it, receive it, and move on.

2. Stateful Subscriptions

Monthly SaaS billing is a human pattern.

A human may use a tool every day, so charging $20/month makes sense.

But an agent may spin up, make 500 requests in ten seconds, complete its task, and disappear.

A subscription model is completely misaligned with that behavior.

The machine economy needs usage-based access at the request level.

Not bloated monthly plans.

Not seats.

Not dashboards.

Just pay, access, execute.

3. Friction-Heavy Settlement

Credit card systems were designed to detect suspicious automated behavior.

But in the machine economy, every request is automated behavior.

That creates a fundamental mismatch.

The very thing machines are supposed to do at scale is the thing legacy payment systems are trained to slow down or block.

The solution is not to slightly improve human billing.

The solution is to move to stateless, machine-native access.

HTTP 402: The Only Logical Standard

At the heart of MPP TestKit is the x402 flow.

HTTP 402, also known as Payment Required, has existed in the HTTP standard for a long time.

But for years, it remained mostly unused.

The internet had the status code, but not the infrastructure to make it useful.

MPP TestKit changes that.

We are building a production-ready implementation of HTTP 402 for machine payments on Solana.

In an MPP-enabled ecosystem, the transaction is the authorization.

There is no login page.

There is no checkout session.

There is no subscription screen.

There is only the request and the settlement.

How the x402 Flow Works

The flow is simple.

1. The Request

An agent calls a protected API endpoint.

The endpoint checks whether the request includes valid payment proof.

If there is no payment proof, the server does not return the data.

Instead, it starts the payment handshake.

2. The 402 Challenge

The server responds with:

402 Payment Required

But this is not a dead end.

It is a machine-readable challenge.

The response includes payment details such as:

Price
Recipient wallet
Network
Required settlement information

The agent now knows exactly what it must pay to access the resource.

3. The Settlement

The agent SDK reads the 402 response.

It signs a Solana transaction for the exact amount required.

Then it submits the transaction to the network.

No human approval screen.

No card form.

No checkout redirect.

Just machine-native settlement.

4. The Receipt

After payment, the agent retries the original request.

This time, it includes a payment receipt in the request headers.

The server can now verify that payment actually happened.

5. Access Granted

The server verifies the transaction on-chain.

If the receipt is valid, the endpoint releases the data.

The agent gets access.

The provider gets paid.

The whole loop happens programmatically.

That is the missing primitive.

Why Solana Makes Sense for This

Machine payments require speed, low cost, and high throughput.

A machine economy cannot run on slow settlement and expensive fees.

If an agent wants to pay fractions of a dollar for an API request, the payment rail needs to make economic sense.

Solana gives this model the right foundation:

Fast settlement
Low fees
High throughput
Strong developer tooling
A growing ecosystem of wallets, agents, and on-chain infrastructure

MPP TestKit takes those rails and makes them usable for developers building real apps.

Engineering the Multi-Language Standard

A protocol is only as strong as its adoption.

If you only support one language, you immediately limit the ecosystem.

The agent economy is language-agnostic.

Some developers build agents in TypeScript.

Some build backend services in Go.

Some build AI systems in Python.

Some build high-performance infrastructure in Rust.

MPP TestKit is designed to meet developers where they already are.

The TypeScript SDK: The Agent Toolkit

The TypeScript SDK is built for developers creating agents and client-side integrations.

Developers should not need to understand every detail of Solana transaction construction just to let an agent pay for an API.

That is why we built:

mppFetch()

It works like a drop-in replacement for the standard fetch() API.

But under the hood, it handles the entire 402 lifecycle.

It can:

Detect a 402 Payment Required response automatically
Read the payment challenge
Sign and submit the required Solana transaction
Retry the request with a payment receipt
Expose lifecycle callbacks for every step

For developers, this means they can build agents that pay for APIs without rebuilding the payment stack themselves.

Lifecycle Callbacks

MPP TestKit also includes lifecycle callbacks through onStep events.

That gives developers visibility into what is happening during payment execution.

For example:

Wallet funded
Payment submitted
Receipt generated
Receipt verified
Request completed

This matters because machine payments should not feel like a black box.

Developers need observability.

They need debuggability.

They need to know where a flow succeeds or fails.

MPP TestKit gives them that.

Ephemeral Wallet Support

For testing and agentic workflows, MPP TestKit supports ephemeral wallets.

This allows agents to spin up temporary session wallets for devnet testing and experimentation.

That makes the developer experience much smoother.

Instead of manually managing wallets and funding flows, builders can test the full payment loop quickly.

This is especially useful for:

AI agent demos
Devnet simulations
Temporary task execution
Agent sandboxing
Protocol testing

Airdrop Retry Logic

Anyone who has built on devnet knows the pain.

Sometimes faucets are slow.

Sometimes airdrops fail.

Sometimes the developer experience breaks for reasons unrelated to your actual product.

MPP TestKit includes robust airdrop retry logic to reduce that friction.

The goal is simple:

Developers should spend more time building and less time fighting the faucet.

The Go SDK: High-Performance Backend Rails

TypeScript is perfect for agents and frontend-adjacent developer workflows.

Go is different.

Go is built for high-performance backend systems.

It is used for gateways, APIs, infrastructure services, and systems that need to handle concurrency at scale.

The MPP Go SDK is designed for API providers.

It fits naturally into net/http middleware and allows providers to protect endpoints with payment verification logic.

This gives backend teams a lightweight way to monetize endpoints without adding heavy runtime overhead.

If you are building an API that needs to verify many payment-gated requests per second, Go is the natural fit.

Python and Rust

MPP TestKit is also expanding across Python and Rust.

Python matters because the AI ecosystem lives there.

A huge amount of agentic infrastructure, machine learning tooling, and automation logic is written in Python.

Rust matters because performance-sensitive infrastructure needs safety and speed.

As the machine economy matures, developers will need SDKs across the full stack.

MPP TestKit is being built as a multi-language standard from day one.

Architectural Proof: Auton and Monetize

We did not want to release only documentation.

We wanted to prove the loop works.

That is why we launched two apps built around the MPP TestKit ecosystem:

Auton
Monetize

They represent both sides of the machine economy.

Auton: The Demand Side

Auton represents demand.

It is an autonomous agent client that discovers prices through the 402 handshake.

It does not use a checkout page.

It does not negotiate like a human.

It does not need a subscription.

It simply requests a resource, reads the server’s payment challenge, settles the required amount on Solana, and retrieves the data.

Auton is the blueprint for how agents should behave in a machine-native economy.

Monetize: The Supply Side

Monetize represents supply.

It shows how any developer can turn an existing API into a self-monetizing endpoint.

With one middleware integration, a normal endpoint can become payment-gated.

Monetize handles the verification logic:

Was the payment sent?
Was it sent to the right wallet?
Was the amount correct?
Was it on the right network?
Is the receipt valid?
Has the receipt already been used?

This is the infrastructure API providers should not have to rebuild themselves.

Together, Auton and Monetize prove that the accountless web is not theory.

It is functional.

The Economic Thesis: Beyond a Discount Token

Every infrastructure ecosystem needs alignment.

For MPP TestKit, that alignment layer is $MTK.

But we have a specific view on token utility.

We are not interested in empty governance theater.

We do not believe token holders should vote on every technical decision that should be handled by engineers.

Instead, $MTK is designed around:

Access
Alignment
Reputation
Builder incentives

1. Developer Access and Premium Tooling

$MTK can act as the access key for advanced MPP TestKit features.

As the ecosystem grows, token-based access can unlock premium developer tools such as:

Hosted endpoints
Advanced analytics
Higher testing limits
Premium dashboards
Enhanced developer tooling
Early access to new infrastructure modules

The builders most committed to the ecosystem should have the best tools to scale.

2. Micro-Payment Alignment

As more agents use x402 rails and more developers list endpoints through Monetize, the overall utility of the ecosystem grows.

$MTK aligns the community around that growth.

It becomes the unit of coordination for builders, users, providers, and early supporters of machine-native commerce.

3. Builder Incentives

The people pushing the protocol forward should participate in the upside.

That includes:

Developers building SDKs
Engineers finding bugs
Writers creating tutorials
Builders launching apps
Contributors improving integrations
Community members onboarding new developers

$MTK gives the ecosystem a way to reward the people actually doing the work.

Not just spectators.

Builders.

4. Reputation and Staking

This is one of the most important future paths.

In an economy full of autonomous agents, reputation becomes critical.

How does an agent know an API provider is reliable?

How does a provider know an agent is not abusive?

How do marketplaces rank endpoints without relying only on centralized reviews?

A staking and reputation layer can help.

Providers could stake $MTK to signal commitment to uptime, quality, and reliability.

Agents could hold or stake $MTK to unlock higher rate limits, verified status, or access to premium endpoints.

This creates a quality layer backed by economic skin in the game.

What Sits Behind One Integration

When a developer integrates MPP TestKit, they are not just adding a payment button.

They are getting months of infrastructure engineering compressed into a single integration point.

Universal Receipt Verification

MPP TestKit handles the logic required to verify that a Solana transaction actually happened and reached finality before access is granted.

This is not something every API provider should need to build from scratch.

Typed Error Classes

Bad error handling kills developer experience.

MPP TestKit replaces vague failures with protocol-specific error classes.

Instead of guessing what went wrong, developers can handle clear cases like:

Invalid receipt
Insufficient funds
Network timeout
Verification failure
Replay attempt

That makes the system easier to debug and safer to run in production.

Idempotency and Security

Payment systems need to be careful with retries.

Agents may retry requests.

Networks may delay responses.

Servers may receive duplicate attempts.

MPP TestKit is designed to prevent double charging and reduce replay attack risk.

That means agents are protected from accidental overpayment, and providers are protected from spoofed access attempts.

Stateless Scaling

Because the system does not require traditional user accounts, providers do not need to manage a massive user database.

There is no account migration problem.

No bot user table.

No subscription state machine.

No dashboard dependency.

A provider can scale from one request to one million requests without changing the core access model.

That is the power of stateless machine-native billing.

The MPP TestKit Roadmap

Infrastructure of this size is not static.

The core rails are already operational, but the roadmap is bigger than one SDK or one demo.

The goal is to bring x402 flows to every corner of the agent economy.

Phase 1: Foundation

The foundation layer has shipped.

This includes:

Payment Request and Payment Receipt handshake
Core TypeScript SDK
Python SDK
Go SDK
Reliability improvements
Lifecycle callbacks
Airdrop retry logic
End-to-end testing

This phase proved the core protocol flow works.

Phase 2: Developer Experience

The current focus is improving the developer experience.

This includes:

Rust SDK
MPX CLI
Endpoint testing from the command line
Developer playground
Network switcher
Framework recipes

The goal is to make the protocol easier to test, easier to integrate, and easier to explain.

Example CLI direction:

mpx mpp-test <url>

A developer should be able to test a payment-gated endpoint instantly.

No ceremony.

No complex setup.

Just run the command and see the flow.

Phase 3: Ecosystem and Agent Integrations

The next major expansion is agent framework integration.

This includes:

LangChain adapters
OpenAI function calling adapters
Django middleware
Go framework support for Echo and Fiber
Improved autonomous execution through Auton v2

Agents should not need custom glue code for every payment-gated resource.

MPP TestKit should become a native layer inside agentic workflows.

Phase 4: Production and Mainnet

The next stage is production-grade mainnet readiness.

This includes:

Mainnet migration guide
Approval safeguards
Native wallet support
Phantom integration
Backpack integration
WalletConnect support
Payment analytics
Multi-recipient payment support
Audit-friendly tracking

This is where the infrastructure matures from developer testing to real economic activity.

Phase 5: Protocol v2

The long-term vision extends beyond the first implementation.

Protocol v2 will focus on:

Cross-chain settlement
Base support
Arbitrum support
Batch payments
Subscription-like machine tiers
High-frequency payment flows
Formal protocol specification
RFC-style standardization

The machine economy will not be limited to one chain, one language, or one use case.

MPP TestKit is being built with that future in mind.

Use Cases: The Machines Are Hungry

The demand for this infrastructure is coming faster than most people realize.

Here are the use cases where machine-native payments become obvious.

1. Trading Bots and DeFi Agents

Autonomous trading agents need data.

They need:

Alpha scores
Rug risk reports
Whale movement alerts
Token analytics
Liquidity data
Market signals
Risk assessments

These agents do not have time to sign up for a Pro plan.

They do not want monthly subscriptions.

They need to pay per query, receive the data, and execute.

That is exactly what x402 enables.

A trading agent can request a specialized data endpoint, pay instantly, receive the result, and act on it.

This is where machine payments become not just useful, but necessary.

2. Content and Research Pipelines

AI agents performing research may need to access dozens of paid services during one workflow.

For example:

Search APIs
Translation APIs
Data extraction tools
Image generation
Text-to-speech
Market research databases
Summarization services
Financial data feeds

Today, each service has its own billing system.

That creates friction.

MPP TestKit makes the billing layer disappear.

Agents can move across multiple providers, paying for each resource as needed.

3. Agent-to-Agent Hiring

This may become one of the most powerful use cases.

Imagine an orchestrator agent receiving a complex task.

It may need to hire specialist agents.

One agent handles research.

Another handles data cleaning.

Another handles code generation.

Another handles verification.

Each specialist may need to pay for its own tools, APIs, or compute.

This creates chains of machine-native payments.

Only a protocol-level payment system can handle that cleanly.

4. Self-Monetizing APIs

Developers often have useful APIs that are too small to justify full billing infrastructure.

Maybe an endpoint only serves 50 requests a day.

Maybe each request is worth $0.05.

With Stripe, subscriptions, webhooks, databases, and account systems, monetizing that endpoint is not worth the effort.

With MPP TestKit, it becomes viable.

Wrap the endpoint.

Set the price.

Receive payment.

That unlocks the long tail of API monetization.

5. AI Tool Marketplaces

As AI agents become more capable, they will need tool marketplaces.

But those marketplaces need payment rails.

Every tool cannot rely on human checkout.

Agents need to discover tools, understand pricing, pay, and execute.

MPP TestKit provides the settlement layer for that future.

Why This Matters

The current internet was not built for autonomous economic actors.

It was built for humans browsing pages, creating accounts, and making purchases manually.

The next internet will look different.

Agents will discover services.

Agents will pay for APIs.

Agents will hire other agents.

Agents will route tasks across networks.

Agents will consume compute, data, and intelligence on demand.

That world needs payment infrastructure that is:

Programmable
Stateless
Fast
Low-cost
Chain-verifiable
Developer-friendly
Machine-native

That is what MPP TestKit is building.

The Future of Infrastructure

MPP TestKit is not just an app.

It is not just a marketplace.

It is not just a dashboard.

It is infrastructure for the next decade of commerce.

The early internet needed TCP/IP to define how data moves.

The machine economy needs a standard for how value moves.

We believe that standard starts with HTTP 402.

We believe the right settlement rail is Solana.

And we believe the developer layer that brings it all together is MPP TestKit.

The rails are no longer theory.

They are live.

They are multi-language.

They are developer-ready.

The machine economy is already here.

It is time to stop mocking payments and start building the future from the terminal.

Links

Website: https://mpptestkit.com

GitHub: https://github.com/mpptestkit

A Self-Monetizing API in 20 Lines of Code

MPP TestKit — Sat, 09 May 2026 10:53:15 +0000

This is a hands-on tutorial. By the end you'll have a running pay-per-request API server, a client that pays automatically, and a test suite that covers the full payment flow - all on devnet, completely free.

The Problem With How We Monetize APIs Today

If you've ever tried to sell access to an API you built, you know the drill:

Sign up for Stripe
Build a subscription checkout flow
Issue API keys on payment confirmation
Store keys in a database
Validate keys on every request
Build a usage dashboard
Handle expired cards, failed payments, refunds
Write the billing docs

By the time you've done all that, you've built a billing product. That wasn't the thing you wanted to build.

The worst part: none of this scales to small amounts. Charging $0.001 per API call with Stripe isn't viable - the processing fee alone exceeds the charge. So you're forced into subscriptions, bundles, and credit packs. Your pricing model becomes a product decision instead of just... pricing.

There's a cleaner way to do this. It's been in the HTTP spec since 1999. It just never had the infrastructure to work.

HTTP 402: The Status Code That Was Waiting for Blockchains

402 Payment Required

This status code has been reserved in HTTP since the original 1.1 spec. The idea: server tells the client "pay first, then retry." The client pays, retries with proof, gets the resource.

The problem was always how. How does the server specify the amount? In what form? How does the client pay programmatically? How does the server verify payment without a central authority?

Blockchains answer all of those questions. Solana specifically:

Specifies amount in SOL (or any token)
Accepts payment via a signed transaction
Provides on-chain verification with no intermediary
Confirms transactions in ~2 seconds
Charges fractions of a cent in fees

MPP Testkit is the SDK that wires this up. Let's build something with it.

What We're Building

A Node.js API server with:

/api/ping - free endpoint, no payment
/api/weather - costs 0.001 SOL per call
/api/forecast - costs 0.005 SOL per call (premium tier)

And a client script that:

Hits the paid endpoints automatically
Handles the wallet, airdrop, and payment without any manual steps
Logs every step of the flow

Total code: about 20 lines for the server, 10 for the client.

Setup

mkdir my-paid-api && cd my-paid-api
npm init -y
npm install express mpp-test-sdk

Create two files: server.js and client.js.

The Server

// server.js
import express from "express";
import { createTestServer } from "mpp-test-sdk";

const app = express();
const mpp = createTestServer();

// Free - no payment needed
app.get("/api/ping", (req, res) => {
  res.json({ status: "ok", ts: Date.now() });
});

// 0.001 SOL per call
app.get("/api/weather",
  mpp.charge({ amount: "0.001" }),
  (req, res) => {
    res.json({
      city: "San Francisco",
      temp: 62,
      condition: "Partly cloudy",
      paid: true,
    });
  }
);

// 0.005 SOL per call - premium tier
app.get("/api/forecast",
  mpp.charge({ amount: "0.005" }),
  (req, res) => {
    res.json({
      city: "San Francisco",
      forecast: [
        { day: "Mon", high: 65, low: 54 },
        { day: "Tue", high: 68, low: 57 },
        { day: "Wed", high: 61, low: 52 },
      ],
      model: "v2-premium",
      paid: true,
    });
  }
);

app.listen(3001, () => {
  console.log("Server running on :3001");
  console.log("Payment recipient:", mpp.recipientAddress);
});

Start it:

node server.js
# Server running on :3001
# Payment recipient: 7xKmPq2rNbMd...

That's the server. mpp.charge() is Express middleware. It returns a 402 if no valid payment receipt is present, verifies on-chain if one is, and calls next() if everything checks out.

The Client

// client.js
import { createTestClient } from "mpp-test-sdk";

const client = await createTestClient({
  network: "devnet",
  onStep: ({ type, message }) => console.log(`  [${type}] ${message}`),
});

console.log("\n- Hitting /api/ping (free)");
const ping = await client.fetch("http://localhost:3001/api/ping");
console.log(await ping.json());

console.log("\n- Hitting /api/weather (0.001 SOL)");
const weather = await client.fetch("http://localhost:3001/api/weather");
console.log(await weather.json());

console.log("\n- Hitting /api/forecast (0.005 SOL)");
const forecast = await client.fetch("http://localhost:3001/api/forecast");
console.log(await forecast.json());

Run it:

node client.js

- Hitting /api/ping (free)
{ status: 'ok', ts: 1715123456789 }

- Hitting /api/weather (0.001 SOL)
  [wallet-created] Keypair generated: 3xMn9...Wr4k
  [funded] Airdropped 2 SOL on devnet
  [request] GET http://localhost:3001/api/weather
  [payment] 402 received · paying 0.001 SOL
  [payment] tx confirmed: 5xKm7...Pq2r
  [retry] Retrying with Payment-Receipt header
  [success] 200 OK
{ city: 'San Francisco', temp: 62, condition: 'Partly cloudy', paid: true }

- Hitting /api/forecast (0.005 SOL)
  [request] GET http://localhost:3001/api/forecast
  [payment] 402 received · paying 0.005 SOL
  [payment] tx confirmed: 8xNp3...Qr1s
  [retry] Retrying with Payment-Receipt header
  [success] 200 OK
{ city: 'San Francisco', forecast: [...], model: 'v2-premium', paid: true }

Notice: the wallet and airdrop only happen once. The second paid call reuses the same wallet - no second airdrop. The client is stateful, the calls are not.

What Just Happened Under the Hood

When the client hit /api/weather:

Client sent GET /api/weather - no special headers
Server returned 402 Payment Required with header:

   Payment-Request: solana; amount="0.001"; recipient="7xKmPq2r..."

SDK parsed the header, built a Solana transaction for 0.001 SOL to 7xKmPq2r...
SDK signed and submitted the transaction to devnet
SDK waited for confirmation (~2 seconds)
Client retried with header:

   Payment-Receipt: solana; signature="5xKm7...Pq2r"

Server verified on-chain: transaction exists, recipient matches, amount ≥ 0.001 SOL
Server called next(), handler returned 200

Your handler code saw none of this. It just received a request and returned JSON.

Writing Tests for Your Paid Endpoints

This is where MPP Testkit really shines. Integration testing paid APIs usually means mocking the payment layer, which means your tests don't actually test the payment logic.

With MPP Testkit on devnet, you test the real flow for free:

// server.test.js
import { createTestClient } from "mpp-test-sdk";
import { describe, test, expect, beforeAll, afterAll } from "vitest";

let client;
let server;

beforeAll(async () => {
  // Start the server
  server = await import("./server.js");

  // Create a test client - wallet + airdrop happen here once
  client = await createTestClient({ network: "devnet" });
});

afterAll(() => server.close());

describe("Free endpoints", () => {
  test("GET /api/ping returns 200 without payment", async () => {
    const res = await client.fetch("http://localhost:3001/api/ping");
    expect(res.status).toBe(200);
    const body = await res.json();
    expect(body).toHaveProperty("status", "ok");
  });
});

describe("Paid endpoints", () => {
  test("GET /api/weather: pays 0.001 SOL, returns weather data", async () => {
    const res = await client.fetch("http://localhost:3001/api/weather");
    expect(res.status).toBe(200);
    const body = await res.json();
    expect(body).toHaveProperty("temp");
    expect(body.paid).toBe(true);
  });

  test("GET /api/forecast: pays 0.005 SOL, returns 3-day forecast", async () => {
    const res = await client.fetch("http://localhost:3001/api/forecast");
    expect(res.status).toBe(200);
    const body = await res.json();
    expect(body.forecast).toHaveLength(3);
  });

  test("Direct request without payment returns 402", async () => {
    const res = await fetch("http://localhost:3001/api/weather");
    expect(res.status).toBe(402);
    const header = res.headers.get("Payment-Request");
    expect(header).toMatch(/solana/);
    expect(header).toMatch(/amount="0.001"/);
  });

  test("Request with invalid receipt returns 403", async () => {
    const res = await fetch("http://localhost:3001/api/weather", {
      headers: { "Payment-Receipt": "solana; signature=fakesig123" },
    });
    expect(res.status).toBe(403);
  });
});

Run with:

npx vitest

These are real integration tests. No mocks. No stubs. The payment flow runs against devnet on every test run. If your receipt verification logic breaks, the test catches it - because it actually verifies.

Handling Errors Gracefully

Real code needs error handling. The SDK throws typed errors:

import {
  mppFetch,
  MppFaucetError,
  MppPaymentError,
  MppTimeoutError,
} from "mpp-test-sdk";

async function fetchWithFallback(url) {
  try {
    return await mppFetch(url);
  } catch (err) {
    if (err instanceof MppFaucetError) {
      // Devnet faucet rate-limited - common in CI with many parallel runs
      console.warn("Faucet unavailable, retrying in 60s...");
      await sleep(60_000);
      return mppFetch(url); // retry once
    }

    if (err instanceof MppPaymentError) {
      // Transaction rejected - log and rethrow
      console.error(`Payment rejected: ${err.url} → ${err.status}`);
      throw err;
    }

    if (err instanceof MppTimeoutError) {
      // Flow took too long - Solana can be slow under load
      console.error(`Timed out after ${err.timeoutMs}ms`);
      throw err;
    }

    throw err;
  }
}

Taking It to Production (Mainnet)

When you're ready to charge real SOL:

Server side - pin a stable recipient wallet:

const mpp = createTestServer({
  secretKey: process.env.SERVER_SECRET_KEY, // base64 or JSON array
  network: "mainnet",
});

Client side - provide a funded wallet:

const client = await createTestClient({
  network: "mainnet",
  secretKey: process.env.CLIENT_SECRET_KEY, // pre-funded with real SOL
});

The protocol is identical. The only difference is network: "mainnet" and no auto-airdrop. Your application code doesn't change.

The Creator Economy Angle

I want to zoom out for a second, because this is bigger than just APIs.

If you're a developer who creates things - libraries, datasets, AI models, tools - the standard monetization paths are:

Open source - free, you get nothing
SaaS - build a subscription billing system (Stripe, auth, database, dashboard)
One-time license - Gumroad, Paddle, etc. - purchase gate, license key management
Usage-based - Stripe metered billing - still requires subscription, monthly invoicing

All of these require you to build infrastructure around your actual product.

HTTP 402 with Solana adds a fifth option: embed payment in the protocol itself.

Your dataset endpoint charges $0.0001 per query. Your AI model charges $0.01 per inference. Your code analysis tool charges $0.005 per file. No subscription. No free tier decision. No pricing page. The price is in the API response.

Consumers - including AI agents - just pay and use. Your server accumulates SOL. You withdraw to your wallet.

The entire billing system is the blockchain.

Why This Matters for AI Agents Right Now

We're at an inflection point: AI agents are being deployed that autonomously call tools, APIs, and services. The problem is that every one of those tools currently requires a human to sign up, get an API key, and manage billing.

That doesn't scale. An agent that spins up 50 tool-calling sessions needs 50 sets of credentials managed by a human. Or one set of credentials shared across everything - which is a security disaster.

HTTP 402 with Solana gives agents a payment identity without a human in the loop:

Agent generates an ephemeral keypair on first run
Agent funds wallet from its operator's SOL balance
Agent hits any 402-gated endpoint and pays automatically
Operator monitors spending via on-chain transactions

No API keys. No credentials database. No revocation system. The wallet is the identity. The payment is the access token.

The Auton demo shows this working end-to-end - an agent that generates its own wallet, gets funded, navigates a 402 gate, pays, and retrieves premium data. Every step streams live to the browser. Watch it once and the architecture becomes obvious.

Quick Reference

Install

npm install mpp-test-sdk       # TypeScript/JavaScript
pip install mpp-test-sdk       # Python
go get github.com/mpptestkit/mpp-test-sdk-go  # Go

Minimal server

import { createTestServer } from "mpp-test-sdk";
const mpp = createTestServer();
app.get("/paid", mpp.charge({ amount: "0.001" }), handler);

Minimal client

import { mppFetch } from "mpp-test-sdk";
const res = await mppFetch("https://your-api.com/paid");

Networks

Network	Auto-funded	Cost
`devnet`	Yes (2 SOL)	Free
`testnet`	Yes (2 SOL)	Free
`mainnet`	No	Real SOL

Error types

Error	Cause
`MppFaucetError`	Devnet/testnet faucet rate-limited
`MppPaymentError`	On-chain transaction rejected
`MppTimeoutError`	Full flow exceeded timeout
`MppNetworkError`	Mainnet attempted without funded wallet

What's Next

Once you have the basics running:

Add multiple price tiers - mpp.charge({ amount: "0.01" }) on premium endpoints, mpp.charge({ amount: "0.001" }) on standard
Use the lifecycle events - stream payment status to your frontend in real-time (the playground does this)
Integrate with your existing auth - 402 and API keys aren't mutually exclusive; use 402 for metered access, API keys for identity
Move to mainnet - same code, swap network: "devnet" to network: "mainnet", provide funded wallets

The interactive playground is the fastest way to see the full flow before you build anything. It runs against a live server - no setup, no install.

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