---
title: "MPP Overview"
type: concept
tags: [overview, core-spec, foundational, well-established]
created: 2026-08-10
updated: 2026-08-10
sources: ["raw/github_doc-readme-md.md", "raw/web_community-machine-payments-protocol-mpp.md"]
confidence: high
mpp_snapshot: "2026-08-10"
---

## Definition

The Machine Payments Protocol (MPP) is an open standard for machine-to-machine payments, co-authored by [[entities/method-tempo|Tempo]] (Tempo Labs) and [[entities/method-stripe|Stripe]]. It lets any client — an AI agent, an app, or a human — pay for an internet resource (an API call, a dataset, a unit of compute) inside the same HTTP request, using the native `402 Payment Required` status code, instead of requiring an account, API key, or pre-arranged billing relationship. MPP is published as an early IETF-style draft (`draft-00` documents; the core spec is tracked as `draft-ryan-httpauth-payment`), with a full rendered spec set at paymentauth.org and a marketing/docs site at mpp.dev.

## How It Works

MPP standardizes a `Payment` HTTP authentication scheme (defined in [[concepts/payment-http-auth-scheme]]) built on top of HTTP's reserved-but-never-standardized `402 Payment Required` status code. The end-to-end client-server exchange is:

1. **Client** requests a protected resource: `GET /resource`
2. **Server** responds `402 Payment Required` with a `WWW-Authenticate: Payment ...` challenge describing what payment is needed (method, intent, amount, recipient, etc.)
3. **Client** fulfills the payment off-band, via whichever payment method the challenge specifies (signs a transaction, pays an invoice, completes a card payment)
4. **Client** retries the same request, this time with an `Authorization: Payment <credential>` header containing proof of payment
5. **Server** verifies the credential and settles the payment, then returns `200 OK` with the resource and (optionally) a `Payment-Receipt` header proving delivery

```mermaid
sequenceDiagram
    participant Client
    participant Server
    Client->>Server: GET /resource
    Server-->>Client: 402 Payment Required, WWW-Authenticate: Payment ...
    Note over Client: Client fulfills payment challenge
    Client->>Server: GET /resource, Authorization: Payment credential
    Server-->>Client: 200 OK
```

This challenge/response mechanic is the exact mechanism defined in [[concepts/payment-http-auth-scheme]]. The specification is deliberately modular, separating stable protocol mechanics from evolving payment ecosystems into four layers (per the mpp-specs README "Architecture" section):

- **Core**: HTTP 402 semantics, headers, IANA registries — see [[concepts/payment-http-auth-scheme]]
- **Intents**: abstract payment patterns such as charge and subscription, defining *what* kind of payment without specifying *how* — see [[concepts/payment-intents]]
- **Methods**: concrete implementations for specific networks (Tempo, Stripe, ACH, and more) — each rail ships as its own plugin-style specification (see method entity pages below)
- **Extensions**: optional protocol additions such as discovery and identity — see [[concepts/payment-discovery]] and [[concepts/mcp-transport]]

## Key Parameters

- **Payment-method agnosticism**: the core protocol does not favor any payment network or currency. Each rail (card, EVM, Solana, Stellar, Hedera, Lightning, NEAR Intents, Stripe, Tempo, USDC) is defined by its own payment method specification that plugs into the same `Payment` challenge/credential shape, registering a lowercase method identifier and its own `request`/`payload` schemas.
- **Crypto vs. fiat, side by side**: MPP treats stablecoin/on-chain rails (Tempo, EVM, Solana, Stellar, Hedera, Lightning, NEAR Intents, USDC) and processor/fiat rails (Stripe, ACH-style bank rails, credit cards) as equally first-class "methods" under the same core scheme — "any currency" (USD, EUR, BRL, USDC.e, BTC, etc.) is a stated design goal.
- **Tempo + Stripe origin**: MPP is jointly authored and maintained by Tempo Labs and Stripe; the core httpauth spec's author list includes engineers from both organizations (see [[concepts/payment-http-auth-scheme]]).
- **Three parties**: Developers (integrate an MPP client so their agent/app can pay), Agents (autonomously call and pay for APIs on a user's behalf), and Services (integrate an MPP server to accept payment with zero onboarding friction).
- **First-class primitives**: idempotency, security, and Receipts are called out as designed-in primitives, not afterthoughts.
- **Design principles** (from the mpp-specs README): extensible core (minimal protocol designed for safe extension), network-agnostic/multi-rail, currency-agnostic (no implicit advantage for any currency or asset), and durable-by-design (replay protection and security as first-class concerns, following web standards).
- **Official SDKs**: TypeScript (`mppx`, the reference implementation, maintained with Wevm), Python (`pympp`), Rust (`mpp-rs`), Go (`mpp-go`), and Ruby (`mpp-rb`, maintained by Stripe).

## When To Use

MPP applies wherever a service wants to charge for programmatic access without pre-provisioned accounts, and wherever a client (especially an autonomous agent) needs to pay for a resource inline rather than through a human checkout flow. Cited use cases:

- **Agentic payments**: an AI agent calling LLM providers, search APIs, or image generators through MPP, paying per request without API keys or human intervention.
- **API monetization**: accepting payment from any client — agent, app, or human — without requiring signups, billing accounts, or API keys.
- **Micropayments**: charging sub-cent amounts per token, per query, or per request, using off-chain payment sessions with on-chain settlement.
- **Machine-to-machine commerce and usage-based billing** more broadly, per the README's stated primary use cases.

MPP is explicitly positioned against the alternative of fighting browser automation pipelines, visual captchas, and ever-changing checkout forms to make human-oriented payment flows work programmatically — the mpp.dev overview frames this as a structural, interface-level problem that MPP's HTTP-native challenge/credential exchange is designed to sidestep.

## Risks & Pitfalls

- MPP specs are early **IETF-style `draft-00`** documents — normative behavior may still change before ratification; implementers should track the IETF draft (`draft-ryan-httpauth-payment`) and the rendered spec set at paymentauth.org for updates.
- Because the protocol is payment-method agnostic, a server's actual security and finality guarantees depend entirely on which method specification is in play (see individual method entity pages) — the core scheme itself does not guarantee settlement finality.
- Discovery of payment methods/prices is optional and advisory, not authoritative — see [[concepts/payment-discovery]] for why the runtime 402 challenge always wins over any pre-fetched metadata.

## Related Concepts

- [[concepts/payment-http-auth-scheme]] — the core "Payment" HTTP authentication scheme that implements the challenge/credential exchange described here
- [[concepts/payment-intents]] — the abstract charge/subscription patterns layered on top of the core scheme
- [[concepts/payment-discovery]] — how clients find which methods/prices a server accepts before making a request
- [[concepts/mcp-transport]] — how the same payment flow is carried over JSON-RPC/MCP instead of raw HTTP

## Sources

- raw/github_doc-readme-md.md (mpp-specs repository README: what MPP is, architecture, design principles, related SDKs)
- raw/web_community-machine-payments-protocol-mpp.md (mpp.dev overview page: problem statement, three parties, payment flow, use cases, SDKs)