# Machine Payments Protocol MPP

[7 · Pay](/category/pay/)

| Machine Payments Protocol |
| --- |
| Category | [Pay](/category/pay/) |
| Governed by | Co-authored by Tempo and Stripe; the core specification (the abstract 402/Challenge/Credential/Receipt shape) is submitted to the IETF standards track as the Payment HTTP Authentication Scheme, while individual payment methods (Tempo, EVM, Stripe Card, Lightning, Solana, Stellar, Monad, NEAR Intents, RedotPay) are maintained separately from the core, to keep the core neutral to any one rail |
| Status | Open protocol; developer docs distinguish the normative IETF specification from the mpp.dev developer-friendly overview |
| Phase | review |
| Implementation | multi-implementation |
| Adoption | unmeasured |
| Version | documented protocol overview on mpp.dev; normative text is the IETF-submitted 'Payment HTTP Authentication Scheme' draft |
| Specification | [https://mpp.dev/protocol](https://mpp.dev/protocol) |
| Found at | none — signalled per-request, no well-known file |
| Last checked | 2026-09-06 |

[Pay](/category/pay/) The Machine Payments Protocol (MPP) standardizes HTTP 402 "Payment Required" as an extensible, payment-network-agnostic machine-to-machine payment flow: a client requests a resource, the server issues a 402 challenge with WWW-Authenticate: Payment, the client fulfills the payment (signing a transaction, paying an invoice, or completing a card charge depending on the method) and retries with Authorization: Payment, and the server verifies and serves the resource with an optional Payment-Receipt header [[1]](#ref-1). It solves the same core problem as x402 and L402 — metered, account-free API access for agents and machines — but is explicitly designed to be method-agnostic: the same core Challenge/Credential/Receipt shape can carry Tempo, EVM, Stripe Card, Lightning, Solana, Stellar, Monad, or NEAR Intents payments [[1]](#ref-1)[[3]](#ref-3).

## Overview
It does not itself pick a payment network or currency: the core specification "makes no claims or affordances to any specific payment method" and is designed to work with any rail [[2]](#ref-2). MPP is precise about status-code semantics in a way that differs from typical HTTP auth schemes — it uses 402 consistently for all payment-related failures (a fresh challenge, a malformed credential, an expired challenge, or a failed verification), reserving 401 for authentication failures unrelated to payment and 403 for cases where a valid payment was made but policy still denies access [[1]](#ref-1).

MPP's governance is deliberately split in two: the core specification is co-authored by Tempo and Stripe and has been submitted to the IETF standards track under the name "Payment HTTP Authentication Scheme," while individual payment methods are maintained separately by whoever supports that rail, which the project says "keeps the protocol neutral while letting payment rails move at their own pace" [[2]](#ref-2). As of this verification the IETF submission's exact draft name/number was not independently located on the IETF datatracker, so its formal standing (individual submission vs. working-group adopted) is unconfirmed — mpp.dev's own "IETF Specs" card was checked but returned no distinct draft identifier in this pass. SDKs exist for TypeScript, Go, Ruby, Rust, and Python per the project's own site, and MPP maintains a direct compatibility/comparison page against x402 [[3]](#ref-3). No independent adoption count was found; adoption is recorded as unmeasured.

## Discovery and probe

HTTP 402 response carrying a WWW-Authenticate: Payment challenge · none — signalled per-request, no well-known file

```
GET {origin}/{paid-path}
parse:     HTTP 402 status with a WWW-Authenticate: Payment ... challenge header; a subsequent authorized retry returns 200 with a Payment-Receipt header
on absent: A 200, 401, or a 402 without a Payment-scheme WWW-Authenticate header means this path is not gated by MPP; MPP also has MCP/JSON-RPC and WebSocket transport bindings, so an HTTP-only probe cannot rule out MPP support offered solely over those transports.
```

Not probed live: no-fixed-path. MPP challenges appear only on paid URLs.

## History
- 2026-09-05 — seeded from Exa Agent research run
- 2026-09-06 — verified against mpp.dev (homepage, /protocol, /governance)

## Instances

- [Stripe](https://docs.stripe.com/payments/machine/x402) · Recorded 2026-09-07 · business
- [Tempo (co-author)](https://mpp.dev/governance) · Recorded 2026-09-06 · business
- [Stripe (co-author)](https://mpp.dev/governance) · Recorded 2026-09-06 · business
- [PyMPP (Python)](https://mpp.dev) · Recorded 2026-09-06 · service
- [mppx (TypeScript)](https://mpp.dev) · Recorded 2026-09-06 · service
- [MPP-rs (Rust)](https://mpp.dev) · Recorded 2026-09-06 · service
- [MPP-rb (Ruby)](https://mpp.dev) · Recorded 2026-09-06 · service
- [MPP-go (Go)](https://mpp.dev) · Recorded 2026-09-06 · service
- [Tempo](https://tempo.xyz/blog/mpp-sessions/) · Observed 2026-04-02 · network
- [Solana Foundation](https://github.com/solana-foundation/mpp) · Observed 2026-03-24 · network
- [Visa (mpp-card SDK)](https://www.npmjs.com/package/mpp-card) · Observed 2026-03-18 · business

Every instance with its source is listed on the [instances page](/instances/).

## See also

- [x402](/protocols/x402/)
- [L402](/protocols/l402/)
- [s402](/protocols/s402/)

## References

- MPP's protocol overview documents the flow as: client GETs a resource, server returns 402 with WWW-Authenticate: Payment, client retries with Authorization: Payment, server verifies and responds 200 with a Payment-Receipt header — and explicitly uses 402 (not 401) even for failed credential verification, reserving 401 for authentication failures unrelated to payment and 403 for policy denial after a valid payment. — [https://mpp.dev/protocol](https://mpp.dev/protocol) VERIFIED
- MPP's Governance page states the protocol is co-authored by Tempo and Stripe, is 'neutral by design' and operates independently of any single company, payment method, or rail, and splits governance between the core specification (submitted to the IETF standards track as the Payment HTTP Authentication Scheme) and separately maintained payment methods. — [https://mpp.dev/governance](https://mpp.dev/governance) VERIFIED
- mpp.dev's homepage lists SDKs across TypeScript (mppx), Go, Ruby, Rust, and Python, plus a comparison page contrasting MPP with x402, and blog posts describing added EVM and x402-exact-flow support as of June 2026. — [https://mpp.dev](https://mpp.dev) (2026-08-12) VERIFIED

[JSON](/data/protocols/mpp.json) · [Markdown](/protocols/mpp/index.md)