Cowrie Research

machine-payments-protocol-primary-sources-2026-05-02

4 min read

Machine Payments Protocol (MPP) primary-source snapshot

Last reviewed: 2026-05-02 UTC

Project status snapshot

What the official materials say

1) Official site: MPP is an HTTP-402 machine-payments standard, not a single rail

  • URL: https://mpp.dev/
  • Key takeaways:
    • The homepage calls MPP the “open standard for machine-to-machine payments via HTTP 402.”
    • It says the protocol was co-developed by Tempo and Stripe.
    • The site taxonomy itself is revealing: instead of centering one chain, it centers protocol docs, payment methods, SDKs, transports, MCP monetization, API monetization, and agentic-payments use cases.
    • That strongly suggests MPP is meant to be cataloged as payment-control-plane infrastructure for machine commerce rather than as a chain-specific payments feature.

2) Protocol overview: shared challenge–credential–receipt semantics are the core product

  • URL: https://mpp.dev/protocol/
  • Key takeaways:
    • The protocol page says MPP standardizes HTTP 402 with an extensible framework that works with any payment network.
    • The canonical flow is: client requests a resource, server returns 402 Payment Required with a WWW-Authenticate: Payment challenge, client fulfills the payment, client retries with an Authorization: Payment credential, and server returns 200 OK with a Payment-Receipt header.
    • The docs define common status-code behavior, replay protection, body-digest binding for paid POST/PUT/PATCH requests, bearer-credential handling rules, and idempotency expectations.
    • This makes MPP look less like a billing wrapper and more like a true payment-authentication layer for web requests.

3) Multi-rail posture is explicit in both the docs and the repo

  • URLs:
  • Key takeaways:
    • The docs describe MPP as method-agnostic and expose payment-method sections for Tempo stablecoins, Stripe/card flows, Lightning, Solana, Stellar SEP-41, Monad, and custom methods.
    • The repo README says MPP is “the open protocol for machine-to-machine payments” and stresses a payment-method agnostic core plus separate method and extension specs.
    • The README’s architecture splits the standard into Core, Intents, Methods, and Extensions.
    • That modular split is one of the clearest signals that MPP should not be collapsed into any one settlement rail.

4) The IETF draft shows this is trying to become durable web infrastructure

  • URL: https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment/
  • Key takeaways:
    • The Internet-Draft is titled “The Payment HTTP Authentication Scheme.”
    • Its abstract says the document defines the Payment authentication scheme, gives semantics to HTTP 402, and is payment-method agnostic.
    • The draft states that specific payment methods are defined in separate method specifications and includes formal sections for headers, registries, intents, error handling, extensibility, and security considerations.
    • The authorship block explicitly includes contributors from Tempo Labs and Stripe, reinforcing the joint standards effort shown on the main site.
    • This is important because it shows MPP is aiming for standards-layer durability rather than only a product-marketing convention.

5) Use-case positioning: MPP is built for paid software and agents

  • URLs:
  • Key takeaways:
    • The docs repeatedly position MPP around paid APIs, MCP servers, tool calls, micropayments, and machine-to-machine commerce.
    • The homepage exposes guides such as “Monetize your MCP server,” “Use with agents,” “Accept multiple payment methods,” “Accept streamed payments,” and “Upgrade your x402 server to MPP.”
    • That use-case mix makes MPP look especially relevant to agentic commerce, API monetization, and programmable service billing—not just conventional consumer checkout.

Whitepaper / technical-doc status

  • No canonical standalone whitepaper or litepaper surfaced in this pass.
  • The real source of truth appears to be the MPP docs site, the public spec repository, and the linked IETF draft.
  • The IETF draft is especially useful because it turns the marketing claim into a concrete standards effort with explicit protocol mechanics.

Research notes

  • Best current category for the library: machine-payments protocol / HTTP 402 payment standard / multi-rail agentic-commerce infrastructure.
  • The most important categorization clue is that MPP defines the payment-auth handshake itself, while individual payment methods supply the rail-specific settlement proof.
  • MPP should stay distinct from x402 and L402 in the library. Those are concrete payment methods / rails; MPP is trying to be the broader multi-method standard that can also sit above card and stablecoin flows.
  • The combination of HTTP-native semantics, multi-rail method registries, MCP transport support, and an active IETF draft makes MPP feel like durable web infrastructure worth separate tracking.

Graph View