Skip to main content
MPP is an open standard for machine-to-machine payments over HTTP, co-developed by Tempo and Stripe. It builds on the 402 Payment Required status code and defines a layered protocol: a core HTTP authentication scheme, abstract payment intents (charge, session), and pluggable payment methods (tempo, stripe, lightning, card, solana, and others). MPP has been submitted to the IETF as a candidate for the official HTTP 402 specification.

​
The payment flow

1. Client sends a normal HTTP request
2. Server responds with 402 + WWW-Authenticate: Payment challenge
3. Client authorizes payment
4. Client retries with Authorization: Payment credential
5. Server settles the payment
6. Server returns the resource + Payment-Receipt header
The server’s 402 response includes a WWW-Authenticate: Payment header with challenge parameters: a payment method, an intent type, and a base64url-encoded request describing what to pay. The client constructs a credential proving payment was authorized, base64url-encodes it, and sends it back in the Authorization: Payment header. On success, the server returns the resource along with a Payment-Receipt header. MPP is settle-only — there is no separate verification step before settlement.

​
How Faremeter supports MPP

Faremeter supports MPP through an adapter that translates MPP interactions into x402v2 format. From a developer’s perspective, this means:
  • On the server, enabling MPP in your middleware configuration is all that’s needed. Your existing payment handlers and facilitator settle MPP requests the same way they settle x402 requests.
  • On the client, no configuration is needed. The fetch wrapper automatically detects MPP challenges and handles them transparently.
The supported payment methods are determined by whichever x402 handlers you have configured. If your facilitator handles Solana and EVM payments, those same handlers process MPP requests.

​
Enabling MPP

MPP support is enabled via the supportedVersions option. Enabling MPP automatically enables x402v2, since the adapter depends on it. 
import { createMiddleware } from "@faremeter/middleware/hono";

app.get(
  "/api/data",
  await createMiddleware({
    facilitatorURL: "http://localhost:4000",
    accepts: [{ scheme: "exact", network: "solana-devnet", asset: "USDC", payTo: "7xKX..." }],
    supportedVersions: { mpp: true },
  }),
  (c) => c.json({ data: "paid content" }),
);

​
What’s supported

Faremeter currently supports the charge intent only. The session intent (streaming payments) is not yet implemented.

​
Differences from x402

For readers familiar with x402, the key differences are:
x402MPP
Challenge deliveryJSON body with accepts arrayWWW-Authenticate: Payment header
Payment attachmentX-PAYMENT or PAYMENT-SIGNATURE headerAuthorization: Payment header
ReceiptX-PAYMENT-RESPONSE or PAYMENT-RESPONSE headerPayment-Receipt header
VerificationOptional verify step before settlementSettle-only
Protocol structureFlat: scheme + networkLayered: intents + methods

​
Current limitations

  • Re-challenge on credential failure sends x402 format headers rather than an MPP WWW-Authenticate: Payment challenge.
  • Request body digest verification (MPP Spec Section 5.1.3) is not yet implemented.
  • Challenge replay protection (MPP Spec Section 11.3) is not yet implemented.

​
Further reading