Frequently asked questions

Is MPP only for stablecoins?

No. MPP is payment-method agnostic—the protocol works with any payment rail.

Today, Tempo stablecoin payments, Stripe (Visa, Mastercard, and other card networks), and Lightning (Bitcoin over the Lightning Network) are in production. Anyone can build a custom payment method by implementing the core control flow for their payment rail. See the full list of payment methods and specifications at paymentauth.org.

Do I need a stablecoin wallet?

No. With Stripe, you can pay with cards without stablecoins. With Lightning, you can pay with Bitcoin.

For Tempo payments, you need a stablecoin wallet to sign transactions. The SDK and the tempo wallet CLI handle key management for you.

How is MPP different from x402?

Both MPP and x402 use HTTP 402 to signal that a request requires payment. The key differences:

See MPP vs x402 for a full side-by-side comparison and migration guidance.

• Payment-method agnostic. MPP supports stablecoins, cards, wallets, and custom rails through extensible payment method specifications. x402 only supports blockchains.
• Designed for production. MPP supports idempotency, expiration, request-body binding (digest), and request-tampering mitigations as first-class primitives.
• Performant payments. MPP's session intent enables pay-as-you-go metering for payments as small as 0.0001 USD. Sessions achieve sub-100ms latency and near-zero per-request fees by settling off-chain vouchers, enabling high-throughput applications like token streaming or content aggregation. x402 requires an on-chain transaction per request.
• Permissionless extensibility. Anyone can author and publish a new payment method or intent specification without approval from a foundation or intermediary. Payment methods compete on adoption and are independently maintained.
• IETF standards track. The core Payment HTTP Authentication Scheme is submitted to the IETF for standardization.

Is MPP compatible with x402?

Yes. The core x402 "exact" flows map directly onto MPP's charge intent. MPP clients can consume existing x402 services. MPP extends beyond x402 with idempotency, receipts, request binding, multiple payment methods including stablecoins and fiat, and efficient low-cost flows like sessions.

Why build MPP on Tempo?

MPP works with any payment rail—Stripe for cards, Lightning for Bitcoin, or any custom method. You don't have to use Tempo.

That said, high-throughput, low-value transactions benefit from specific properties that Tempo provides:

• Fast, deterministic finality—Certainty that a payment has settled, not probabilistic confirmation.
• Low, predictable cost—Transaction fees stay stable regardless of global network congestion.
• Payment lanes—Dedicated transaction routing for payment traffic, ensuring reliability even under heavy load.
• Stablecoin-native—TIP-20 stablecoins (USDC.e, USDT) are first-class citizens, so payments are denominated in familiar currency.

These properties make Tempo well-suited as a settlement layer for machine payments where speed, cost, and reliability matter.

What are sessions?

Sessions are a Tempo-specific payment intent that enables streaming, pay-as-you-go payments. Instead of paying per request, a client opens a session (depositing funds into an escrow contract), then makes many requests by issuing signed vouchers off-chain. The server periodically settles the accumulated vouchers on-chain. Sessions are the mechanism that makes micropayments viable—sub-cent transactions cost nothing individually because only net settlement hits the chain. See the session documentation for details.

Because sessions bypass consensus for individual interactions, they achieve client-to-server latency (low double-digit milliseconds), near-zero per-request fees, and horizontally scalable throughput. The bottleneck is CPU, not blockchain TPS.

How much does it cost?

Pricing is set per service. For individual charge payments, typical prices range from $0.01 to $0.10 per request. For session-based payments, the per-request cost can go much lower because each interaction is a signed voucher rather than an on-chain transaction—only net settlement hits the chain.

The protocol itself is free and open. There are no licensing fees for implementing MPP.

Is it safe?

MPP requires TLS 1.2+ for all connections. Challenge IDs are cryptographically bound to prevent replay attacks. The protocol never performs side effects on unpaid requests—your client only pays after verifying what it is paying for.

Payments use the same security model as the underlying payment method. For Tempo, that means cryptographic signatures over every transaction. For Stripe, it means Stripe's existing fraud and dispute infrastructure.

For operational guidance on MPP_SECRET_KEY, logging, and rotation, see Security.

How do I handle MPP_SECRET_KEY?

Treat MPP_SECRET_KEY as root-of-trust material for server-side Challenge binding. Store it in a secrets manager, keep it server-side, never log it, rotate it immediately if it is exposed, and use overlapping current-and-previous key verification during rollovers so in-flight Challenges keep working. See Security for the full guidance.

What happens if a payment fails?

The service returns an error with details following RFC 9457 (Problem Details for HTTP APIs). Your client can retry with a different payment method or surface the error. No money is deducted for failed requests.

Can I accept MPP payments for my own service?

Yes. See the server quickstart to start accepting payments in a few lines of code, or read more about API monetization with MPP. The TypeScript SDK includes middleware for popular frameworks including Hono, Express, Next.js, and Elysia.

Is MPP an IETF standard?

The core Payment HTTP Authentication Scheme is submitted to the IETF standards track. Payment method and intent specifications (for example, charge, session) are separate documents that anyone can author and publish independently—they do not require IETF approval. This mirrors how the web works: HTTP is standardized, but content types and authentication schemes evolve independently.

Can I use MPP outside of HTTP?

Yes. MPP includes an MCP transport binding that maps the Challenge-Credential-Receipt flow onto the Model Context Protocol. This means MCP servers can monetize tool calls directly, and agents pay autonomously without OAuth or account setup.

Who is building MPP?

MPP is co-authored by Tempo and Stripe. The core specification is developed in the open and designed to be extended by any payment network or provider. The Payment HTTP Authentication Scheme is submitted to the IETF.