{
 "acronym": "MPP",
 "adoption": {
  "by": null,
  "level": "unmeasured",
  "probe_run": null
 },
 "aliases": [
  "MPP"
 ],
 "analog": "A payment-method-agnostic HTTP 402 challenge/credential/receipt exchange",
 "collisions": [],
 "discovery": {
  "mechanism": "HTTP 402 response carrying a WWW-Authenticate: Payment challenge",
  "path": "none — signalled per-request, no well-known file"
 },
 "dispute": null,
 "evidence": [
  {
   "claim": "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.",
   "date": null,
   "label": "VERIFIED",
   "url": "https://mpp.dev/protocol"
  },
  {
   "claim": "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.",
   "date": null,
   "label": "VERIFIED",
   "url": "https://mpp.dev/governance"
  },
  {
   "claim": "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.",
   "date": "2026-08-12",
   "label": "VERIFIED",
   "url": "https://mpp.dev"
  }
 ],
 "form": "http-header",
 "governance": "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",
 "group": "HTTP 402 family",
 "history": [
  {
   "date": "2026-09-05",
   "note": "seeded from Exa Agent research run"
  },
  {
   "date": "2026-09-06",
   "note": "verified against mpp.dev (homepage, /protocol, /governance)"
  }
 ],
 "id": "mpp",
 "implementation": "multi-implementation",
 "last_verified": "2026-09-06",
 "name": "Machine Payments Protocol",
 "native_status": "Open protocol; developer docs distinguish the normative IETF specification from the mpp.dev developer-friendly overview",
 "origin": {
  "date": null,
  "org": "Tempo and Stripe"
 },
 "part_of": null,
 "parties": [
  "agent-site",
  "agent-payment"
 ],
 "phase": "review",
 "probe": {
  "method": "GET",
  "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.",
  "parse": "HTTP 402 status with a WWW-Authenticate: Payment ... challenge header; a subsequent authorized retry returns 200 with a Payment-Receipt header",
  "path": "{origin}/{paid-path}"
 },
 "question": "How can a machine client (an agent, script, or another server) pay for an HTTP resource using any payment network, not just one?",
 "scope": "payments",
 "spec_url": "https://mpp.dev/protocol",
 "step": "pay",
 "summary_md": "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]. 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][3].\n\nIt 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]. 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].\n\nMPP'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]. 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]. No independent adoption count was found; adoption is recorded as unmeasured.",
 "track": "vendor-consortium",
 "version": {
  "date": null,
  "label": "documented protocol overview on mpp.dev; normative text is the IETF-submitted 'Payment HTTP Authentication Scheme' draft"
 }
}