MPP Support

Run402 accepts payments via x402 and Stripe's Machine Payments Protocol — MPP on Tempo, and MPP on Bitcoin Lightning

What is MPP?

The Machine Payments Protocol (MPP) is Stripe's open protocol for machine-to-machine payments. It is settlement-agnostic: Run402 accepts it on Tempo, an L1 blockchain built by Stripe, using pathUSD as its stablecoin, and on the Bitcoin Lightning Network, paid in sats. Like x402, MPP enables AI agents to pay for permitted services autonomously over HTTP, without per-request human approval.

The protocol works in three steps: a server returns 402 Payment Required with a WWW-Authenticate: Payment challenge, the client pays and presents a payment credential, and the server verifies it — on-chain on Tempo, or by the invoice preimage on Lightning. Sub-second finality on Tempo and instant Lightning settlement mean payments clear almost immediately.

Three payment rails, one handshake

Run402 is multi-rail: every paid endpoint accepts x402 and MPP, and MPP settles on Tempo or on Bitcoin Lightning. Your agent's EVM wallet key works on both Base and Tempo—same private key, same address, different chains. For Lightning, the platform mints the agent a budgeted wallet on Run402's own Hub. You choose the rail at setup time.

Getting started with MPP

CLI

Switch your agent to the MPP rail with a single command. The Tempo faucet funds your wallet instantly—no rate limits, no waiting for on-chain confirmation.

npx run402 init mpp          # Fund wallet on Tempo, switch to MPP rail
npx run402 tier set prototype # Pay $0.10 in testnet pathUSD
npx run402 projects provision # Provision a Postgres database
npx run402 deploy --manifest app.json

To switch back to x402 at any time:

npx run402 init              # Switch back to Base Sepolia (x402)

CLI — Bitcoin Lightning

Ask the platform for a Lightning wallet. Run402 mints a budgeted sub-wallet on its own Hub, funds it with a few starter sats, and stores the pairing locally; from then on every paid call answers the Lightning challenge first and falls back to x402.

npx run402 init lightning                    # Mint the agent's wallet, switch rail
npx run402 tier set prototype                # Pay the tier in sats
npx run402 image generate "a lighthouse"     # $0.03, paid in sats
npx run402 wallets lightning status          # Balance and remaining budget

Or top an organization up in sats from any wallet — a phone, another agent:

npx run402 billing topup --sats 5000 --wait  # BOLT11 invoice (QR with --qr), wait, receipt

MCP Server

The run402-mcp server works with both rails. After running run402 init mpp, every paid call the MCP server makes (its tools and its run snippets) uses MPP on Tempo; run402 init lightning switches them to sats, and a run snippet calling r.billing.createLightningTopup mints an invoice for the organization.

Direct HTTP

Send an Authorization: Payment <credential> header with your MPP credential. The mppx SDK handles the 402 challenge–response flow automatically:

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

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

// mppx.fetch is a drop-in replacement for fetch
const res = await mppx.fetch(
  "https://api.run402.com/tiers/v1/prototype",
  { method: "POST" }
);

For Lightning, send Accept-Payment: lightning/charge;profile=run402-mpp-lightning-charge-draft00-safety-v1 with a stable Idempotency-Key. The 402 carries one fixed BOLT11 invoice; the retry presents its preimage as the Authorization: Payment credential. The wire profile is documented in openapi.json and llms-full.txt.

How it works on the server

When a request hits a paid endpoint on api.run402.com:

1. If the request has an Authorization: Payment header, it's routed to the MPP verifier. A Tempo credential is checked against the chain by the mppx middleware; a Lightning credential is checked by hashing its preimage against the retained invoice and confirming settlement on Run402's Hub.
2. If the request has an x402 header (payment-signature, x-payment), it's routed to the x402 facilitator for on-chain verification on Base.
3. If there's no payment header, the server returns 402 with both an x402 response body and a WWW-Authenticate: Payment header, so clients of either protocol know how to pay. A client that asked for Lightning gets exactly one BOLT11 challenge instead.

After successful payment, the response includes X-Run402-Settlement-Rail: mpp (or x402, or allowance) so your agent knows which rail settled the transaction. A settled Lightning charge carries a payment block (intent id, payment hash) and a Payment-Receipt header instead.

Pricing

Same prices on every rail. No surcharges for any protocol; a Lightning invoice is the USD price quoted into whole sats at mint.

Why all three?

x402 and MPP are complementary. x402 is the open community standard backed by Coinbase—it works with any EVM chain and any ERC-20 token. MPP is Stripe's take on the same idea, optimized for Tempo's instant finality and Stripe's fiat on-ramp. Lightning is where bitcoin-native agents and humans already keep their sats, and MPP's charge method carries it over the same 402 handshake. By supporting all three, Run402 meets agents where they are: crypto-native agents use x402, Stripe-native agents use MPP on Tempo, bitcoiners pay in sats, and everyone gets the same infrastructure.

We believe machine payments are inevitable and multi-protocol. Run402 is built to be rail-agnostic.

Resources

mpp.dev — MPP protocol spec and SDK docs

x402.org — x402 protocol spec

tempo.xyz — Tempo blockchain

lightning.network — the Bitcoin Lightning Network

mppx on npm — TypeScript SDK for MPP

run402.com/llms.txt — Full API reference for agents