How Stripe MPP Lets AI Agents Pay for Your API

Think about what it takes to get a paying customer on your API today: account signup, a pricing page, billing integration, API key provisioning, and inevitably a few support tickets. That’s fine when there’s a human on the other end. It completely breaks down when the API user is an autonomous agent.

The Machine Payments Protocol (MPP) is a new open standard, co-authored by Stripe and Tempo, that embeds payment negotiation directly into HTTP (and MCP) requests.

Instead of accounts, subscriptions, and API keys, an agent hits your endpoint, gets a 402 Payment Required response with the price, pays, and gets the resource. All in a single request-response cycle.

Earlier this year I wrote about x402, the Coinbase (and Stripe, oddly enough) backed protocol for enabling agents to pay for API access using cryptocurrency. MPP tackles the same fundamental problem but goes further in some important ways, and the fact that Stripe are adding their inherent DX and name specifically to this for sure means that there’s going to be eyes on it and adoption to follow.

What is MPP?

MPP (Machine Payments Protocol) standardizes the HTTP 402 Payment Required status code with a Challenge-Credential-Receipt flow. When a client hits a paid endpoint, the server tells it what payment is required and where to pay. The client pays. The server verifies that payment and returns the resource.

That all happens in seconds (and even faster if there’s no approvals).

The five-step flow:

1. Client requests a resource - GET /resource
2. Server returns a payment challenge - 402 Payment Required with a WWW-Authenticate: Payment header describing the price, currency, and accepted payment methods
3. Client fulfills the payment - signs a transaction, pays an invoice, or completes a card payment
4. Client retries with a credential - GET /resource with an Authorization: Payment header containing proof of payment
5. Server verifies and delivers - 200 OK with a Payment-Receipt header

This is how HTTP authentication already works (think WWW-Authenticate and Authorization headers for Bearer tokens), just applied to payments.

Why not just use x402?

Both MPP and x402 use the HTTP 402 status code. Both enable agents to pay for API access without accounts or API keys. But MPP addresses several gaps.

Payment method agnostic: x402 only supports blockchain transactions. MPP supports stablecoins (via Tempo), credit and debit cards (via Stripe and Visa), Bitcoin (via Lightning), and custom payment methods anyone can implement. Using MPP your API can accept Visa and USDC through the same protocol.

Sessions for streaming payments: x402 pays on-chain for every single request, which gets expensive fast. MPP lets a client deposit funds upfront, then spend against that balance with lightweight off-chain vouchers. Settlement happens in batches, so you get sub-100ms latency and near-zero per-request fees, which is critical for high-throughput use cases like token streaming.

Production primitives: MPP includes idempotency, request-body binding (digest verification to prevent request tampering), expiration, and structured receipts as first-class concepts. These matter when real money is moving. This also feels very Stripe-like in terms of DX and customer offering.

IETF standards: The core spec is submitted to the IETF for standardization, not just published as an open-source project.

That said, MPP is backwards-compatible with x402. The core x402 “exact” flow maps directly to MPP’s charge intent, and MPP clients can consume existing x402 services.

Stripe as a payment method

This is where MPP diverges most from x402. You do not need crypto at all. This is where “sounds cool, but crypto” hold outs start to prick up their ears.

MPP’s Stripe payment method uses Shared Payment Tokens (SPTs). Both the client and server need a Stripe account. The flow:

1. Server responds with 402 including Stripe-specific challenge details (amount, currency, allowed payment method types)
2. Client collects a payment method (via Stripe Elements or a stored card) and creates an SPT through the Stripe API
3. Client sends the SPT as a credential
4. Server creates a Stripe PaymentIntent using the SPT and confirms it
5. Server returns the resource with a receipt referencing the PaymentIntent

This means your API can accept Visa, Mastercard, and other card networks through MPP. Funds settle into your existing Stripe balance, on your standard payout schedule, with all the usual Stripe infrastructure (tax, fraud protection, reporting, refunds) intact.

For developers who already run on Stripe, this is the most practical path to MPP adoption. No crypto wallets, no new payment infrastructure, just a new protocol sitting in front of the same Stripe backend you already use, and a whole new world of agentic possibility for your APIs.

See the Stripe MPP documentation for the full integration guide, including deposit address creation and testnet setup.

Example

The mppx SDK is available for TypeScript, Python, and Rust. The fastest way to see it in action is with the CLI:

# Create a test account funded with testnet tokens
npx mppx account create

# Make a paid request
npx mppx https://mpp.dev/api/ping/paid

# Inspect a server's challenge without paying
npx mppx --inspect https://mpp.dev/api/ping/paid

The server quickstart walks through full setup. The protocol spec and IETF drafts are at paymentauth.org, and the spec source lives at github.com/tempoxyz/mpp-specs.

Here’s what the code looks like on each side.

Server side: charging for a resource

The mppx TypeScript SDK provides middleware for popular frameworks. Here’s a Next.js example that charges $0.10 per request in stablecoins on Tempo:

import { Mppx, tempo } from "mppx/nextjs";

const mppx = Mppx.create({
  methods: [
    tempo({
      currency: "0x20c0000000000000000000000000000000000000", // pathUSD on Tempo
      recipient: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
    }),
  ],
});

export const GET = mppx.charge({ amount: "0.1" })(() =>
  Response.json({ data: "paid content here" }),
);

The middleware handles the entire 402 Challenge/Credential/Receipt flow. When a request comes in without payment, it returns a 402 with the challenge. When a valid credential is provided, it verifies and calls your handler.

The ever popular Hono, Elysia, and Express are also supported via framework-specific imports (mppx/hono, mppx/elysia, mppx/express). For any other Fetch API-compatible framework (Cloudflare Workers, Deno, Bun), use mppx/server directly:

import { Mppx, tempo } from "mppx/server";

const mppx = Mppx.create({
  methods: [
    tempo({
      currency: "0x20c0000000000000000000000000000000000000",
      recipient: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
    }),
  ],
});

export async function handler(request: Request) {
  const response = await mppx.charge({ amount: "0.1" })(request);

  // Payment required: send 402 response with challenge
  if (response.status === 402) return response.challenge;

  // Payment verified: attach receipt and return resource
  return response.withReceipt(Response.json({ data: "paid content here" }));
}

You can override currency and recipient per route if different endpoints need different payment configurations:

mppx.charge({
  amount: "0.1",
  currency: "0x…",
  recipient: "0x…",
});

Client side: paying for a resource

On the client side, mppx can polyfill the global fetch to handle 402 responses automatically:

import { privateKeyToAccount } from "viem/accounts";
import { Mppx, tempo } from "mppx/client";

const account = privateKeyToAccount("0xabc…123");

// Polyfill global fetch to handle 402 automatically
Mppx.create({
  methods: [tempo({ account })],
});

// This just works. If the server returns 402, payment happens transparently.
const response = await fetch("https://api.example.com/paid-resource");

If you’d rather not polyfill the global fetch, use the bound mppx.fetch instead:

const mppx = Mppx.create({
  polyfill: false,
  methods: [tempo({ account })],
});

const response = await mppx.fetch("https://api.example.com/paid-resource");

MCP transport: paying for tool calls

MPP isn’t limited to HTTP. It includes a transport binding for the Model Context Protocol, which means MCP servers can charge for individual tool calls.

The protocol maps onto JSON-RPC:

When an agent calls a paid MCP tool, the server returns error code -32042 (the MCP equivalent of HTTP 402) with the payment challenge. The agent fulfills the payment and retries with the credential in the _meta field.

Agent calls a paid tool:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "web-search",
    "arguments": { "query": "MCP payments" }
  }
}

Server returns payment challenge:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32042,
    "message": "Payment Required",
    "data": {
      "challenges": [
        {
          "id": "ch_abc123",
          "method": "tempo",
          "intent": "charge",
          "request": {
            "amount": "10",
            "currency": "usd",
            "recipient": "0xa726a1..."
          }
        }
      ]
    }
  }
}

Agent retries with payment credential:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "web-search",
    "arguments": { "query": "MCP payments" },
    "_meta": {
      "org.paymentauth/credential": {
        "challenge": { "id": "ch_abc123" },
        "source": "0x1234...",
        "payload": { "signature": "0xabc..." }
      }
    }
  }
}

Today, most MCP servers are either free or require pre-configured API keys. MPP gives MCP tool providers a way to charge per-call without any account setup. This is significant for the MCP ecosystem as it matures and more tool providers look to monetize.

Regardless of current MCP vs CLI sentiment, I’m glad this is here. It’s going to be interesting to see who, if anyone, adopts this for MCP use.

MPP (and x402) and API Gateways

If you’re looking at these code examples and thinking “I don’t want to add payment middleware to every route handler in my application code,” you’re thinking about it the right way.

Payment negotiation, like authentication and rate limiting, is a cross-cutting concern. It belongs at the infrastructure layer, not scattered across your application. An API gateway is the natural place to enforce payment requirements: inspect incoming requests for credentials, issue 402 challenges for unauthenticated requests, verify payments, and pass verified requests through to your backend.

This is the same pattern you’d use for API key auth or rate limiting. Your backend focuses on business logic. The gateway handles the protocol mechanics. With MPP, the gateway would intercept the WWW-Authenticate / Authorization header exchange, verify credentials against the payment method, and attach Payment-Receipt headers to responses before forwarding them.

The MCP transport works the same way. A gateway sitting in front of your MCP server can intercept tool calls, issue -32042 challenges for unpaid requests, and transparently pass paid requests through.

Agentic Protocol Landscape

MPP enters a space that’s getting busy. However, I don’t expect it to get much more dense, and in many ways, MPP is a more tightly scoped vendor centric approach to x402.

x402 (Coinbase) was the first mover, using HTTP 402 for blockchain-only payments. Simple and effective, but limited to on-chain transactions and a single payment rail.

Google AP2 (Agent Payments Protocol) is a broader initiative standardizing how agents negotiate payment with merchants. It uses verifiable mandates for authorization and works with cards, bank transfers, and stablecoins. AP2 focuses more on the full commerce lifecycle (discovery, cart management, fulfillment) than on per-request API payments.

Stripe/OpenAI ACP (Agentic Commerce Protocol) handles the broader commerce flow between agents, businesses, and payment providers. It already powers Instant Checkout in ChatGPT. ACP is about product discovery and checkout, while MPP is about per-request API monetization. They’re complementary rather than competing.

MPP positions itself as the unifying payment layer: payment-method agnostic, IETF-bound, and backed by Stripe’s existing payment infrastructure. The Stripe integration is a major differentiator, giving API operators a way to accept agent payments through the same Stripe dashboard they already use.

For API developers, the important takeaway is that the 402 status code is being actively standardized for real payment flows, regardless of which specific protocol wins. If you’re running an API that agents will consume, understanding this pattern matters. Picking one of these will be a choice you eventually have to make.

What this means for API monetization

MPP is not a replacement for traditional API billing. If your customers are humans who want invoices, usage dashboards, and team management, you still need all those things.

Where MPP changes the equation is for high-volume, low-value transactions where the onboarding cost is disproportionate to the transaction value. An agent that needs to call your API once to get a piece of data should not need to create an account, pick a plan, and generate an API key first.

What Stripe have created here (and why this protocol might be the most quickly adopted) is effectively a bridge between two worlds. For existing Stripe users, MPP payments appear in your dashboard like any other transaction: same balance, same payouts, same reporting. You’re not setting up separate crypto infrastructure or learning a new billing system.

Whether MPP, x402, AP2, or something else becomes the dominant standard is an open question. But the underlying pattern, payment negotiation in the HTTP (and MCP) layer, is clearly where the industry is heading. The APIs that can accept payment from both humans and machines will have an advantage as agentic commerce matures.