Mixed Payments run live on Tempo mainnet and through Stripe since 2026-03-18, but the core is an individual Internet-Draft with no IANA registrations yet, Stripe labels its MPP docs Frontier with a preview API version, and session is a per-method intent, not a standardized one.
Latest version
Core draft-httpauth-payment-01 (2026-09-09); mppx 0.13.4 on 2026-10-08,
State as of
Verified (verified under 30 days ago)
Multi-rail
Crypto-native
Card network
Payment credential (primary layer)
Settlement rails
Discovery
A. TL;DR and key facts
MPP adds a Payment authentication scheme to HTTP 402. The server sends a challenge, the client pays through a named method and retries with a credential, and the server returns a receipt.
Why it exists
An agent that wants one API call, one page of data or a stream of model tokens should not need an account, an API key and a card on file first. MPP puts the price and the proof of payment into the ordinary HTTP authentication headers, so a client can pay on the first request. Because the core says nothing about money movement, the same challenge and credential shape works for stablecoins on Tempo and other chains, Stripe Shared Payment Tokens, Visa network tokens and Lightning, and each rail writes its own method.
What it is not
Not Stripe-only. Tempo Labs and Stripe co-author the core, and Visa, Lightspark, Circle, Coinbase and others author payment methods. Source [1, 2, 3, 4, 18, 19, 20, 24]
Not an IETF standard. The core is an individual Internet-Draft with no working group, no stream and no intended status, and IANA has registered none of its names. Source [3, 5, 12]
Not crypto-only. Methods cover cards through Stripe Shared Payment Tokens and Visa network tokens, plus Bitcoin over Lightning. Source [17, 18, 19]
Not the MPP of AP2. In AP2 documents, MPP means Merchant Payment Processor, an unrelated role. Source [33]
Not a standardized session intent. Only charge and subscription are in specs/intents; session is defined inside method specs, and the generic session pull request closed unmerged on 2026-09-28. Source [1, 34]
Not x402. The two are separate HTTP 402 designs with a documented mapping, and the mppx SDK can serve both on one route. Source [28, 29]
Not an identity or mandate protocol. The core has no agent identity and no user authorization object; identity is an optional SDK add-on. Source [4, 35]
Key facts as of 2026-10-11
Steward
Tempo Labs and Stripe (co-authors); five core authors, three from Tempo Labs and two from Stripe Source [1, 2, 3, 4]
Governance
Core through the IETF as an individual Internet-Draft (no working group, not a standard); methods maintained by each rail; no foundation Source [1, 3, 5]
License
Specs CC0 1.0; tooling Apache-2.0 or MIT; mppx MIT Source [6, 7]
First announced
2026-03-18, with Tempo mainnet (spec repository started 2026-01-05) Source [2, 8, 9]
Latest version
draft-httpauth-payment-01 posted 2026-09-09, expires 2027-03-13; first name draft-ryan-httpauth-payment expired 2026-09-18; mppx 0.13.4 (2026-10-08) Source [5, 10, 11]
Status
Live on Tempo and Stripe; core still a draft; IANA registrations requested, not done Source [4, 12, 13]
x402 (exact maps to charge; mppx serves both), Stripe SPTs, Visa card method on VIC and TAP, Mastercard AP4M (Tempo's statement), AP2 (complementary, no cross-reference) Source [2, 17, 28, 29, 30, 31, 32]
How to read this explanation
ELI5 is a short plain-language version. Practitioner is the full text. Spec-deep adds field tables and wire examples. STE shows the Simplified Technical English version instead.
B. Detailed explanation
ELI5 mode: plain-language version only.
Practitioner mode: the full explanation.
Spec-deep mode: the full explanation plus 4 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Think of a toll gate on a road built for delivery robots. A robot rolls up and asks to pass. The gate does not open; it hands back a small printed ticket: “one cent, pay to this gate, any of these coins or cards accepted, ticket good for five minutes.” The ticket carries a stamp that only the gate can make, so nobody can fake one or change the price.
The robot picks a way to pay that it carries: digital dollars, a card that its owner set up, or a Lightning payment. It pays, staples the proof to the ticket and rolls up again. The gate checks the stamp, checks the proof, keeps the ticket so nobody can use it twice, opens, and gives the robot a receipt.
Some robots pass the same gate thousands of times an hour. For them there is a prepaid jar. The robot puts ten dollars in the jar once, and then hands the gate small signed notes as it goes: “I have now used 3 cents,” “now 4 cents.” The gate cashes the notes when it likes, and the robot can never lose more than what is in the jar. When the robot leaves, the gate takes what was used and the rest goes back.
That is MPP. The gate is a web server, the ticket is a , the stapled proof is a , and the jar is a . Two companies, and Stripe, wrote the rules together, and each kind of money writes its own small rule book.
MPP (Machine Payments Protocol) answers the same question as every design: how does a server a client that has no account? Its answer is to treat payment as an HTTP (Hypertext Transfer Protocol) authentication scheme named Payment.Source [1, 4] The server answers 402 with a WWW-Authenticate: Payment challenge that names a method, an intent and a base64url request; the client pays through that method and retries with Authorization: Payment and a credential; the server returns 200 with a Payment-Receipt.Source [4] The challenge id is bound to every parameter, usually with an HMAC (hash-based message authentication code), so a client cannot pay for something other than what the server asked, and each id works once.Source [4, 41] The core never moves money. Payment methods do, and they span Tempo , Stripe Shared Payment Tokens, Visa network tokens and Lightning, so MPP is not crypto-only.Source [1, 17, 18, 19] What MPP does not give you: an IETF standard (the core is an individual draft), a protocol identity for the agent, a user mandate, or a dispute process that works the same on every rail.Source [4, 5, 35, 41, 42]
Problem and design goals
The specification repository describes MPP as an open protocol for machine-to-machine payments in which a client pays inside the HTTP exchange, with no pre-provisioned account or API (application programming interface) key.Source [1] Tempo Labs and Stripe co-author it, so it is not a Stripe-only protocol.Source [1, 2, 3] Stripe announced it on 2026-03-18, the same day Tempo announced its mainnet.Source [2, 8]
Three design choices shape everything else. First, MPP reuses the HTTP authentication framework instead of inventing new headers: the challenge rides in WWW-Authenticate, the proof in Authorization, and only the receipt and preference headers are new.Source [4] Second, it separates the shape of a payment from the rail. The specification splits into a core, intents (abstract patterns such as a one-time charge), payment methods (concrete rails) and extensions for discovery and transports.Source [1] Third, it pushes rail work out of the core: each method is defined and maintained by the rail behind it, and rails can add methods without approval.Source [3]
The core also sets two guardrails for servers. A server must not perform side effects for a request that has not been paid, and it must not require a user account in order to pay.Source [4] The charge intent goes further and treats any partial delivery before verification, such as streamed tokens or a started tool call, as forbidden.Source [41]
Actors and roles
The core has two roles. The client requests a resource, receives the challenge, pays through the named method and retries with a credential. Before paying it must check the amount, recipient, currency and validity window, and it must not rely on the free-text description.Source [4] The server issues challenges, binds them, verifies and settles credentials and returns receipts.Source [4]
Methods add their own roles. In the card method a , such as a token service provider, provisions an encrypted and , and a , such as a PSP (payment service provider) or acquirer, decrypts it and asks the card network for authorization.Source [18] In the stripe method the merchant is identified by a Stripe in methodDetails.networkId, and both client and server need Stripe accounts.Source [17] In a the payer funds an escrow and the payee withdraws from it: the payer calls open, topUp, and withdraw, while the payee calls settle and close.Source [27] When methodDetails.feePayer is true the server co-signs the Tempo transaction and pays its fees, and the server always pays for settle and close.Source [16, 27] Stripe offers a hosted variant: with hostedFeePayer Stripe pays customers’ Tempo network fees, from mppx 0.9.2, in live mode only and not with Connect.Source [13]
Discovery adds a third kind of party. Crawlers and explorers read optional OpenAPI documents to list paid services; , run by Merit Systems, indexes servers, agents, transactions and volume.Source [15, 43, 44]
Core objects
Three objects carry every payment. The challenge is a set of auth-params on WWW-Authenticate: Payment. Five are required: id, realm, method, intent and request.Source [4] Five are optional: digest, expires, description, header and opaque.Source [4] The request value is base64url JSON without padding, canonicalized with (the JSON Canonicalization Scheme, RFC 8785), so two implementations compute the same binding input.Source [4] The server binds id to everything except description, and the recommended way is an HMAC-SHA256 over the parameters joined by pipes.Source [4] The digest parameter uses to tie the payment to the request body.Source [4]
The credential is base64url JSON with three fields: a challenge object that echoes the challenge, an optional source that identifies the payer (a , or decentralized identifier, is recommended), and a method-specific payload.Source [4] It goes in Authorization by default. If the challenge carried header="Payment-Authorization", the only allowed value, the client sends it in Payment-Authorization instead, which lets a client keep an ordinary bearer token in Authorization.Source [4]
The receipt is base64url JSON in Payment-Receipt with status, method, timestamp and reference, and status is always success.Source [4] A server must never send a receipt on an error response.Source [4] Errors are problem documents with type URIs under paymentauth.org, from payment-required to payment-action-required.Source [4]
Intents define the shared shape of request. A charge needs amount in base units and currency, with optional recipient, description, externalId and methodDetails.Source [41] A subscription adds periodUnit (day, week or month) and periodCount, with an optional subscriptionExpires.Source [45] Expiry never sits inside request; it travels only as the expires auth-param.Source [41] Method identifiers are lowercase ASCII letters, and the spec repository defines eleven of them.Source [1, 4, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26]
Field tables. Core version draft-httpauth-payment-01, read from specs/core/draft-httpauth-payment-01.md in tempoxyz/mpp-specs at commit 50309c8. Descriptions are paraphrased.
Challenge auth-params (WWW-Authenticate: Payment)Spec version draft-httpauth-payment-01
Field
Type
Required
Description
id
string
Yes
Non-empty challenge identifier, bound to the other parameters and echoed unchanged. Spec reference for id
Credential (Authorization: Payment or Payment-Authorization: Payment)Spec version draft-httpauth-payment-01
Field
Type
Required
Description
challenge
object
Yes
Echo of id, realm, method, intent, request, plus description, opaque, digest, expires and header when the challenge had them.
source
string
No
Payer identifier; DID format recommended, for example did:pkh on Tempo.
payload
object
Yes
Method-specific proof: a signed transaction, an SPT id, an encrypted card token, a preimage or a voucher.
Receipt (Payment-Receipt)Spec version draft-httpauth-payment-01
Field
Type
Required
Description
status
string
Yes
Always success; receipts appear only on 2xx responses.
method
string
Yes
Method used.
timestamp
string
Yes
RFC 3339 settlement time.
reference
string
Yes
Method reference: Tempo transaction hash, Stripe PaymentIntent id, card authorization reference, or channelId for a session.
subscriptionId
string
No
base64url id returned on subscription activation (subscription intent).
Shared request fields by intentSpec version draft-payment-intent-charge-00, draft-payment-intent-subscription-00, draft-tempo-session-00
Field
Type
Required
Description
amount
string
Yes
Base units. For a Tempo session it is the price per unit.
currency
string
Yes
ISO 4217 lowercase code, token address, or method-defined value.
recipient
string
No
Payee; required by Tempo session and Tempo subscription, forbidden in stripe subscription.
periodUnit / periodCount
string
No
Subscription only: day, week or month, and a positive integer string.
subscriptionExpires
string
No
Subscription only: end of the grant.
unitType / suggestedDeposit
string
No
Tempo session only, for example llm_token and a deposit hint.
description / externalId
string
No
Display text and merchant reference.
methodDetails
object
No
Method-specific fields; may carry a version, absent means 1.
Problem types (base https://paymentauth.org/problems/): payment-required, payment-insufficient, payment-expired, verification-failed, method-unsupported (400), malformed-credential, invalid-challenge, bad-request (400), invalid-payload, internal-payment-error (500) and payment-action-required; the rest return 402.Source [4]
Headers requested from IANA (Internet Assigned Numbers Authority) (not registered as of 2026-10-11): Accept-Payment, Payment-Authorization, Payment-Receipt, the Payment authentication scheme, and two new registries for methods and intents.Source [4, 12]
Illustrative example, spec version draft-httpauth-payment-01 with draft-tempo-charge-00: a Tempo charge challenge. The id, addresses and dates are placeholders, and the chain is the Moderato testnet.
The main sequence in section C plays a one-time Tempo charge over HTTP.Source [4]
The client requests the resource. It may add Accept-Payment with method and intent pairs and q weights, such as tempo/charge, stripe/charge;q=0.5.Source [4]
The server answers 402 with Cache-Control: no-store and one or more WWW-Authenticate: Payment challenges, optionally with a payment-required problem body.Source [4] The challenge stays authoritative even when the client stated preferences.Source [4]
The client decodes request and checks amount, recipient, currency and expiry.Source [4] For Tempo it signs a transfer or transferWithMemo transaction valid no later than expires; with feePayer true it leaves the fee to the server.Source [16]
The client retries the same request with Authorization: Payment and the credential.Source [4]
The server checks that the id is outstanding and bound, not expired, and that the proof, amount, recipient and digest match, then settles.Source [4, 41]
The server answers 200 with Payment-Receipt and Cache-Control: private; for Tempo the receipt reference is the transaction hash.Source [4]
Failures come back in one shape. A malformed credential, an unknown or used id, an expired challenge or a failed proof each get 402, a fresh challenge and a matching problem type.Source [4] A 403 means the payment was valid but policy denies access, and it carries no new challenge.Source [4] Servers should check ordinary authentication first and answer 401 before they issue a payment challenge, and should reject a request with two Payment credentials with 400.Source [4]
Other methods change step 3 and step 5. With stripe, the client creates a (SPT) and sends its spt_ id; the server creates a PaymentIntent with confirm true and the token as shared_payment_granted_token, and returns a receipt only if the PaymentIntent reached succeeded.Source [17] The spec recommends an made from the challenge id and the SPT, and Connect parameters such as application_fee_amount come from server configuration, never from the challenge.Source [17] With card, the challenge carries accepted networks, a merchant name and an RSA key; the Client Enabler returns a JWE (JSON Web Encryption) that neither client nor server can parse, and the server’s enabler decrypts it and authorizes it on the network.Source [18]
Over (Model Context Protocol) the same exchange becomes JSON-RPC. A paid tool returns error -32042 with the challenges in error.data, where request is a plain JSON object and httpStatus should be 402.Source [14] The client retries with the credential under _meta key org.paymentauth/credential and gets the receipt under org.paymentauth/receipt; a failed verification returns -32043 with a fresh challenge.Source [14]
Condition
Status
Response
Problem type
No credential
402
Fresh challenge
payment-required
Bad base64url or JSON
402
Fresh challenge
malformed-credential
Unknown or used id
402
Fresh challenge
invalid-challenge
Expired challenge
402
Fresh challenge
payment-expired
Proof fails
402
Fresh challenge
verification-failed
Paid, policy denies
403
No challenge
none
Two Payment credentials
400
Reject
none
MCP codes (draft-payment-transport-mcp-00): -32042 payment required, -32043 verification failed with a fresh challenge, -32602 malformed credential, -32603 processor failure. Servers advertise support under capabilities.experimental.payment.methods.Source [14]
Illustrative example, spec version draft-httpauth-payment-01: the decoded credential for the Tempo charge above, sent in Authorization: Payment <base64url>.
A challenge has a short life: issued, then consumed once, expired, or replaced by a fresh challenge after a failure.Source [4, 41] The longer lifecycles belong to sessions and subscriptions.
A Tempo session is a payment channel. The client deposits into an escrow, signs rising vouchers as it consumes units, and the server settles on chain when it chooses.Source [27] The challenge prices one unit and names the escrow contract.Source [27] The credential action is one of open, topUp, voucher or close, and every carries the channel id, a cumulative amount (a running total, not a delta) and an EIP-712 signature.Source [27] Vouchers go to the same resource URI (Uniform Resource Identifier), and HEAD requests can carry voucher-only updates.Source [27] For SSE (server-sent events) streams the receipt arrives in the first headers and again as a final payment-receipt event, with acceptedCumulative and spent fields that let the client audit the meter.Source [27]
A channel ends one of two ways. On a the client sends action: "close", and in v2 the server captures the greater of what was spent and what is already settled, then refunds the rest.Source [27] On a forced close the client calls requestClose, a grace period of at least 15 minutes starts in which the server can still settle, and the client then calls withdraw; the spec advises waiting 16 minutes.Source [27] A top-up during that grace period cancels the close request.Source [27] Channels never expire and vouchers have no validity field, so an open channel stays a liability until somebody closes it.Source [27]
Session protocol v1 uses the TempoStreamChannel escrow contract; v2 uses a (Tempo token standard) channel reserve precompile, and methodDetails.sessionProtocol says which.Source [27] The EIP-712 domain names differ too: Tempo Stream Channel in v1, TIP20 Channel Reserve in v2.Source [27]
A starts with activation: the server verifies the grant, collects the first period and returns a subscriptionId in the receipt.Source [45] Each later period allows at most one renewal, collected before or with delivery, and missed periods never add up to extra authority.Source [45] The id alone authorizes nothing.Source [45] Expiry, cancellation, a failed renewal or a bad credential all return 402 with a fresh challenge.Source [45]
Tempo session payload by actionSpec version draft-tempo-session-00 (2026-06-25 v2 text)
The stamped ticket stops two tricks: changing the price and using a ticket twice. It does not stop a fake gate from printing an honest-looking ticket with its own address, so the robot must still check who it pays. Anyone who steals the stapled proof before the robot uses it can spend it, so the proof must stay secret.
The core assumes an attacker who can read, inject, change and replay traffic, and who may run a malicious client or server.Source [4] Its guarantees are binding and single use: the server binds the id to every parameter, methods must give single-use proofs, and each id works once.Source [4, 41] TLS (Transport Layer Security) 1.2 or later is required and TLS 1.3 recommended.Source [4]
Credentials are bearer tokens: whoever holds an unused one can present it, so servers and intermediaries must not log them or put them in errors or analytics.Source [4] Caching needs care. Shared caches treat Authorization specially but not Payment-Authorization, so responses to that header must be private or no-store.Source [4] The client carries the last line of defense: binding stops tampering after the challenge is issued, but only the client’s own checks stop a malicious server from asking for too much or naming the wrong recipient.Source [4]
Loss limits come from the rail, not the core: a session deposit, SPT usage limits, or Tempo access key limits.Source [17, 27, 46] Disputes also depend on the rail, so card routes keep chargebacks while Stripe stablecoin payments have none.Source [41, 42]
The SDKs (software development kits) have had the serious bugs. Within two weeks of launch both the TypeScript and Rust SDKs received critical multi-bug advisories, GHSA-8x4m-qw58-3pcx and GHSA-fxc9-7j2w-vx54, neither with a CVE (Common Vulnerabilities and Exposures) id.Source [47, 48] CVE-2026-34209 let a close voucher equal to the settled amount close a channel for free, and CVE-2026-34210 let one SPT credential be replayed; both were fixed in mppx 0.4.11 on 2026-03-26.Source [11, 49, 50, 51] Two medium advisories in July 2026 let attackers drain a server through calldata padding or access lists, fixed in 0.8.2.Source [47] A formal analysis models MPP with x402, ACP (Agentic Commerce Protocol) and AP2 (Agent Payments Protocol) in Tamarin and reports 40 new findings across the four.Source [52] Section H has the threat table.
Versioning and governance
The core carries no version on the wire, like Basic and Bearer; an incompatible change would need a new scheme name such as Payment2.Source [4] Methods may add a version in methodDetails, and its absence means 1.Source [4]
The IETF (Internet Engineering Task Force) record is easy to misread. draft-ryan-httpauth-payment-00 was posted on 2026-02-16 and -01 on 2026-03-18, and that name expired on 2026-09-18.Source [10] A new name, draft-httpauth-payment-00, appeared on 2026-06-19 while the old one was still active, and -01 followed on 2026-09-09, expiring 2027-03-13.Source [5, 10] The 2026-09-09 event was a revision, not a rename, and the Datatracker records no “replaces” link between the two names.Source [5, 40] Both are individual submissions with no working group, stream or intended status, so the core is not an IETF standard.Source [5] mpp.dev’s description of the core as submitted to the standards track is stronger than that record.Source [3, 5] The intent, method, discovery and MCP drafts are not on the Datatracker at all, and IANA has registered none of the requested names.Source [1, 5, 12]
The core draft lists five authors, three from Tempo Labs and two from Stripe.Source [4] Governance sends the core through the IETF and leaves each method to its rail, with no foundation, charter or steering committee.Source [1, 3] Specifications are CC0 1.0 and tooling is Apache-2.0 or MIT; the mppx SDK is MIT.Source [6, 7]
Extensibility
Methods are the main axis. The spec repository holds eleven method ids: tempo, stripe, card, lightning, evm, solana, stellar, hedera, usdc, nearintents and xrpl.Source [1, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26] mpp.dev documents two more, monad and redotpay, that have no spec file.Source [53] Rails write their own: Jacob Brans of Visa wrote card, Lightspark wrote lightning, Circle wrote usdc, and Coinbase, MegaETH Labs and Monad Foundation wrote the evm charge.Source [18, 19, 20, 24] The methods map in section C shows rail, author and intents.
Intents are the second axis, and the rule is strict. A new intent starts as an experimental definition inside a method and moves to specs/intents/ only after two or more methods adopt it.Source [54] Only charge and subscription are there today; session is defined inside the tempo, evm, solana, hedera, lightning and xrpl method specs.Source [1, 19, 20, 21, 23, 26, 27, 34] The 2026-06-17 MPP blog called sessions a formal intent, but the pull request for a generic session intent (PR #280) closed unmerged on 2026-09-28.Source [34, 36]
Extensions are the third axis. Discovery is optional: a server publishes /openapi.json with x-service-info and per-operation x-payment-info, and the 402 challenge stays authoritative.Source [15] The MCP transport is the other extension, and mppx adds request attestation for Web Bot Auth and Visa TAP (Trusted Agent Protocol) outside the spec.Source [4, 14, 35]
Tempo charge methodDetails and payloadSpec version draft-tempo-charge-00
Field
Type
Required
Description
chainId
number
No
Spec default 42431 (the Moderato testnet id).
feePayer
boolean
No
Server sponsors the fee.
memo
string
No
bytes32; forces transferWithMemo.
splits
array
No
Extra recipients with amount and optional memo.
supportedModes
array
No
pull (server broadcasts) or push (client broadcasts).
payload.type
string
Yes
transaction (signature), hash (hash) or proof (zero-amount EIP-712 proof).
stripe and card charge fieldsSpec version draft-stripe-charge-00, draft-card-charge-00
Field
Type
Required
Description
networkId (stripe)
string
Yes
Business Network Profile of the seller.
paymentMethodTypes (stripe)
array
Yes
For example card or link.
spt (stripe payload)
string
Yes
Shared Payment Token id starting spt_.
acceptedNetworks, merchantName (card)
array, string
Yes
Networks the server takes and the display name.
encryptionJwk or jwksUri plus kid (card)
object or string
Yes
Server RSA key for the JWE.
encryptedPayload (card payload)
string
Yes
JWE with the network token and dynamic data; plus network, panLastFour and expiry fields.
How it composes with the other seven
MPP settles a payment and stops there, so it pairs with protocols that say who the agent is and what the user approved.Source [4, 35] Its closest sibling is x402: MPP’s own documentation maps the x402 headers onto Payment authentication and x402 exact onto charge, and mppx can serve both on one route.Source [28, 29] The stripe method carries Stripe Shared Payment Tokens, the same token family Stripe uses for agentic checkout with ACP.Source [2, 17] Visa wrote the card method and says it builds on VIC (Visa Intelligent Commerce) and TAP.Source [18, 30] Tempo says it is working with Mastercard on MPP compatibility for Agent Pay for Machines.Source [31] AP2 is complementary in principle, but neither side references the other, and the UCP (Universal Commerce Protocol) and ERC-8004 repositories do not mention MPP.Source [15, 32] The section “Compare and compose” below goes further.
Limitations and open issues
Not a standard yet. An individual draft, a first name that expired, and no IANA entries.Source [5, 10, 12]
Narrow authorship. All five core authors work at Tempo Labs or Stripe, and there is no neutral working group.Source [4, 5]
Session is not standardized. It lives in six method specs, and the generic intent pull request closed unmerged.Source [19, 20, 21, 23, 26, 27, 34]
savings are a best case. Opening a channel on an existing reserve balance costs 72.1 percent less gas than v1, but settling to a new payee balance costs 79.4 percent more.Source [36]
Spec inconsistencies. Tempo charge defaults chainId to the testnet id 42431, Tempo session to mainnet 4217, and the subscription spec calls 42431 mainnet.Source [16, 27, 43, 46, 55] Tempo subscriptions allow only day or week periods although the intent allows month.Source [45, 46]
Channels never expire. Unsettled vouchers persist until someone closes the channel.Source [27]
Public settlement. Tempo settlement is visible on a public chain and indexed by MPPscan.Source [43, 44]
Thin and tiny usage. MPPscan counted 4,072,426 transactions and 435,476 USD all time as of 2026-10-11, but only 8,774 USD across 998,771 transactions in the last 30 days, under one cent each.Source [44] The homepage shows only the last 7 days by default.Source [44] 126 of the 129 directory listings accept Tempo.Source [56]
Vendor framing. The MPP versus x402 page is written by MPP’s authors and recommends MPP by default.Source [28]
Unclear fees. A 1.5 percent Stripe stablecoin fee was reported in 2025, and whether it applies to MPP charges is not stated.Source [13, 42, 57]? unverified
What changed in 2025 and 2026
2026-01-05: the spec repository was created; its first commit became public on 2026-03-18.Source [9]
2026-03-18: launch by Stripe and Tempo with Tempo mainnet; Visa named the design partner for cards, Lightspark extended MPP to Lightning.Source [2, 8, 30]
2026-03-24 to 2026-06-21: Solana, Stellar, EVM, Hedera, USDC and NEAR Intents methods merged.Source [20, 21, 22, 23, 24, 25]
2026-03-26: advisories and the mppx 0.4.11 fix; NVD (National Vulnerability Database) published the two CVEs on 2026-03-31.Source [11, 49, 50, 51]
2026-08-04 to 2026-08-12: TAP and Web Bot Auth attestation merged in mppx, shipped in 0.8.17 and announced.Source [11, 35, 61]
2026-08-25 and 2026-08-27: Payment-Authorization merged; mppx 0.9.0 added dual MPP and x402 wrappers.Source [11, 29, 39]
2026-09-08 and 2026-09-09: XRPL methods merged; draft-httpauth-payment-01 posted.Source [5, 26]
2026-09-18 and 2026-09-28: the old draft name expired; the generic session intent pull request closed unmerged.Source [10, 34]
C. Diagrams
Main flow: MPP one-time charge over HTTP (tempo method, charge intent)
The default MPP path. The server answers an unpaid request with 402 and a WWW-Authenticate: Payment challenge, the client signs a Tempo transfer and retries with Authorization: Payment, and the server verifies, broadcasts and returns 200 with Payment-Receipt.
Client (agent)
Resource server
Tempo testnet (Moderato)
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 8Client (agent) toto Resource server
GET /v1/forecast (optional Accept-Payment)
The client asks for the resource with no credential. It may state the method and intent pairs it can use, with q weights. The server must treat Accept-Payment as a hint only.
Generated from the flow definition (spec version draft-httpauth-payment-01 with draft-payment-intent-charge-00 and draft-tempo-charge-00, 2026-09-09). The player above uses the same data.
Text alternative
Sequence diagram: MPP one-time charge over HTTP (tempo method, charge intent). 3 participants: Client (agent), Resource server, and Tempo testnet (Moderato). 8 steps, 6 crossing a trust boundary, 10 failure branches. Based on stripe-mpp draft-httpauth-payment-01 with draft-payment-intent-charge-00 and draft-tempo-charge-00 (2026-09-09). Step 1: Client (agent) to Resource server: GET /v1/forecast (optional Accept-Payment). This step crosses a trust boundary. Step 2: Resource server to Client (agent): 402 with WWW-Authenticate: Payment. This step crosses a trust boundary. If Credential needs ordinary authentication too: Server answers 401 first and issues the Payment challenge only after authentication. Step 3: Client (agent) to Client (agent): Decode request and check terms. If Challenge already expired: Client must not pay; it requests a new challenge. If Amount or recipient differ from policy: Client stops; nothing is signed. Step 4: Client (agent) to Resource server: Retry with Authorization: Payment. This step crosses a trust boundary. If Credential sent in a field the challenge did not select: Server must not accept it. Step 5: Resource server to Resource server: Verify binding, expiry and proof. If Bad base64url or JSON: 402, fresh challenge, malformed-credential. If Unknown or used id: 402, fresh challenge, invalid-challenge. If Expired: 402, fresh challenge, payment-expired. If Proof invalid: 402, fresh challenge, verification-failed. Step 6: Resource server to Tempo testnet (Moderato): Co-sign fee and broadcast. This step crosses a trust boundary. If Transaction reverts or is not included: 402 with a fresh challenge; no receipt. Step 7: Tempo testnet (Moderato) to Resource server: Transfer confirmed. This step crosses a trust boundary. Step 8: Resource server to Client (agent): 200 OK with Payment-Receipt. This step crosses a trust boundary. If Payment valid but policy denies access: 403 with no new challenge.
Step 1: Client (agent) to Resource server: GET /v1/forecast (optional Accept-Payment). This step crosses a trust boundary.
Step 2: Resource server to Client (agent): 402 with WWW-Authenticate: Payment. This step crosses a trust boundary. If Credential needs ordinary authentication too: Server answers 401 first and issues the Payment challenge only after authentication.
Step 3: Client (agent) to Client (agent): Decode request and check terms. If Challenge already expired: Client must not pay; it requests a new challenge. If Amount or recipient differ from policy: Client stops; nothing is signed.
Step 4: Client (agent) to Resource server: Retry with Authorization: Payment. This step crosses a trust boundary. If Credential sent in a field the challenge did not select: Server must not accept it.
Step 5: Resource server to Resource server: Verify binding, expiry and proof. If Bad base64url or JSON: 402, fresh challenge, malformed-credential. If Unknown or used id: 402, fresh challenge, invalid-challenge. If Expired: 402, fresh challenge, payment-expired. If Proof invalid: 402, fresh challenge, verification-failed.
Step 6: Resource server to Tempo testnet (Moderato): Co-sign fee and broadcast. This step crosses a trust boundary. If Transaction reverts or is not included: 402 with a fresh challenge; no receipt.
Step 7: Tempo testnet (Moderato) to Resource server: Transfer confirmed. This step crosses a trust boundary.
Step 8: Resource server to Client (agent): 200 OK with Payment-Receipt. This step crosses a trust boundary. If Payment valid but policy denies access: 403 with no new challenge.
Lifecycle: Tempo session channel lifecycle (cooperative and forced close)
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
Transition
Session challenge issued to Channel open
Trigger
Client sends action open with a signed deposit transaction
402 with intent session; amount is price per unit.
Channel open
Deposit in escrow; no expiry.
Streaming with vouchers
Off-chain cumulative EIP-712 vouchers; receipts carry acceptedCumulative and spent.
Close requested (grace period)
At least 15 minutes; server may still settle or close.
Closed and finalized
Payee paid, remainder refunded.
Rejected
400 malformed, 402 bad signature or signer, 410 channel not found or finalized.
Spec version draft-tempo-session-00.
State diagram: Tempo session channel lifecycle (cooperative and forced close)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version draft-tempo-session-00).
Text alternative
State diagram: Tempo session channel lifecycle (cooperative and forced close). 6 states: Session challenge issued, Channel open, Streaming with vouchers, Close requested (grace period), Closed and finalized, and Rejected. Starts in Session challenge issued. Ends in Closed and finalized and Rejected. 11 transitions. From Session challenge issued to Channel open when Client sends action open with a signed deposit transaction (open(payee, token, deposit, salt, authorizedSigner)). From Session challenge issued to Rejected when Open transaction or voucher signature invalid (HTTP 402 session/invalid-signature). From Channel open to Streaming with vouchers when Client sends rising vouchers to the same URI (Authorization: Payment action voucher (HEAD allowed)). From Streaming with vouchers to Streaming with vouchers when Server claims the newest voucher (settle(channelId, cumulativeAmount, signature)). From Streaming with vouchers to Streaming with vouchers when Deposit runs low (action topUp; topUp(channelId, additionalDeposit)). From Streaming with vouchers to Closed and finalized when Cooperative close: client sends action close; server captures max(spent, settled) (close(channelId, cumulativeAmount, signature)). From Streaming with vouchers to Close requested (grace period) when Server stops answering; client starts a forced close (requestClose(channelId)). From Close requested (grace period) to Streaming with vouchers when Client tops up, which cancels the close request (topUp (emits CloseRequestCancelled)). From Close requested (grace period) to Closed and finalized when Server closes during the grace period (close(channelId, cumulativeAmount, signature)). From Close requested (grace period) to Closed and finalized when Grace period over (wait 16 minutes); client withdraws the rest (withdraw(channelId)). From Streaming with vouchers to Rejected when Voucher above deposit, below minVoucherDelta or from the wrong signer (HTTP 402 session/amount-exceeds-deposit, session/delta-too-small, session/signer-mismatch).
From Session challenge issued to Channel open when Client sends action open with a signed deposit transaction (open(payee, token, deposit, salt, authorizedSigner)).
From Session challenge issued to Rejected when Open transaction or voucher signature invalid (HTTP 402 session/invalid-signature).
From Channel open to Streaming with vouchers when Client sends rising vouchers to the same URI (Authorization: Payment action voucher (HEAD allowed)).
From Streaming with vouchers to Streaming with vouchers when Server claims the newest voucher (settle(channelId, cumulativeAmount, signature)).
From Streaming with vouchers to Streaming with vouchers when Deposit runs low (action topUp; topUp(channelId, additionalDeposit)).
From Streaming with vouchers to Closed and finalized when Cooperative close: client sends action close; server captures max(spent, settled) (close(channelId, cumulativeAmount, signature)).
From Streaming with vouchers to Close requested (grace period) when Server stops answering; client starts a forced close (requestClose(channelId)).
From Close requested (grace period) to Streaming with vouchers when Client tops up, which cancels the close request (topUp (emits CloseRequestCancelled)).
From Close requested (grace period) to Closed and finalized when Server closes during the grace period (close(channelId, cumulativeAmount, signature)).
From Close requested (grace period) to Closed and finalized when Grace period over (wait 16 minutes); client withdraws the rest (withdraw(channelId)).
From Streaming with vouchers to Rejected when Voucher above deposit, below minVoucherDelta or from the wrong signer (HTTP 402 session/amount-exceeds-deposit, session/delta-too-small, session/signer-mismatch).
Four zones: the client holds its keys and policy, the server holds the binding secret and the handler, the rail settles, and discovery is public and advisory. Numbers follow the main flow.
Text alternative
Flowchart. The client zone holds the agent, its wallet key, SPT or card enabler, and its policy checks. The client requests a resource from the server middleware, gets 402 with WWW-Authenticate: Payment, pays through the named method, and retries with Authorization: Payment. The server middleware, which holds the HMAC binding secret, verifies and settles through one rail: the Tempo chain and escrow, Stripe PaymentIntents, a card network through enablers, or a Lightning node, then returns 200 with Payment-Receipt. The client may find services through /openapi.json and MPPscan.
Challenge, request, credential and receipt from the core, with the subscription fields and the Tempo session payload and receipt extensions. Problem documents ride in the 402 body.
Text alternative
Class diagram. Challenge has id, realm, method, intent, request, digest, expires, description, header and opaque, and its request decodes to Request with amount, currency, recipient, description, externalId and methodDetails. SubscriptionFields extends Request with periodUnit, periodCount and subscriptionExpires. Credential echoes the Challenge and carries source and payload; the Tempo session payload has action, channelId, cumulativeAmount and signature. Receipt has status, method, timestamp, reference and subscriptionId; the session receipt adds challengeId, channelId, acceptedCumulative, spent, units and txHash. A Problem with type, title, status and detail goes in the 402 body.
What each of the three messages carries. The challenge id binds every parameter except description, the credential echoes the challenge, and the receipt appears only on success.
Text alternative
Three stacked boxes. Challenge in WWW-Authenticate: Payment with status 402: required id, realm, method, intent and request; optional digest, expires, description, header and opaque; id computed as HMAC-SHA256 over the parameters joined by pipes. Credential in Authorization: Payment as base64url: challenge echo, optional payer DID source, method payload, sent in Payment-Authorization when the challenge set header. Receipt in Payment-Receipt, 2xx only: status success, method, timestamp and reference, with method extras such as subscriptionId, challengeId and channelId.
The 11 method ids with spec files in tempoxyz/mpp-specs as of 2026-10-11, their rail, spec author and the intents each defines. Session exists only inside method specs. mpp.dev also documents monad and redotpay without spec files.
Text alternative
Flowchart. Three intents: charge and subscription in specs/intents, session per method only. tempo (TIP-20, Tempo Labs) links to charge, session and subscription. stripe (SPT, Stripe and Tempo Labs) links to charge and subscription. card (network tokens, Visa) to charge. lightning (BOLT11, Lightspark) to charge and session. evm (Coinbase, MegaETH, Monad; OKG for session) to charge and session. solana to charge and session. stellar to charge. hedera to charge and session. usdc (Circle) to charge. nearintents (Near One) to charge. xrpl (Ripple) to charge and session.
Header and scheme correspondence published by MPP, consistent with the x402 page. exact maps to charge; upto and batch-settlement are only comparable to sessions. mppx 0.9.0 and later can serve both on one route.
Text alternative
Two columns. x402 V2 PAYMENT-REQUIRED maps to MPP WWW-Authenticate: Payment; PAYMENT-SIGNATURE maps to Authorization: Payment or Payment-Authorization; PAYMENT-RESPONSE maps to Payment-Receipt; scheme exact maps to intent charge; schemes upto and batch-settlement are comparable to per-method session. A note says mppx 0.9.0 and later serves both on one route.
MPP metered session on Tempo (open, vouchers, top-up, cooperative close)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
For streaming and per-unit pricing. The client opens an escrow channel with a deposit, then pays with off-chain cumulative vouchers sent to the same URI; the server settles when it likes and closes cooperatively, capturing only what was spent.
Text alternative
Sequence diagram: MPP metered session on Tempo (open, vouchers, top-up, cooperative close). 3 participants: Client (agent), Resource server, and Tempo escrow (precompile in v2). 10 steps, 10 crossing a trust boundary, 4 failure branches. Based on stripe-mpp draft-tempo-session-00 (v2 text merged 2026-06-25) (2026-06-25). Step 1: Resource server to Client (agent): 402 with intent="session". This step crosses a trust boundary. Step 2: Client (agent) to Resource server: action open. This step crosses a trust boundary. Step 3: Resource server to Tempo escrow (precompile in v2): Broadcast open. This step crosses a trust boundary. Step 4: Resource server to Client (agent): 200, stream begins, receipt. This step crosses a trust boundary. Step 5: Client (agent) to Resource server: action voucher (HEAD allowed). This step crosses a trust boundary. If Voucher above deposit: session/amount-exceeds-deposit. If Increase below minVoucherDelta: session/delta-too-small. If Wrong signer: session/signer-mismatch. Step 6: Client (agent) to Tempo escrow (precompile in v2): action topUp when low. This step crosses a trust boundary. Step 7: Resource server to Tempo escrow (precompile in v2): settle (optional, any time). This step crosses a trust boundary. Step 8: Client (agent) to Resource server: action close. This step crosses a trust boundary. Step 9: Resource server to Tempo escrow (precompile in v2): close. This step crosses a trust boundary. If Server unresponsive: Forced close: requestClose, grace period of at least 15 minutes, withdraw. Step 10: Resource server to Client (agent): Final receipt with txHash. This step crosses a trust boundary.
Step 1: Resource server to Client (agent): 402 with intent="session". This step crosses a trust boundary.
Step 2: Client (agent) to Resource server: action open. This step crosses a trust boundary.
Step 3: Resource server to Tempo escrow (precompile in v2): Broadcast open. This step crosses a trust boundary.
Step 4: Resource server to Client (agent): 200, stream begins, receipt. This step crosses a trust boundary.
Step 5: Client (agent) to Resource server: action voucher (HEAD allowed). This step crosses a trust boundary. If Voucher above deposit: session/amount-exceeds-deposit. If Increase below minVoucherDelta: session/delta-too-small. If Wrong signer: session/signer-mismatch.
Step 6: Client (agent) to Tempo escrow (precompile in v2): action topUp when low. This step crosses a trust boundary.
Step 7: Resource server to Tempo escrow (precompile in v2): settle (optional, any time). This step crosses a trust boundary.
Step 8: Client (agent) to Resource server: action close. This step crosses a trust boundary.
Step 9: Resource server to Tempo escrow (precompile in v2): close. This step crosses a trust boundary. If Server unresponsive: Forced close: requestClose, grace period of at least 15 minutes, withdraw.
Step 10: Resource server to Client (agent): Final receipt with txHash. This step crosses a trust boundary.
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 10Resource server toto Client (agent)
402 with intent="session"
The amount is the price per unit; the request names unitType, suggestedDeposit, recipient and methodDetails.escrowContract, chainId and sessionProtocol.
Spec version draft-tempo-session-00 (v2 text merged 2026-06-25) (2026-06-25). Sources: [27], [36]
Step 1 of 10: Resource server to Client (agent). 402 with intent="session". Crosses a trust boundary.
MPP subscription: activation and one renewal per period
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The client grants a recurring authorization once. The server collects the first period on activation and returns a subscriptionId, then collects at most one renewal per later period, before or with delivery. Any failure returns 402 with a fresh challenge.
Text alternative
Sequence diagram: MPP subscription: activation and one renewal per period. 3 participants: Client (agent), Resource server, and Payment network (Tempo or Stripe). 6 steps, 6 crossing a trust boundary, 2 failure branches. Based on stripe-mpp draft-payment-intent-subscription-00 with draft-tempo-subscription-00 (2026-07-29). Step 1: Resource server to Client (agent): 402 with intent="subscription". This step crosses a trust boundary. Step 2: Client (agent) to Resource server: Credential with the grant. This step crosses a trust boundary. Step 3: Resource server to Payment network (Tempo or Stripe): Collect the first period. This step crosses a trust boundary. Step 4: Resource server to Client (agent): 200 with subscriptionId in the receipt. This step crosses a trust boundary. Step 5: Resource server to Payment network (Tempo or Stripe): Next period: one renewal. This step crosses a trust boundary. If Renewal fails: 402 with a fresh challenge. If Cancelled or expired: 402 with a fresh challenge; no further renewals. Step 6: Resource server to Client (agent): Serve the period. This step crosses a trust boundary.
Step 1: Resource server to Client (agent): 402 with intent="subscription". This step crosses a trust boundary.
Step 2: Client (agent) to Resource server: Credential with the grant. This step crosses a trust boundary.
Step 3: Resource server to Payment network (Tempo or Stripe): Collect the first period. This step crosses a trust boundary.
Step 4: Resource server to Client (agent): 200 with subscriptionId in the receipt. This step crosses a trust boundary.
Step 5: Resource server to Payment network (Tempo or Stripe): Next period: one renewal. This step crosses a trust boundary. If Renewal fails: 402 with a fresh challenge. If Cancelled or expired: 402 with a fresh challenge; no further renewals.
Step 6: Resource server to Client (agent): Serve the period. This step crosses a trust boundary.
Spec version draft-payment-intent-subscription-00 with draft-tempo-subscription-00 (2026-07-29). Sources: [45], [46], [103]
Step 1 of 6: Resource server to Client (agent). 402 with intent="subscription". Crosses a trust boundary.
MPP charge with the stripe method (Shared Payment Token)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The challenge names the seller profile and accepted payment method types. The client creates a Shared Payment Token scoped to that seller and sends its id; the server creates and confirms a PaymentIntent and returns the PaymentIntent id as the receipt reference.
Text alternative
Sequence diagram: MPP charge with the stripe method (Shared Payment Token). 4 participants: Client (agent), Stripe (client account), Seller server, and Stripe (seller account). 6 steps, 6 crossing a trust boundary, 2 failure branches. Based on stripe-mpp draft-stripe-charge-00 (2026-09-09). Step 1: Seller server to Client (agent): 402 with method="stripe". This step crosses a trust boundary. Step 2: Client (agent) to Stripe (client account): Create a Shared Payment Token. This step crosses a trust boundary. Step 3: Client (agent) to Seller server: Retry with credential payload {spt}. This step crosses a trust boundary. Step 4: Seller server to Stripe (seller account): Create PaymentIntent (confirm true). This step crosses a trust boundary. If Stripe answers with Idempotent-Replayed for a new challenge: Treat as replay; mppx before 0.4.11 missed this (CVE-2026-34210). Step 5: Stripe (seller account) to Seller server: PaymentIntent status. This step crosses a trust boundary. If Any other status: 402 with a fresh challenge. Step 6: Seller server to Client (agent): 200 with Payment-Receipt. This step crosses a trust boundary.
Step 1: Seller server to Client (agent): 402 with method="stripe". This step crosses a trust boundary.
Step 2: Client (agent) to Stripe (client account): Create a Shared Payment Token. This step crosses a trust boundary.
Step 3: Client (agent) to Seller server: Retry with credential payload {spt}. This step crosses a trust boundary.
Step 4: Seller server to Stripe (seller account): Create PaymentIntent (confirm true). This step crosses a trust boundary. If Stripe answers with Idempotent-Replayed for a new challenge: Treat as replay; mppx before 0.4.11 missed this (CVE-2026-34210).
Step 5: Stripe (seller account) to Seller server: PaymentIntent status. This step crosses a trust boundary. If Any other status: 402 with a fresh challenge.
Step 6: Seller server to Client (agent): 200 with Payment-Receipt. This step crosses a trust boundary.
Spec version draft-stripe-charge-00 (2026-09-09). Sources: [2], [17], [51]
Step 1 of 6: Seller server to Client (agent). 402 with method="stripe". Crosses a trust boundary.
MPP charge with the card method (Visa-authored, encrypted network token)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The server offers card networks and an RSA key. The client asks its Client Enabler for a network token and cryptogram encrypted to that key, and the server passes the JWE to its Server Enabler, which authorizes on the card network.
Text alternative
Sequence diagram: MPP charge with the card method (Visa-authored, encrypted network token). 5 participants: Client (agent), Client Enabler, Merchant server, Server Enabler (PSP or acquirer), and Card network. 7 steps, 7 crossing a trust boundary, 1 failure branch. Based on stripe-mpp draft-card-charge-00 (2026-09-09). Step 1: Merchant server to Client (agent): 402 with method="card". This step crosses a trust boundary. Step 2: Client (agent) to Client Enabler: Ask for a token for this challenge. This step crosses a trust boundary. Step 3: Client Enabler to Client (agent): Encrypted payload. This step crosses a trust boundary. Step 4: Client (agent) to Merchant server: Retry with Authorization: Payment. This step crosses a trust boundary. Step 5: Merchant server to Server Enabler (PSP or acquirer): Forward encryptedPayload. This step crosses a trust boundary. Step 6: Server Enabler (PSP or acquirer) to Card network: Authorize. This step crosses a trust boundary. If Decline: Server should issue a fresh 402. Step 7: Merchant server to Client (agent): 200 with Payment-Receipt. This step crosses a trust boundary.
Step 1: Merchant server to Client (agent): 402 with method="card". This step crosses a trust boundary.
Step 2: Client (agent) to Client Enabler: Ask for a token for this challenge. This step crosses a trust boundary.
Step 3: Client Enabler to Client (agent): Encrypted payload. This step crosses a trust boundary.
Step 4: Client (agent) to Merchant server: Retry with Authorization: Payment. This step crosses a trust boundary.
Step 5: Merchant server to Server Enabler (PSP or acquirer): Forward encryptedPayload. This step crosses a trust boundary.
Step 6: Server Enabler (PSP or acquirer) to Card network: Authorize. This step crosses a trust boundary. If Decline: Server should issue a fresh 402.
Step 7: Merchant server to Client (agent): 200 with Payment-Receipt. This step crosses a trust boundary.
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 7Merchant server toto Client (agent)
402 with method="card"
request carries amount, currency, methodDetails.acceptedNetworks, merchantName and the encryption key as encryptionJwk or jwksUri plus kid on the realm origin.
Spec version draft-card-charge-00 (2026-09-09). Sources: [18], [30], [104]
Step 1 of 7: Merchant server to Client (agent). 402 with method="card". Crosses a trust boundary.
MPP over MCP: a paid tool call
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Over JSON-RPC the challenge arrives as error -32042 with request as a native JSON object; the client retries tools/call with the credential in _meta, and the result carries the receipt in _meta.
Text alternative
Sequence diagram: MPP over MCP: a paid tool call. 2 participants: MCP client (agent) and MCP server. 4 steps, 4 crossing a trust boundary, 3 failure branches. Based on stripe-mpp draft-payment-transport-mcp-00 (2026-09-09). Step 1: MCP client (agent) to MCP server: tools/call premium-analysis. This step crosses a trust boundary. Step 2: MCP server to MCP client (agent): error -32042 Payment Required. This step crosses a trust boundary. Step 3: MCP client (agent) to MCP server: Retry with _meta org.paymentauth/credential. This step crosses a trust boundary. If Verification fails: error -32043 with a fresh challenge and a failure object. If Malformed credential: error -32602. If Processor failure: error -32603. Step 4: MCP server to MCP client (agent): Result with _meta org.paymentauth/receipt. This step crosses a trust boundary.
Step 1: MCP client (agent) to MCP server: tools/call premium-analysis. This step crosses a trust boundary.
Step 2: MCP server to MCP client (agent): error -32042 Payment Required. This step crosses a trust boundary.
Step 3: MCP client (agent) to MCP server: Retry with _meta org.paymentauth/credential. This step crosses a trust boundary. If Verification fails: error -32043 with a fresh challenge and a failure object. If Malformed credential: error -32602. If Processor failure: error -32603.
Step 4: MCP server to MCP client (agent): Result with _meta org.paymentauth/receipt. This step crosses a trust boundary.
Spec version draft-payment-transport-mcp-00 (2026-09-09). Sources: [14]
Step 1 of 4: MCP client (agent) to MCP server. tools/call premium-analysis. Crosses a trust boundary.
MPP failure: the client pays an expired challenge
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The client signs too late. The server sees that expires has passed, answers 402 with a fresh challenge and a payment-expired problem, and settles nothing.
Text alternative
Sequence diagram: MPP failure: the client pays an expired challenge. 2 participants: Client (agent) and Resource server. 6 steps, 4 crossing a trust boundary. Based on stripe-mpp draft-httpauth-payment-01 (2026-09-09). Step 1: Client (agent) to Resource server: GET /v1/forecast. This step crosses a trust boundary. Step 2: Resource server to Client (agent): 402 with challenge. This step crosses a trust boundary. Step 3: Client (agent) to Client (agent): Sign after expires. Step 4: Client (agent) to Resource server: Retry with Authorization: Payment. This step crosses a trust boundary. Step 5: Resource server to Resource server: Check expiry. Step 6: Resource server to Client (agent): 402, fresh challenge, payment-expired. This step crosses a trust boundary.
Step 1: Client (agent) to Resource server: GET /v1/forecast. This step crosses a trust boundary.
Step 2: Resource server to Client (agent): 402 with challenge. This step crosses a trust boundary.
Step 3: Client (agent) to Client (agent): Sign after expires.
Step 4: Client (agent) to Resource server: Retry with Authorization: Payment. This step crosses a trust boundary.
Step 5: Resource server to Resource server: Check expiry.
Step 6: Resource server to Client (agent): 402, fresh challenge, payment-expired. This step crosses a trust boundary.
Source of truth: Specification (external link) Generated from src/content/flows/stripe-mpp-failure-expired-challenge.json.
Play this flow step by step
Client (agent)
Resource server
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Spec version draft-httpauth-payment-01 (2026-09-09). Sources: [4]
Step 1 of 6: Client (agent) to Resource server. GET /v1/forecast. Crosses a trust boundary.
MPP failure: a used credential is sent again (replay)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A credential that already paid is presented a second time, by the same client or by an attacker who copied it. The id is single use, so the server answers 402 with invalid-challenge and settles nothing.
Text alternative
Sequence diagram: MPP failure: a used credential is sent again (replay). 2 participants: Client (agent) and Resource server. 6 steps, 5 crossing a trust boundary. Based on stripe-mpp draft-httpauth-payment-01 (2026-09-09). Step 1: Client (agent) to Resource server: GET /v1/forecast. This step crosses a trust boundary. Step 2: Resource server to Client (agent): 402 with challenge. This step crosses a trust boundary. Step 3: Client (agent) to Resource server: First retry pays. This step crosses a trust boundary. Step 4: Client (agent) to Resource server: Same credential again. This step crosses a trust boundary. Step 5: Resource server to Resource server: Look up the id. Step 6: Resource server to Client (agent): 402, fresh challenge, invalid-challenge. This step crosses a trust boundary.
Step 1: Client (agent) to Resource server: GET /v1/forecast. This step crosses a trust boundary.
Step 2: Resource server to Client (agent): 402 with challenge. This step crosses a trust boundary.
Step 3: Client (agent) to Resource server: First retry pays. This step crosses a trust boundary.
Step 4: Client (agent) to Resource server: Same credential again. This step crosses a trust boundary.
Step 5: Resource server to Resource server: Look up the id.
Step 6: Resource server to Client (agent): 402, fresh challenge, invalid-challenge. This step crosses a trust boundary.
Source of truth: Specification (external link) Generated from src/content/flows/stripe-mpp-failure-reused-challenge.json.
Play this flow step by step
Client (agent)
Resource server
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Spec version draft-httpauth-payment-01 (2026-09-09). Sources: [4]
Step 1 of 6: Client (agent) to Resource server. GET /v1/forecast. Crosses a trust boundary.
MPP alternative path: paid, but policy denies access (403)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The payment is valid but the server will not serve the request, for example because the account is blocked. The server returns 403 with no new challenge, which tells the client that paying again will not help.
Text alternative
Sequence diagram: MPP alternative path: paid, but policy denies access (403). 2 participants: Client (agent) and Resource server. 3 steps, 2 crossing a trust boundary, 1 failure branch. Based on stripe-mpp draft-httpauth-payment-01 (2026-09-09). Step 1: Client (agent) to Resource server: Retry with Authorization: Payment. This step crosses a trust boundary. Step 2: Resource server to Resource server: Verify payment, then apply policy. Step 3: Resource server to Client (agent): 403 Forbidden, no challenge. This step crosses a trust boundary. If Rate limited: Server may send Retry-After.
Step 1: Client (agent) to Resource server: Retry with Authorization: Payment. This step crosses a trust boundary.
Step 2: Resource server to Resource server: Verify payment, then apply policy.
Step 3: Resource server to Client (agent): 403 Forbidden, no challenge. This step crosses a trust boundary. If Rate limited: Server may send Retry-After.
Source of truth: Credentials (external link) Generated from src/content/flows/stripe-mpp-failure-policy-denied.json.
Play this flow step by step
Client (agent)
Resource server
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Spec version draft-httpauth-payment-01 (2026-09-09). Sources: [4]
Step 1 of 3: Client (agent) to Resource server. Retry with Authorization: Payment. Crosses a trust boundary.
How MPP composes with the other seven
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Solid lines are documented links; dotted lines are statements by one side only or the absence of a link. The Mastercard line is Tempo's statement inside Mastercard's 2026-06-10 release.
Text alternative
Flowchart. x402 and MPP are linked: exact maps to charge and mppx serves both. MPP's stripe method carries Stripe Shared Payment Tokens, which OpenAI ACP agentic checkout also uses. MPP's card method may add Visa TAP headers and gets tokens from Visa Intelligent Commerce. Dotted: Mastercard Agent Pay for Machines (Tempo says it is working on MPP compatibility), AP2 (complementary, no cross-reference), UCP (no reference), ERC-8004 (discovery draft mentions future on-chain anchoring).
Where attacks land and which rule answers them. Three of the server items are past SDK advisories, now fixed.
Text alternative
Flowchart in four zones. Client: overpay by a malicious server, answered by client checks; leaked credential, answered by TLS and never logging. Path: a proxy caching a Payment-Authorization response, answered by Cache-Control private or no-store; spoofed discovery data, answered by treating the 402 challenge as authoritative. Server and SDK: replay of a consumed id or SPT, fee payer drained by padded calldata, close voucher equal to settled amount. Channel: never-expiring channel left open; unresponsive server at close, answered by forced close after 15 minutes.
Spec-deep mode: the full explanation plus 0 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
This section uses Simplified Technical English (ASD-STE100): short sentences, one instruction per step, and one word for one meaning.
MPP is the Machine Payments Protocol. It is an open protocol for payments in HTTP. Tempo Labs and Stripe wrote the protocol together. Thus, MPP is not a protocol of Stripe only.
MPP adds a Payment authentication scheme to HTTP. A server sends status 402 with a challenge. The client pays with the payment method that the challenge names. Then the client sends the request again with a credential. The server verifies the payment and sends a receipt.
The core specification is an individual Internet-Draft at the IETF. It is not an IETF standard. No IETF group controls it. Each payment rail writes the specification for its payment method.
MPP is not only for crypto money. Some payment methods use stablecoins on Tempo or on other networks. The stripe method uses Shared Payment Tokens for cards. The card method from Visa uses encrypted card tokens. The lightning method uses Bitcoin.
The server makes the challenge identifier from all of the challenge values with a secret key. Thus, nobody can change the amount or the recipient. Each challenge identifier operates one time only.
In AP2 documents, the letters MPP mean Merchant Payment Processor. That is a different thing.
Procedure Pay for a resource with MPP (agent)
Send the request to the server.
If the server sends status 402, read the WWW-Authenticate header.
Decode the request value of the challenge.
Make sure that the amount, the currency and the recipient are correct.
Make sure that the challenge did not expire.
Do not use the description to make a decision.
Pay with the payment method that the challenge names.
Send the request again. Put the credential in the Authorization header.
If the challenge has the header value, put the credential in the Payment-Authorization header.
Read the Payment-Receipt header. Keep the reference value.
Procedure Accept an MPP payment (server)
Select the payment methods that your buyers can use.
Make a secret key of 32 bytes or more for the challenges.
If a request has no credential, send status 402 with a challenge.
Set the Cache-Control header to no-store on the 402 response.
When a credential arrives, calculate the challenge identifier again.
Make sure that nobody used the challenge identifier before.
Make sure that the challenge did not expire.
Verify the payment proof with the payment method.
If a check fails, send status 402 with a new challenge.
Record the challenge identifier as used.
Send the resource with the Payment-Receipt header.
Procedure Close a payment channel (agent)
Send a credential with the close action and the last voucher.
Read the receipt. Make sure that the spent amount is correct.
If the server does not close the channel, call requestClose on the network.
Wait 16 minutes or more.
Call withdraw to get the remaining money back.
Technical nouns and technical verbs
challenge: The data in the WWW-Authenticate header that tells the client the price and the payment method.
credential: The data that the client sends to show that it paid. Anyone who has it can use it.
receipt: The data in the Payment-Receipt header that shows a successful payment.
payment method: The specification for one payment rail, for example tempo, stripe or card.
intent: The type of payment, for example charge or subscription.
charge: A payment of one amount one time.
subscription: A payment of one amount for each period.
session: A series of small payments from a deposit in a payment channel.
voucher: A signed note that gives the total amount that the client used.
payment channel: An escrow on the network that holds the deposit for a session.
Shared Payment Token: A Stripe token that lets a seller charge a card with limits.
verify (TV): To make sure that a payment proof is correct.
settle (TV): To send a payment to the network so that the money moves.
STE check report
Sentences
77
Longest procedural sentence
14 words (limit 20)
Longest descriptive sentence
16 words (limit 25)
Flags
None
Written to the public ASD-STE100 Issue 9 writing rules. Vocabulary not checked against the official dictionary.
Compare with the practitioner text side by side
Practitioner text (section B)
MPP (Machine Payments Protocol) answers the same question as every HTTP 402 design: how does a server charge a client that has no account? Its answer is to treat payment as an HTTP (Hypertext Transfer Protocol) authentication scheme named Payment. The server answers 402 with a `WWW-Authenticate: Payment` challenge that names a method, an intent and a base64url request; the client pays through that method and retries with `Authorization: Payment` and a credential; the server returns 200 with a `Payment-Receipt`. The challenge id is bound to every parameter, usually with an HMAC (hash-based message authentication code), so a client cannot pay for something other than what the server asked, and each id works once. The core never moves money. Payment methods do, and they span Tempo stablecoins, Stripe Shared Payment Tokens, Visa network tokens and Lightning, so MPP is not crypto-only. What MPP does not give you: an IETF standard (the core is an individual draft), a protocol identity for the agent, a user mandate, or a dispute process that works the same on every rail.
The specification repository describes MPP as an open protocol for machine-to-machine payments in which a client pays inside the HTTP exchange, with no pre-provisioned account or API (application programming interface) key. Tempo Labs and Stripe co-author it, so it is not a Stripe-only protocol. Stripe announced it on 2026-03-18, the same day Tempo announced its mainnet.
Simplified Technical English
MPP is the Machine Payments Protocol. It is an open protocol for payments in HTTP. Tempo Labs and Stripe wrote the protocol together. Thus, MPP is not a protocol of Stripe only.
MPP adds a Payment authentication scheme to HTTP. A server sends status 402 with a challenge. The client pays with the payment method that the challenge names. Then the client sends the request again with a credential. The server verifies the payment and sends a receipt.
The core specification is an individual Internet-Draft at the IETF. It is not an IETF standard. No IETF group controls it. Each payment rail writes the specification for its payment method.
E. Main personas
API, data or compute seller
Runs the resource server: prices routes, issues bound challenges, verifies credentials and returns receipts, usually through mppx middleware. Source [4, 7, 27, 47]
Goals
Charge per call or per token without accounts or invoices
Accept stablecoins and cards from the same 402 response
Get paid before any side effect runs
Pains
Managing the HMAC secret that every challenge id depends on
Choosing between charge and a session for streaming endpoints
Keeping up with SDK advisories (four mppx advisories in 2026)
Implements
mppx server with one or more methods and a secretKey
Cache-Control no-store on 402 and private on receipts
Atomic consumption of challenge ids
Must trust
The rail to settle what it confirms
Its SDK version to enforce replay and close rules
Discovery crawlers to list it accurately (advisory only)
Questions, first steps, metrics and a day in the life
Questions they ask
Which methods do my buyers actually hold?
Do I sponsor Tempo fees with feePayer or hostedFeePayer?
How do I refund a stablecoin charge if delivery fails?
First three steps
Run the mppx server quick start on the Moderato testnet
Add a second method (stripe) to the same route and read both challenges
Pin mppx to 0.8.2 or later and subscribe to the repository advisories
Metrics they care about
Paid requests per route
Share of 402s that convert to 200
Fee payer spend per day
A day in the life
Priya sells a weather API by the call. Her route answers unpaid requests with a Tempo challenge and a Stripe challenge, both bound with the HMAC secret she rotated last week. Overnight an agent fleet pays 40,000 times at one cent each; the receipts carry transaction hashes she reconciles each morning. A partner wants to stream forecasts per minute, so she adds a session route and caps the suggested deposit. When an advisory about fee payer draining appears, she upgrades mppx, checks her fee wallet balance, and adds a daily ceiling. Her one open worry: refunds on stablecoin charges are her own policy.
Questions, first steps, metrics and a day in the life
Questions they ask
How much can this agent lose in the worst case?
Which channels are still open and how do I close them?
What happens if the server never answers my close?
First three steps
Run the mppx client quick start against the mpp.dev paid ping on testnet
Add a policy extension that rejects unknown recipients
List and close retained sessions with the mppx CLI
Metrics they care about
Spend per task
Open channel count and locked deposit
Rejected challenges by reason
A day in the life
Marco ships a research agent that buys search results and model tokens. He wires mppx into fetch and adds a policy hook that refuses any challenge whose recipient is not on an allowlist or whose amount exceeds two cents. For a model provider the agent opens a Tempo session with a five dollar deposit, so the worst case is five dollars. At the end of each task his code sends a close; a nightly job lists retained channels and force-closes any the server ignored, waiting the full grace period. He never logs credentials, because whoever copies one can spend it.
Settles MPP charges on card and fiat rails: Stripe for the stripe method, or a Client or Server Enabler for the Visa card method. Source [13, 17, 18, 51]
Goals
Bring existing card and wallet acceptance to machine clients
Keep raw card data out of client and server scope
Reuse fraud, tax, refunds and reporting
Pains
Replayed SPT credentials (CVE-2026-34210)
Mapping one challenge to one PaymentIntent or authorization
No published SPT pricing
Implements
PaymentIntent creation with confirm true and an idempotency key from challenge id and SPT
JWE decryption and network authorization as Server Enabler
Network token and cryptogram provisioning as Client Enabler
Must trust
The merchant server to validate the challenge before charging
The card network for authorization and dispute rules
The Client Enabler key handling
Questions, first steps, metrics and a day in the life
Questions they ask
Is this payment card-not-present with agent involvement, and how do disputes work?
What metadata ties a PaymentIntent to its challenge?
Do stablecoin charges carry a percentage fee?
First three steps
Read draft-stripe-charge-00 and draft-card-charge-00
Run the mppx stripe example in test mode
Map PaymentIntent and authorization references into receipts
Metrics they care about
Authorization rate on agent traffic
Dispute rate by method
Duplicate charge incidents
A day in the life
Lena works on acceptance at a payment processor that already serves Visa merchants. Visa's card method lets her team act as a Server Enabler: merchant servers forward an encrypted token they cannot read, her service decrypts it and asks the network for authorization. Card economics and chargebacks stay as they are. On the first week a merchant's buggy client sends the same credential twice; her idempotency checks return the first authorization instead of charging again. She reports authorization rates for agent traffic separately, because nobody yet knows whether it behaves like ordinary card-not-present volume.
The software that pays: reads challenges, chooses a method within its limits, signs, retries and keeps receipts. Source [4, 41]
Goals
Finish the task within budget
Prefer the cheapest acceptable method
Keep proof of every payment
Pains
Challenges that look valid but name the wrong recipient
Descriptions that can say anything
Streams that cut off mid-session
Implements
Accept-Payment preference ordering
Pre-payment checks on amount, currency, recipient and expires
Receipt storage with reference and timestamp
Must trust
Its operator's policy and key custody
The server's challenge binding
The rail's finality
Questions, first steps, metrics and a day in the life
Questions they ask
Is this price within my budget for this task?
Is the challenge still valid?
Did I get a receipt for every paid response?
First three steps
Read the challenge and decode request
Check amount, recipient, currency and expires against policy
Pay through the preferred method and store the receipt
Metrics they care about
Cost per completed task
Receipts per paid response
Rejected challenges
A day in the life
An overnight procurement agent needs ten datasets. For each it requests the file, receives a 402 with two challenges and decodes both. One is a Tempo charge for 0.40 USD to an address its operator approved; the other is a Stripe charge it is not configured to use, so it ignores it. It checks that the challenge expires in four minutes, signs and retries, and stores the receipt hash in its task log. One server asks for 40 USD with a reassuring description. The agent ignores the description, compares the amount with its budget, refuses, and flags the server for its operator.
Builds an independent controls layer (budgets, allowlists, monitoring, kill switches) around MPP clients and servers. Source [4, 7, 27]
Goals
Enforce budgets the protocol does not have
See every payment an agent makes
Stop spending quickly when something goes wrong
Pains
No protocol kill switch or revocation message
Channels without expiry
Identity only as an SDK add-on
Implements
Policy extensions that run before mppx signs
Channel inventory and forced-close automation
Receipt and MPPscan monitoring
Must trust
The SDK hook order
Public chain data for reconciliation
Rail-level limits such as SPT max_amount
Questions, first steps, metrics and a day in the life
Questions they ask
Where can I intercept a payment before it is signed?
How do I prove a payment to an auditor?
How long can a channel stay open unseen?
First three steps
Add an mppx extension that enforces a per-task budget
Export receipts and channel states to a ledger
Alert on open channels older than a set age
Metrics they care about
Blocked versus allowed payments
Open channel value at risk
Time to stop an agent
A day in the life
Sam runs the controls team for a company with 300 agents. MPP gives him clean hooks: every payment starts with a decoded challenge, and mppx runs his extension before it signs. His extension checks a per-agent budget, a recipient allowlist and a maximum price per unit for sessions. A dashboard joins stored receipts with on-chain settlements. The gap he cannot close in policy is time: channels never expire, so his nightly job force-closes channels idle for a day. When an agent misbehaves, he revokes its key at the wallet, because the protocol has no stop button.
Builds Tamarin models of x402, MPP, ACP and AP2 from their specifications, schemas and reference code using one shared abstraction of the agent payment lifecycle, then asks source-backed verification questions to expose missing bindings and cross-stage correspondences, which it consolidates into 18 security principles. Across 86 verification cases it reproduces 46 known or calibration cases, reports 40 new formal-consistency findings, and validates ten of them against x402 implementations with proofs of concept.
Why it matters here: The only side-by-side formal model of x402, stripe-mpp, openai-acp and ap2 so far; it shows where each specification leaves delegated authority, settlement and fulfillment unbound. AP2: Tamarin models that include AP2. ERC-8004: Trustless Agents: Formal models of agent payment protocols around ERC-8004. Agentic Commerce Protocol (ACP): Models ACP in Tamarin with x402, MPP and AP2; the only formal analysis that names it. Stripe MPP (Machine Payments Protocol): Models MPP in Tamarin alongside x402, ACP and AP2; the only formal analysis that names MPP. UCP: Formal analysis of agent payment protocols; the abstract does not name UCP but analyzes AP2, which UCP embeds as an extension. x402: Formal Tamarin models of x402 alongside MPP, ACP and AP2.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jiang2026formal,
title = {{A Formal Analysis of Agent Payment Protocols}},
author = {Ke Jiang and Mohan Yu and Yuan Chang and Mohit Kumar Jangid and Jianyu Niu and Cong Wang and Yinqian Zhang},
year = {2026},
eprint = {2609.00060},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.00060}
}
Proposes A402, a payment architecture that binds cryptocurrency payments to service execution through Atomic Service Channels and TEE-assisted adaptor signatures, so that payment finalizes only if the requested service is executed and delivered, with a TEE-based liquidity vault aggregating channel settlements on chain. Evaluated against x402 on Bitcoin and Ethereum integrations.
Why it matters here: Addresses the end-to-end atomicity gap that x402 leaves open, and connects agent micropayments to the payment-channel lineage. Stripe MPP (Machine Payments Protocol): Binding payment to service execution, the gap MPP's charge intent addresses only by forbidding delivery before verification. x402: Shows that x402 does not bind payment to service execution and proposes Atomic Service Channels.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026a402,
title = {{A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce}},
author = {Yue Li and Lei Wang and Kaixuan Wang and Zhiqiang Yang and Ke Wang and Zhi Guan and Jianbo Gao},
year = {2026},
eprint = {2603.01179},
archivePrefix = {arXiv},
primaryClass = {cs.DC},
url = {https://arxiv.org/abs/2603.01179}
}
Analyzes x402 as a stack of HTTP semantics, per-chain schemes and SDK choices against five invariants and finds four flaw classes: cross-resource substitution, duplicate-settlement races, allowance overdraft and denial of settlement, reaching resource-leakage ratios up to 100% against official SDKs and a production deployment. It also proves that output-only pay-per-token pricing cannot be both fair and bounded against hidden reasoning-token inflation, and proposes mitigations with provable guarantees.
Why it matters here: Explains the state-synchronization gap between synchronous HTTP and asynchronous settlement that is specific to x402-style rails. Stripe MPP (Machine Payments Protocol): x402 free-riding attacks that map onto MPP charge implementations. x402: Four flaw classes, including cross-resource substitution and a duplicate settlement race.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ling2026freeriding,
title = {{Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments}},
author = {Shengchen Ling and Yihang Huang and Yuefeng Du and Yuan Chen and Yajin Zhou and Lei Wu and Cong Wang},
year = {2026},
eprint = {2605.30998},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2605.30998}
}
A vision paper arguing that once buyers are agents paying over agent-native rails such as x402 and AP2, the scarce resource becomes trustworthy product information rather than product matching. It sketches a market in which buyer agents pay fractions of a cent to unlock seller- and reviewer-supplied evidence, with reviewer trust scored reputationally, and lists the NLP problems this creates.
Why it matters here: Names x402 and AP2 directly as the rails that make per-fact micropayments feasible, and ties paid information to the reputation scoring that ERC-8004 registries aim to provide. Stripe MPP (Machine Payments Protocol): Micro-transaction markets for product information, a use case for per-request MPP charges.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ventirozos2026paying,
title = {Paying to Know: Micro-Transaction Markets for Verified Product Information in Agentic E-Commerce},
author = {Filippos Ventirozos and Matthew Shardlow},
year = {2026},
eprint = {2606.24783},
archivePrefix = {arXiv},
primaryClass = {cs.CL},
url = {https://arxiv.org/abs/2606.24783},
note = {arXiv preprint}
}
Systematizes blockchain-based agent-to-agent payments, with x402 as the lead example, into a four-stage lifecycle of discovery, authorization, execution and accounting, classifies representative designs at each stage, and isolates recurring weaknesses: weak intent binding, misuse under valid authorization, payment-service decoupling and limited accountability.
Why it matters here: Gives a lifecycle vocabulary for x402 and for the discovery role that erc-8004 registries are meant to fill, and names the payment-service decoupling problem that later x402 attack papers exploit. ERC-8004: Trustless Agents: Survey that places ERC-8004 among agent payment components. Stripe MPP (Machine Payments Protocol): Systematizes blockchain agent-to-agent payments; does not name MPP but covers the Tempo-style rails. x402: Systematizes blockchain agent-to-agent payments, with x402 as a central case.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhang2026sok,
title = {{SoK: Blockchain Agent-to-Agent Payments}},
author = {Yuanzhe Zhang and Yuexin Xiang and Yuchen Lei and Qin Wang and Tian Qiu and Yujing Sun and Spiridon Zarkov and Tsz Hon Yuen and Andreas Deppeler and Jiangshan Yu and Kwok-Yan Lam},
year = {2026},
eprint = {2604.03733},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2604.03733}
}
A systematization of knowledge that frames the security of autonomous LLM agents in commerce along five dimensions (agent integrity, transaction authorization, inter-agent trust, market manipulation, regulatory compliance), derives 12 cross-layer attack vectors from a curated corpus of papers, protocol documents, industry reports and incidents, and proposes a layered defense for the authorization gaps in current agent payment protocols. The ACP it lists is written 'Agent Commerce Protocol', which may not be OpenAI's Agentic Commerce Protocol; that mapping is unconfirmed.
Why it matters here: Places erc-8004, ap2, x402 and stripe-mpp in one threat framework and argues that their authorization gaps compound across the reasoning, tooling, custody and settlement layers. AP2: Places AP2 among agent commerce attack vectors. Stripe MPP (Machine Payments Protocol): Includes MPP in its protocol set for agent commerce security. x402: Security SoK of agentic commerce that covers x402.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{mao2026sok,
title = {{SoK: Security of Autonomous LLM Agents in Agentic Commerce}},
author = {Qian'ang Mao and Jiaxin Wang and Ya Liu and Li Zhu and Cong Ma and Jiaqi Yan},
year = {2026},
eprint = {2604.15367},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2604.15367}
}
Proposes Sprites, a payment channel construction for smart-contract chains that cuts the worst-case time collateral is locked along a multi-hop route and supports partial deposits and withdrawals without closing the channel. It also gives a modular treatment of general state channels.
Why it matters here: A key reference for channel designs on Ethereum-style chains, where x402 settles; it explains the collateral and dispute costs any channel-based agent payment scheme must budget for. Stripe MPP (Machine Payments Protocol): Payment channel foundations behind MPP sessions.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{miller2017sprites,
title = {{Sprites and State Channels: Payment Networks that Go Faster than Lightning}},
author = {Andrew Miller and Iddo Bentov and Ranjit Kumaresan and Christopher Cordi and Patrick McCorry},
year = {2017},
eprint = {1702.05812},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/1702.05812}
}
Joseph Poon, Thaddeus Dryja. 2016. Not peer reviewed
The white paper (draft version 0.5.9.2, dated 2016-01-14) for a network of bidirectional payment channels in which transfers happen off chain and are routed across channels with hashed timelock contracts, so only channel opening and closing touch the blockchain.
Why it matters here: Payment channels are the main route to cheap, fast repeated payments; the deferred and session schemes discussed for x402 and MPP inherit the channel model this paper popularized. Stripe MPP (Machine Payments Protocol): Foundation for the lightning method and for cumulative channel updates.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{poon2016lightning,
title = {{The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments}},
author = {Joseph Poon and Thaddeus Dryja},
year = {2016},
howpublished = {White paper, draft version 0.5.9.2},
note = {Not peer reviewed},
url = {https://lightning.network/lightning-network-paper.pdf}
}
Adapts probabilistic micropayments to decentralized currencies such as Bitcoin, designing schemes where a payer issues lottery-style tickets and only winning tickets are settled on chain, with protections against a payer who double-spends the escrow.
Why it matters here: Links the 1990s micropayment literature to blockchain settlement, the setting in which x402 operates and in which MPP offers on-chain payment methods. Stripe MPP (Machine Payments Protocol): Micropayments for decentralized currencies.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{pass2015decentralized,
title = {{Micropayments for Decentralized Currencies}},
author = {Rafael Pass and abhi shelat},
year = {2015},
booktitle = {Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security},
pages = {207--218},
publisher = {ACM},
doi = {10.1145/2810103.2813713},
url = {https://doi.org/10.1145/2810103.2813713}
}
Proposes paying for many small items with electronic lottery tickets: each ticket wins a larger payment with small probability, so the expected value equals the price while the number of real transactions drops sharply.
Why it matters here: Probabilistic payment is one of the standing answers to per-request fees that are smaller than settlement cost, a problem x402 and MPP face whenever an agent buys thousands of cheap API calls. Stripe MPP (Machine Payments Protocol): Probabilistic micropayments, an alternative to channels.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{rivest1997lottery,
title = {{Electronic lottery tickets as micropayments}},
author = {Ronald L. Rivest},
year = {1997},
booktitle = {Financial Cryptography},
series = {Lecture Notes in Computer Science},
pages = {307--314},
publisher = {Springer},
doi = {10.1007/3-540-63594-7_87},
url = {https://doi.org/10.1007/3-540-63594-7_87}
}
Introduces two micropayment schemes: PayWord, where a user commits to a hash chain and pays by revealing successive hash values, and MicroMint, where coins are hash collisions that are cheap to verify but costly to mint at scale. Both aim to make each payment far cheaper than a public-key signature.
Why it matters here: The hash-chain idea behind PayWord is the template for streaming and session payments; MPP sessions and payment channels used with x402 apply the same principle of one setup and many cheap increments. Stripe MPP (Machine Payments Protocol): Cumulative micropayment tokens, an ancestor of cumulative vouchers.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{rivest1997payword,
title = {{PayWord and MicroMint: Two simple micropayment schemes}},
author = {Ronald L. Rivest and Adi Shamir},
year = {1997},
booktitle = {Security Protocols},
series = {Lecture Notes in Computer Science},
pages = {69--87},
publisher = {Springer},
doi = {10.1007/3-540-62494-5_6},
url = {https://doi.org/10.1007/3-540-62494-5_6}
}
Steve Glassman, Mark Manasse, Martín Abadi and others. 1995. Fourth International World Wide Web Conference (WWW4). Peer reviewed
Describes Millicent, a protocol for web purchases below one cent in which brokers sell vendor-specific scrip that each vendor can validate locally, without extra network round trips or heavy cryptography. Brokers handle accounts and billing so vendors and customers do not need direct financial relationships.
Why it matters here: The direct ancestor of pay-per-request web payments: x402 and MPP revisit the same goal of charging tiny amounts per HTTP resource, with stablecoins and facilitators in the broker role.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@inproceedings{glassman1995millicent,
title = {{The Millicent Protocol for Inexpensive Electronic Commerce}},
author = {Steve Glassman and Mark Manasse and Martín Abadi and Paul Gauthier and Patrick Sobalvarro},
year = {1995},
booktitle = {Fourth International World Wide Web Conference},
address = {Boston, MA, USA},
url = {https://www.w3.org/Conferences/WWW4/Papers/246/}
}
Presents a fraud taxonomy for agents with spend authority organized by five observation levels, a benchmark of twenty fraud classes built from production aggregates (1,647 service operations and 1,068 settlements), and gordonguard, an open-source detector stack. Calibrated detectors flag 6.5 percent of clean traffic and leave eight classes at chance, and a median payment of $0.007 makes one human review 143 times costlier than the payment it checks.
Why it matters here: Targets fraud on machine-to-machine rails such as x402 and MPP, where a counterparty can be exactly who it claims to be and still overcharge, and shows why identity checks alone, including ERC-8004 identity, do not stop value loss.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{srivastava2026acb,
title = {Agentic Commerce Bench: Measuring Fraud Detection for Agents That Spend Money},
author = {Ankit Srivastava and Debjyoti Paul},
year = {2026},
eprint = {2609.35886},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.35886},
note = {arXiv preprint}
}
AID-Guard closes the gap between authorization at admission and the provider effect that follows: it revalidates the approved request and provider state at commit, holds one reservation under ambiguity, and releases a successor only after a terminal result or a certified no-effect, so one approval yields at most one effect across retries and recovery. A prototype was tested against Stripe and Resend provider contracts, with all 210 Stripe trials matching predeclared outcomes.
Why it matters here: Exactly-once effects and idempotency are the operational core of agent payments; this is an evaluated protocol that treats a Stripe charge as a delegated effect with its own lifecycle, relevant to MPP and ACP implementations.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{tong2026aidguard,
title = {AID-Guard: Stateful Authorization for Delegated Agent Effects},
author = {Yingzhe Tong and Leyu Dai and Songhui Guo},
year = {2026},
eprint = {2608.21159},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.21159},
note = {arXiv preprint}
}
Introduces blind signatures, where a signer signs a message without seeing it, and uses them to build payments that the bank can verify but cannot link back to the payer.
Why it matters here: The origin of private digital cash; it frames the privacy trade-off in agent payments, where x402 settles on public ledgers and card-based agent payments expose purchase data to the networks.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{chaum1983blind,
title = {{Blind Signatures for Untraceable Payments}},
author = {David Chaum},
year = {1983},
booktitle = {Advances in Cryptology},
pages = {199--203},
publisher = {Springer},
doi = {10.1007/978-1-4757-0602-4_18},
url = {https://doi.org/10.1007/978-1-4757-0602-4_18}
}
A survey tracing market microstructure from floor trading through electronic order books, batch auctions, dark pools and blockchain automated market makers to AI agents that discover, pay for and compete over resources, organized around whether a market can allocate efficiently without participants revealing everything. It argues that allocation is the missing layer of the agent-commerce protocol stack.
Why it matters here: Positions payment protocols such as x402 and MPP as settlement without allocation, and names extractable value and algorithmic collusion as the next problems for agent markets.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{aldridge2026microstructure,
title = {Evolution of Market Microstructure in the Age of AI},
author = {Irene Aldridge},
year = {2026},
eprint = {2609.33058},
archivePrefix = {arXiv},
primaryClass = {econ.EM},
url = {https://arxiv.org/abs/2609.33058},
note = {arXiv preprint}
}
Argues from pricing history that people prefer flat-rate and bundled pricing over metered charges, and that the mental cost of deciding on each tiny payment is the main obstacle to micropayments, not the technology.
Why it matters here: The classic objection to pay-per-use pricing; agent payments may sidestep it because software, not a person, makes each spending decision, which is the core bet behind x402 and MPP. Stripe MPP (Machine Payments Protocol): The classic critique of per-unit pricing; useful against the falling average MPP payment size.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{odlyzko2003against,
title = {{The Case Against Micropayments}},
author = {Andrew Odlyzko},
year = {2003},
booktitle = {Financial Cryptography},
series = {Lecture Notes in Computer Science},
pages = {77--83},
publisher = {Springer},
doi = {10.1007/978-3-540-45126-6_6},
url = {https://doi.org/10.1007/978-3-540-45126-6_6}
}
Specifies terms.txt, a robots.txt-style file for per-path, per-purpose machine-access terms, and an origin-enforced exchange combining Web Bot Auth signatures, signed intent, delegation tokens, HTTP 402 negotiation and signed receipts, with a dependency-free implementation adding 0.20 to 0.65 ms per request. The arXiv comment reports submission to IEEE Internet Computing; it is not accepted as of the arXiv record.
Why it matters here: Combines the Web Bot Auth signatures that visa-tap builds on with HTTP 402 negotiation in the style of x402 and stripe-mpp, for content access rather than checkout.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{chowdhury2026termstxt,
title = {{terms.txt: A Consent and Compensation Protocol for Agentic Web Access}},
author = {Rajarshi Chowdhury},
year = {2026},
eprint = {2609.11152},
archivePrefix = {arXiv},
primaryClass = {cs.NI},
url = {https://arxiv.org/abs/2609.11152}
}
Grey literature: central banks, standards drafts and white papers
Visa, Artemis. 2026. Visa and Artemis joint research report. Not peer reviewed
A joint report (summary page last updated 2026-07-14) that splits agentic commerce into agent purchases on behalf of people and small machine-to-machine payments, and measures x402 at about $15.0 million adjusted volume over 109.6 million transactions and MPP at about $25,000 over 115,000 transactions, using Artemis data as of 2026-04-21.
Why it matters here: The main vendor-published measurement of x402 and MPP volumes; the adjusted figures exclude activity Artemis classed as wash or test traffic, and they are self-reported, not independently audited.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{visa2026groundup,
title = {{Agentic Payments from the Ground Up: What the Onchain Data Tells Us}},
author = {{Visa} and {Artemis}},
year = {2026},
howpublished = {Visa},
note = {Research report with Artemis; data as of 2026-04-21},
url = {https://www.visa.com/en-us/thought-leadership/innovation/agentic-payments-from-the-ground-up}
}
B. Ryan, J. Moxey, T. Meagher and others. 2026. IETF Internet-Draft draft-httpauth-payment-01. Not peer reviewed
Revision 01 (2026-09-09) of the draft behind the Machine Payments Protocol, written by authors from Tempo Labs and Stripe. It defines a "Payment" HTTP authentication scheme that uses the 402 status code to issue payment challenges and stays agnostic to payment method through registered method identifiers.
Why it matters here: The core MPP specification in IETF form; comparing it with x402, which also uses HTTP 402, shows the two designs for pay-per-request access.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{ryan2026httpauthpayment,
title = {{The "Payment" HTTP Authentication Scheme}},
author = {B. Ryan and J. Moxey and T. Meagher and J. Weinstein and S. Kaliski},
year = {2026},
howpublished = {Internet-Draft draft-httpauth-payment-01, IETF},
note = {Work in progress, 2026-09-09},
url = {https://datatracker.ietf.org/doc/draft-httpauth-payment/}
}
Bank for International Settlements. 2025. BIS Annual Economic Report 2025, chapter III. Not peer reviewed
Argues that tokenized platforms built around central bank reserves, commercial bank money and government bonds can form the next monetary system, and that stablecoins fail the three tests of singleness, elasticity and integrity needed to be its mainstay. Published 2025-06-29.
Why it matters here: x402 and the on-chain MPP methods settle mostly in stablecoins; this chapter is the leading central bank critique of that settlement asset.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@incollection{bis2025aerch3,
title = {{The next-generation monetary and financial system}},
author = {{Bank for International Settlements}},
year = {2025},
booktitle = {Annual Economic Report 2025},
chapter = {III},
publisher = {Bank for International Settlements},
month = {jun},
url = {https://www.bis.org/publ/arpdf/ar2025e3.htm}
}
MPP binds every challenge parameter to its id, makes ids and proofs single use, forbids side effects before payment and requires TLS, so tampering and replay are covered at protocol level. What it leaves to clients is deciding whether a challenge is honest, because a malicious server can bind a bad price as easily as a good one. Credentials are bearer tokens. Loss limits, refunds and disputes come from the rail. The worst incidents so far were SDK bugs, not protocol flaws: four mppx advisories and one Rust advisory in 2026, all fixed.
STRIDE threats (12)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Malicious or spoofed server asks for the wrong paymentA server, a mirror or an injected tool result issues a validly bound challenge that names its own recipient or an inflated amount, with a reassuring description. Source [4, 41]Preconditions: The client pays whatever a challenge asks; No recipient allowlist or price ceiling.Impact: The client pays the attacker; on-chain charges are final.
Partly
Binding only protects a challenge after the server issues it. Clients must check amount, recipient, currency and expires and ignore description, as the core requires; enforce an allowlist before signing.
S Spoofing
Spoofed discovery metadataDiscovery documents are unauthenticated, so an attacker publishes /openapi.json data with false prices or methods to lure agents. Source [15]Preconditions: Client trusts x-payment-info for decisions.Impact: Agents route to an attacker or overpay.
Mitigated by spec
Discovery is advisory and must not drive security decisions; the 402 challenge is authoritative.
T Tampering
Replay of a consumed challenge or proofThe same credential is sent twice, concurrently or later, to obtain service twice or to settle twice. Source [4, 47, 48]Preconditions: Server does not record consumed ids atomically; Method proof not checked for single use.Impact: Free service or double charge.
Mitigated by spec
Ids are single use and methods must give single-use proofs; concurrent duplicates must settle at most once. mppx and the Rust SDK had replay bugs fixed in 0.4.8, 0.4.11 and 0.8.0.
T Tampering
SPT replay through Stripe idempotencyA stripe/charge implementation ignores Stripe's Idempotent-Replayed signal, so one SPT credential pays for several new challenges. Source [17, 51]Preconditions: Server mppx before 0.4.11; Idempotency key not tied to the challenge.Impact: Seller delivers several times for one payment (CVE-2026-34210).
Partly
Use the idempotency key built from challenge id and SPT, treat Idempotent-Replayed as a replay, and upgrade mppx.
T Tampering
Body swapped after paymentA credential for a cheap request body is replayed with a different, more expensive body. Source [4]Preconditions: Challenge issued without digest; Non-idempotent request.Impact: Client gets more than it paid for, or the server does work it did not price.
Partly
Use the digest parameter (RFC 9530) for requests with bodies and an Idempotency-Key.
R Repudiation
Disputed delivery after an on-chain chargeThe client says it never got the resource; on stablecoin rails there is no chargeback and the receipt only proves payment. Source [41, 42]Preconditions: Stablecoin method; Server returned an error after settling.Impact: Payer bears the loss unless the seller refunds voluntarily.
Partly
The charge intent forbids partial delivery before verification; keep receipts and logs and publish a refund policy. Card routes keep chargebacks.
I Information disclosure
Leaked bearer credential is spent by someone elseA credential copied from logs, an error message, analytics or a proxy is presented before the legitimate client uses it. Source [4]Preconditions: Credential logged or exposed in transit; Challenge still outstanding.Impact: Whoever presents it first gets the paid resource; the payer has paid for someone else.
Partly
The core forbids logging credentials and requires TLS 1.2 or later. Keep credentials in memory only and use short expires values.
I Information disclosure
Shared cache stores a paid responseA proxy or CDN caches a response to a request that used Payment-Authorization, which RFC 9111 does not protect the way it protects Authorization. Source [4]Preconditions: Intermediary caches by default; Server omits Cache-Control.Impact: Paid content and receipts are served to other users.
Mitigated by spec
Send no-store on 402 and private on receipts and on any response to a Payment-Authorization request.
I Information disclosure
Public settlement reveals payer and payeeTempo and other chain methods settle on public ledgers that explorers index. Source [4, 43, 44]Preconditions: Chain-based method.Impact: Spending patterns and counterparties are visible.
Left to implementers
Use fresh addresses or card and Stripe methods where privacy matters; the core only asks methods to support pseudonymous options.
D Denial of service
Fee payer gas drainingWhen the server sponsors fees, an attacker pads calldata or adds access lists so each sponsored transaction burns more gas than the policy expected. Source [16, 47]Preconditions: feePayer true; Server mppx before 0.8.2.Impact: Server's fee wallet drains (CVE-2026-63627, CVE-2026-63628).
Left to implementers
Cap calldata size and reject access lists for sponsored transactions; set a daily ceiling on the fee wallet.
D Denial of service
Channel liabilities that never endChannels and vouchers have no expiry, so deposits stay locked and unsettled vouchers stay claimable until someone closes the channel. Source [27]Preconditions: Client forgets to close; Server disappears.Impact: Locked funds; late claims surprise the payer.
Partly
Servers should close idle channels; clients should track channels and force-close, waiting at least 16 minutes after requestClose.
E Elevation of privilege
Session close voucher accepted at the settled amountA close voucher equal to, not above, the settled amount was accepted, so an attacker could close or grief a channel for free. Source [27, 49]Preconditions: Server mppx before 0.4.11.Impact: Payee loses unsettled earnings or the channel is closed against its will (CVE-2026-34209).
Left to implementers
Implementation bug, fixed in mppx 0.4.11; servers must compare with less-than-or-equal and capture max(spent, settled) on close.
Attack scenarios
A tool result names a different recipient Source [4, 41]
Preconditions: An agent reads 402 responses relayed by a third-party tool; No recipient allowlist.
The tool rewrites the challenge from its own server, binding its own recipient
The agent sees a valid challenge and signs a Tempo transfer
The attacker's server returns a receipt for nothing
Impact: Loss of the payment; no protocol refund on chain.
Fee wallet drained through sponsored transactions Source [16, 47]
Preconditions: Server offers feePayer true; mppx below 0.8.2.
Attacker requests many challenges
Each transaction it signs carries padded calldata or a large access list
The server co-signs and pays inflated fees
Impact: The server's fee balance is spent without matching revenue.
Preconditions: Open channel with a deposit; Server stops answering.
The client's close request times out
The client calls requestClose on chain
The server, if alive, can still settle its newest voucher during the grace period
After at least 15 minutes the client calls withdraw and recovers the rest
Impact: Funds locked for the grace period; the payer loses at most what the server can still settle with vouchers it holds.
Published research findings
A Formal Analysis of Agent Payment Protocols: Tamarin models of x402, MPP, ACP and AP2 with 40 previously undocumented formal-consistency findings across the four; the abstract does not break them out per protocol. (paper in section G) Source [52]
Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments: Attacks on x402 payment binding and delivery that apply by analogy to MPP charge implementations; the paper does not name MPP. (paper in section G) Source [68]
SoK: Security of Autonomous LLM Agents in Agentic Commerce: A systematization of agent commerce threats that includes MPP in its protocol set. (paper in section G) Source [67]
CVEs and advisories
CVE-2026-63627 severity medium: GHSA-727h-3vm5-qwq6: fee payer gas draining by calldata padding in mppx; fixed in 0.8.2. VerifiedSource [47]
CVE-2026-63628 severity medium: GHSA-vc9j-9wph-qghj: fee payer gas draining with access lists in mppx; fixed in 0.8.2. VerifiedSource [47]
GHSA-fxc9-7j2w-vx54 severity critical: Critical advisory for the Rust crate mpp before 0.8.0: free and replayed charges, griefed sessions, fee payer manipulation and replayed stripe charges. No CVE id. VerifiedSource [48]
GHSA-8x4m-qw58-3pcx severity critical: Critical mppx advisory (before 0.4.8): several tempo/charge and tempo/session bypasses, including hash replay across modes and routes, free pull-mode charges, fee payer manipulation and voucher signature bypass. No CVE id. VerifiedSource [47]
CVE-2026-34209 severity high: GHSA-mv9j-8jvg-j8mr: mppx before 0.4.11 accepted a session close voucher equal to the settled amount, closing or griefing a channel for free. Fixed in 0.4.11; NVD published 2026-03-31. VerifiedSource [49, 50]
CVE-2026-34210 severity medium: GHSA-8mhj-rffc-rcvw: mppx before 0.4.11 ignored Stripe's Idempotent-Replayed header, so one SPT credential could be replayed. Fixed in 0.4.11; NVD published 2026-03-31. VerifiedSource [50, 51]
MPP natively binds payee and amount, makes challenges single use, and returns receipts. Budgets, consent, identity, revocation and disputes come from rails or from tools around the protocol. The best places for an independent controls layer are the client just before the SDK signs (mppx runs extensions there), the session channel inventory, and receipt reconciliation after the fact.
The core payment is pseudonymous with an optional DID source; mppx adds RFC 9421 request attestation for Web Bot Auth and Visa TAP, and the card method allows optional TAP headers. Source [4, 18, 35]
Agent registration (know your agent)
None
The core forbids requiring accounts for payment; any know-your-customer step belongs to a method (the stripe method needs Stripe accounts on both sides). Source [4, 17]
User consent capture
Partial
Browser wallets should show the origin and ask for explicit confirmation; SPT creation may prompt 3DS or biometrics. No user mandate object. Source [4, 17]
Spending caps
Partial
Caps come from the rail: the session deposit, SPT usage limits, Tempo access key limits. The core has none. Source [17, 27, 46]
Merchant or payee scoping
Native
recipient and realm are bound into the challenge id; SPTs are scoped to the seller networkId; v2 session descriptors must match the payee. Source [4, 17, 27]
Time windows and expiry
Partial
Challenges carry expires, subscriptions subscriptionExpires and SPTs expires_at, but session channels and vouchers never expire. Source [4, 27, 45]
Revocation
Partial
No core revocation message; subscriptions cancel by method-specific means and a payer can force-close a channel. Source [27, 45]
Step-up authentication
External
Method-specific: Stripe may prompt 3DS while creating an SPT; card methods carry network cryptograms. Source [17, 18]
Replay protection
Native
Single-use challenge ids and proofs, Idempotency-Key, digest binding, and channel and EIP-712 domain binding in sessions. Source [4, 27]
Receipts and evidence
Native
Payment-Receipt with a method reference on every paid response; session receipts add spent and acceptedCumulative, plus a final SSE event. Source [4, 27]
Dispute support
External
Depends on the rail: card and stripe routes keep chargebacks; Stripe stablecoin payments have no disputes; on-chain charges are final. Source [41, 42]
Reputation
None
No reputation layer; the discovery draft only mentions future on-chain anchoring compatible with ERC-8004. Source [15]
Monitoring signals
Partial
Public explorer data (MPPscan, Tempo chain) and the Stripe Dashboard for Stripe-settled payments; servers should rate-limit. Source [2, 4, 44]
Kill switch
None
No protocol stop; a payer stops signing or force-closes, and an operator revokes keys at the wallet or disables a Stripe account. Source [27]
No user mandate. MPP has no object that records what a user allowed an agent to buy; AP2 or wallet policy must supply it. Source [4, 33]
No protocol budget. Limits exist only in rails (deposit, SPT, access keys) and SDK hooks. Source [17, 27]
Identity is an add-on. Request attestation is an mppx feature, not part of the core draft. Source [4, 35]
Channels without expiry. Open channels and unsettled vouchers persist until closed. Source [27]
Rail-dependent disputes. Stablecoin charges have no chargeback; refunds are seller policy. Source [41, 42]
Where an independent controls layer can act
Before authorization
Decide whether to pay: recipient allowlists, price ceilings, method preference. Accept-Payment ordering plus a policy check on the decoded challenge; mppx extensions run before signing. Source [4, 7]
At signing
Bound the worst case. Small session deposits, SPT usage limits, Tempo access key limits, short expires. Source [17, 27, 46]
At the edge
Recognize and rate-limit agents. Web Bot Auth or TAP attestation through mppx; Retry-After; 403 for policy denials after valid payment. Source [4, 35]
At settlement
Screen and reconcile. Stripe fraud tools for Stripe-settled payments; TIP-20 policy registry allow and block lists on Tempo. Source [2, 69]
After the fact
Audit and close. Store receipts, reconcile with chain data or the Stripe Dashboard, force-close idle channels. Source [4, 27, 44]
Implementer checklist
Check amount, recipient, currency and expires before paying; ignore description. Binding does not stop a dishonest server. Source [4]
Never log credentials; keep them in memory. They are bearer tokens. Source [4]
Send no-store on 402 and private on paid responses. Shared caches do not protect Payment-Authorization. Source [4]
Run mppx 0.8.2 or later (Rust mpp 0.8.0 or later). Earlier versions have published bypasses. Source [47, 48]
Cap session deposits and track every open channel. Channels never expire; the deposit is the worst case. Source [27]
Cap fee payer spend. Sponsored fees were drained in 2026 advisories. Source [47]
Use digest for requests with bodies. Ties the payment to the exact request. Source [4]
J. Compliance and regulation
Not legal advice. This is a study summary of public rules as of the dates cited. Ask counsel about your situation.
MPP mixes rails, so the rules follow the method. Card and Stripe methods inherit card law, PSD2 strong customer authentication and network rules; Tempo and other stablecoin methods inherit stablecoin, anti-money-laundering, travel rule and sanctions rules. The core itself has no identity or screening layer and forbids requiring accounts for payment, which pushes screening duties onto the parties that settle. Rows are dated; check each source before relying on it.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
Card charges through the stripe or card method fall under Regulation Z, which caps cardholder liability for unauthorized use at 50 USD and turns on actual, implied or apparent authority, a test agent payments make harder. Source [17, 75]
Verified
United States
Regulation E covers unauthorized electronic fund transfers from accounts; whether a Tempo wallet transfer counts is unclear, and Stripe stablecoin payments have no disputes. Source [42, 76]
Verified
United Kingdom
The UK Payment Services Regulations 2017 tie liability to consent (regulation 67) and limit payer liability for unauthorized transactions (regulation 77), which applies to card-based MPP charges. Source [86, 87]
Verified
Canada
The Retail Payment Activities Act has been fully in force since 2025-09-08, bringing payment service providers under Bank of Canada supervision. Source [92]
Verified
Card network rules
Card routes keep network rules: the card method carries an encrypted network token authorized by a Server Enabler, and card economics are unchanged; no MPP-specific card pricing or liability rule was published. Source [18, 30]
Reported
AML and sanctions
United States
The MPP core has no KYC or sanctions layer and must not require accounts for payment. OFAC says sanctions obligations are the same for digital and fiat currency transactions, so sellers and settling parties screen on their own. Source [4, 73]
Verified
United States
FinCEN guidance FIN-2019-G001 treats hosted wallet providers as money transmitters; how it applies to an MPP server that only receives payer-signed transfers is not addressed. Source [74]
Reported
European Union
The Transfer of Funds Regulation (EU) 2023/1113 applies the travel rule to crypto-asset transfers between providers. MPP credentials carry only an optional payer DID, so originator data must come from the providers. Source [4, 79]
Verified
United Kingdom
The UK Money Laundering Regulations 2017 cover cryptoasset businesses and the travel rule, which reaches providers that settle MPP stablecoin payments for UK customers. Source [85]
Verified
Stablecoin rules
United States
Tempo charges settle in TIP-20 stablecoins. The GENIUS Act (Public Law 119-27, 2025-07-18) regulates payment stablecoins and takes effect on the earlier of 2027-01-18 or 120 days after final regulations. Source [69, 70]
Verified
United States
As of 2026-10-11 only proposed GENIUS Act rules were found; the OCC said it aimed to finalize by November 2026. Source [71, 72]
Reported
European Union
MiCA applies to e-money tokens and crypto-asset service providers; its transitional period for providers ended on 2026-07-01, which matters for stablecoin methods offered to EU users. Source [77, 78]
Verified
Canada
Canada's Stablecoin Act in Bill C-15 received Royal Assent on 2026-03-26 and is expected to take effect in 2027. Source [90, 91]
Verified
Singapore
Digital payment token services need a license under the Payment Services Act 2019 (statute text not read directly), and MAS has a finalized framework for single-currency stablecoins. Source [93, 94]
Reported
Strong customer authentication
European Union
Card charges inside the EU fall under PSD2 strong customer authentication and its RTS; the stripe method may trigger 3DS while the SPT is created, before any MPP request. Source [17, 80, 81]
Verified
AI-specific rules
European Union
AI Act Article 50 transparency duties apply from 2026-08-02, and the Digital Omnibus (Regulation (EU) 2026/1744) moved Annex III high-risk obligations to 2027-12-02. Nothing in it is specific to agent payments. Source [82, 83]
Verified
United Kingdom
The FCA payments priorities (2026-03-25) include agentic AI, and HM Treasury consulted on modernising payment services regulation from 2026-07-14 to 2026-10-06. Source [88, 89]
Verified
Singapore
MAS issued Guidelines on AI Risk Management for financial institutions on 2026-10-07, effective 2027-10-07, and plans to consult on agentic AI guidance in 2027. Source [95, 96]
Verified
Data protection
European Union
GDPR covers online identifiers. Card credentials in the card method can carry billing address, cardholder name and payment account reference, and public chain settlement exposes addresses. Source [18, 84]
Verified
Card network rules
The stripe method keeps raw card data away from client and server, and the card method encrypts the token so neither can parse it, which the specs say reduces PCI DSS scope. Source [17, 18]
Verified
K. Observability lens
3 of 5 observability score
Tempo settlement is public on chain and a transaction hash comes back in every Tempo receipt.
MPPscan indexes servers, agents, transactions and volume, and its stats endpoint is public.
The mpp.dev services directory is public JSON.
Challenges, credentials and receipts travel only between client and server; Stripe and card payments are visible only to the parties.
The specs define no .well-known path and discovery documents are optional and unauthenticated.
Publicly observable
Public signals
What
Where
How
Tempo charge and session settlements
Tempo mainnet (chain 4217) and its explorer
TIP-20 transfers and escrow calls (open, settle, topUp, close, requestClose, withdraw); receipt reference is the transaction hash or channelId. Source [4, 27, 43]
WWW-Authenticate, Authorization and Payment-Receipt contents. Bilateral between client and server over TLS; credentials must never be logged.
Stripe-settled MPP payments. Appear in the seller's Stripe API and Dashboard only.
Card authorizations through the card method. Visible only to the enablers, network and issuer; the token is encrypted end to end.
Session vouchers before settlement. Off-chain; only the newest settled amount reaches the chain.
Subscription state and cancellation. Held by the server; the specs define no public subscription registry.
What an indexer or monitor could capture
Tempo charge payments from TIP-20 Transfer and TransferWithMemo events to known MPP recipients: transaction hash, payer address, recipient address, memoSource [16, 44]
Session channels from Escrow or precompile calls open, topUp, settle, close, requestClose, withdraw: channelId, payer, payee, deposit, settled amountSource [27]
Service catalog from mpp.dev/api/services and /openapi.json crawls: service URL, methods, intents, pricesSource [15, 56]
Tempo Labs: Co-author of the core (three of five authors) and of most intent, transport and Tempo method drafts; runs mpp.dev. Source [1, 4]
Stripe: Co-author of the core (two authors) and of the stripe methods; settles MPP payments in its platform. Source [2, 4]
Rail authors: Visa (card), Lightspark (lightning), Circle (usdc), Coinbase, MegaETH Labs and Monad Foundation (evm charge), OKG (evm session), Solana Foundation, Stellar Development Foundation, Hedera, Near One and Ripple maintain their methods. Source [3, 18, 19, 20, 24]
Implementers and deployments
Implementers (9)
Name
Role
Status
Stripe (MPP acceptance with deposit addresses and SPTs)
Accepts MPP payments in stablecoins and cards, Klarna and Affirm through SPTs; docs labeled Frontier. Source [13, 59]
Beta
Tempo mainnet
Default settlement chain; mainnet since 2026-03-18. Source [8, 43]
Live
Visa (mpp-card SDK)
Card method author and design partner for cards. Source [30, 97]
npmmppx (external link) version 0.13.4: TypeScript SDK by wevm, MIT; server, client, CLI, proxy; serves x402 too since 0.9.0. Version as of 2026-10-11.
PyPIpympp (external link) version 0.11.0: Python SDK by tempoxyz. Version as of 2026-10-11.
crates.iompp (external link) version 0.15.0: Rust SDK (tempoxyz/mpp-rs). Version as of 2026-10-11.
MPPscan's count of MPP payments, mostly on Tempo. Source [44] Caveat: Indexer's own definition; includes test and self-dealing traffic it cannot filter. A June 2026 article shows the same live figure, so it is not a June value.
MPPscan volume, all time
435,476 USD
Sum of indexed payment values. Source [44] Caveat: About 0.11 USD per transaction on average.
MPPscan unique senders and recipients, all time
224,244 / 6,101 addresses
Distinct sending and receiving addresses. Source [44] Caveat: Addresses, not agents or businesses.
MPPscan last 30 days
998,771 transactions; 8,774 USD transactions and USD
Rolling 30-day window. Source [44] Caveat: Under one cent per transaction, which points to many tiny or test payments.
MPPscan last 7 days (homepage default)
126,902 transactions; 1,484 USD transactions and USD
Rolling 7-day window shown by default on the homepage. Source [44] Caveat: Do not read the homepage numbers as all-time totals.
mpp.dev directory services
129 services
Listings in mpp.dev/api/services; 126 accept tempo, 10 stripe, 1 evm. Source [56] Caveat: A listing, not usage.
about 25,000 USD over about 115,000 transfers USD and transfers
Cumulative to 2026-04-21 as reported. Source [100] Caveat: Secondary report (Forkast, 2026-07-20); about 0.22 USD each.
GitHub stars
mpp-specs 95; mppx 186 stars
Stars on the two main repositories. Source [7, 9] Caveat: Interest, not usage.
Costs
Costs, who pays them, and how sure we are
Item
Value
Who pays
As of
Confidence and caveat
Protocol fee
None defined in any MPP spec; costs come from the rail Source [4]
Not applicable
Verified Rail and processor fees still apply.
Tempo network fee
Paid in USD TIP-20 stablecoins through the Fee AMM; a 50,000-gas transfer costs at most about 0.0006 USD, with a quiet-period floor near 0.00003 USD Source [27, 101]
Client by default; server when feePayer is true for charge, open and topUp; server always for settle and close
Verified Depends on Tempo base fee parameters; fees go to the proposing validator.
Session v2 gas versus v1
Open on an existing reserve balance 72.1 percent less gas (294,425 versus 1,055,229); settle to a new payee balance 79.4 percent more (559,871) Source [36]
Whoever pays the operation's fee
Verified Up to 72 percent is the best case for one operation, not an average.
Stripe hostedFeePayer
Stripe pays customers' Tempo network fees Source [13]
Stripe
Verified Needs mppx 0.9.2 or later, live mode and a Tempo deposit address on the same account; not with Connect.
Stripe MPP minimums
0.50 USD for SPT card payments; 0.01 USDC for stablecoin payments Source [13]
Payer (minimum charge size)
Verified Minimums, not fees.
Stripe stablecoin payment fee
1.5 percent per transaction, reported at launch of stablecoin payments Source [42, 57]
Merchant
Reported The current Stripe docs page states no percentage; whether it applies to MPP charges is unverified.
Shared Payment Token fee
Not published; SPT docs labeled Public preview Source [63]
Unknown
Verified Absence of a public schedule, not a zero fee.
Card method
Card economics unchanged (interchange and acquirer fees); no MPP-specific card pricing published Source [30]
Merchant
Reported Inferred from Visa's announcement; no price list.
From the README quick start. secretKey is the challenge-binding secret; the README asks for at least 32 bytes. Keep it out of source control. mppx documentation (external link)Source [7]
Pay automatically with fetch (client)mppx 0.13.4Client sidetypescript
import { privateKeyToAccount } from 'viem/accounts'import { Mppx, tempo } from 'mppx/client'Mppx.create({ methods: [tempo({ account: privateKeyToAccount('0x...') })],})// Global fetch now handles 402 automaticallyconst res = await fetch('https://mpp.dev/api/ping/paid')
CLI: pay, choose protocol, close sessionsmppx CLI 0.13.4Command linebash
# create account - stored in keychain, autofunded on testnetmppx account create# make request - automatic payment handlingmppx example.com# pay an x402 offer on a server that advertises both protocolsmppx example.com --protocol x402# inspect and close retained sessionsmppx sessions listmppx sessions close --all --yes
Simulation of the Payment challenge and credential with an HMAC-bound challenge id, failure injection, a Tempo session meter with EIP-712 vouchers on a fake chain (424242), the method and intent matrix, and an x402 to MPP header translator. No real funds, no wallet, no network calls.
Simulation, no real fundsFollows spec version draft-httpauth-payment-01 with draft-payment-intent-charge-00 and draft-tempo-charge-00
Loading the simulation.
Keys are generated in this browser for this session only, on test chain identifiers or fixture data. No wallet connects and nothing is sent to a network.
P. Compare and compose
x402 is the sibling to compare first. Both answer , but x402 uses its own headers and a facilitator, while MPP uses HTTP authentication and lets the server or the rail settle. MPP’s mapping sends PAYMENT-REQUIRED to WWW-Authenticate: Payment, PAYMENT-SIGNATURE to Authorization: Payment and PAYMENT-RESPONSE to Payment-Receipt.Source [28] x402 exact maps to MPP charge, while x402 upto and EVM batch settlement are the usage-based counterparts of MPP sessions.Source [28] With mppx one route can emit both challenges, accept either and return the matching receipt, and the mppx client prefers the when it sees both.Source [28, 29] Stripe sits on both sides: it co-authors MPP and holds a seat on the x402 Technical Steering Committee.Source [4, 62]
On the card side, the stripe method carries Stripe Shared Payment Tokens, the token family Stripe also uses for agentic checkout next to ACP. Stripe documents SPTs as a public preview with no published price.Source [2, 17, 63] Visa’s card method has two links to TAP. The spec lets a client add TAP signature headers, and that sentence has been in the file since its first public version of 2026-03-18.Source [18, 64] Visa’s announcement of the same day says the spec and SDK are built on VIC and TAP, although the mpp-card 0.1.8 package contains no TAP signing code.Source [30, 65]
Mastercard has no ; the Visa card method simply accepts mastercard as a network value.Source [1, 18] In Mastercard’s 2026-06-10 release for Agent Pay for Machines (AP4M), says it is working with Mastercard on MPP compatibility; Mastercard’s own text makes no MPP claim, and no Tempo page lists AP4M.Source [31, 66] Tempo and Stripe are both in AP4M’s initial partner group.Source [66]
AP2 is complementary rather than connected: AP2 carries evidence of what a user authorized, MPP negotiates and settles a payment, but no specification binds them and neither repository mentions the other.Source [32] Watch the acronym: in AP2 documents MPP means Merchant Payment Processor.Source [33] UCP and ERC-8004 have no MPP link either, though the MPP discovery draft calls itself compatible with future on-chain anchoring of the kind ERC-8004 provides.Source [15, 32]
Relations to other protocols
Compatible withfrom ERC-8004: Trustless Agents: The MPP payment discovery draft cites ERC-8004 and calls its off-chain discovery compatible with future on-chain anchoring; no integration is specified. Source [105]
Complementsfrom Mastercard Agent Pay: Tempo, quoted in Mastercard's AP4M release, says it is working with Mastercard on Machine Payments Protocol compatibility; Mastercard makes no MPP claim itself and maintains no MPP payment method. Source [31, 106]
Same stewardfrom Agentic Commerce Protocol (ACP): Stripe co-maintains ACP and runs MPP; MPP accepts cards through the same Shared Payment Token family that implements ACP Delegate Payment. Source [107, 108]
Compatible withStripe MPP (Machine Payments Protocol) to Mastercard Agent Pay: Tempo's statement only: in Mastercard's 2026-06-10 AP4M release Tempo says it is working with Mastercard on MPP compatibility. Mastercard makes no MPP claim and has no MPP method spec. Source [1, 31]
Compatible withStripe MPP (Machine Payments Protocol) to x402: MPP maps x402 headers onto Payment authentication and x402 exact onto charge; upto and batch-settlement are comparable to sessions. mppx 0.9.0 and later serves both on one route; the mppx client prefers the Payment challenge. Source [28, 29, 98]
Competes withStripe MPP (Machine Payments Protocol) to x402: Both are HTTP 402 payment protocols; MPP's comparison page, written by its authors, recommends MPP by default. Stripe co-authors MPP and sits on the x402 TSC. Source [28, 62]
ComplementsStripe MPP (Machine Payments Protocol) to AP2: Complementary in principle (AP2 carries user authorization evidence, MPP settles payment) but no specification binds them and neither repository mentions the other. In AP2, MPP means Merchant Payment Processor. Source [32, 33]
ComplementsStripe MPP (Machine Payments Protocol) to Agentic Commerce Protocol (ACP): No protocol cross-reference; the shared component is Stripe Shared Payment Tokens, which the stripe method carries and Stripe also uses for agentic checkout. Source [2, 17, 32]
EmbedsStripe MPP (Machine Payments Protocol) to Visa Trusted Agent Protocol: The Visa-authored card method lets a client add TAP signature headers (in the spec since 2026-03-18); Visa says the card spec and SDK are built on VIC and TAP; mppx adds TAP request attestation. Source [18, 30, 35, 64]
Complementsfrom UCP: No documented relation in the spec; Stripe's UCP integration is a payment handler for tokenized methods, not MPP. Source [109, 110]
Compatible withfrom Visa Trusted Agent Protocol: Visa authored the MPP card method; draft-card-charge-00 lets a client add TAP signature headers, Visa says the card spec and mpp-card SDK are built on VIC and TAP, and mppx signs and verifies TAP attestations. Source [111, 112, 113]
Compatible withfrom x402: MPP maps x402 exact onto its charge intent, and mppx can serve both protocols on one route; Stripe sits on the x402 TSC and co-created MPP. Source [114, 115]
Competes withfrom x402: Both offer HTTP 402 machine payments for agents; Visa and Artemis measured MPP far below x402 to 2026-04-21 (secondary report). Source [114, 116]
Stripe MPP (Machine Payments Protocol) in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
Pay-per-request, metered and recurring payments as an HTTP authentication scheme 402 challenge, credential and receipt; methods settle on their own rails.Source [1, 4]
Verified
Layers covered
Payment credential and settlement rails; optional discovery No identity, mandate or checkout layer; disputes depend on the rail.Source [4, 15]
Verified
Stewards
Tempo Labs and Stripe Rails maintain their own methods (Visa, Lightspark, Circle and others).Source [1, 3]
Verified
Governance model
Core as an individual IETF draft; methods by rails; no foundation No working group, charter or steering committee.Source [3, 5]
Verified
License (spec and code)
Specs CC0 1.0; tooling Apache-2.0 or MIT; mppx MIT IETF submissions fall under IETF Trust terms.Source [6, 7]
Verified
First announced
2026-03-18 With Tempo mainnet; spec repository created 2026-01-05.Source [2, 9]
Verified
Latest version and date
draft-httpauth-payment-01 (2026-09-09); mppx 0.13.4 (2026-10-08) Old name draft-ryan-httpauth-payment expired 2026-09-18.Source [5, 11]
Verified
Maturity
Live deployments on a draft spec Tempo mainnet and Stripe since 2026-03-18; Stripe docs labeled Frontier; no IANA registrations.Source [8, 12, 13]
Verified
Transports
HTTP authentication headers; JSON-RPC and MCP; SSE receipts MCP error -32042 and _meta credential and receipt.Source [4, 14]
Verified
Settlement rails
Tempo and other chains, Stripe SPTs, card networks, Lightning 11 method ids in the spec repo; mpp.dev documents two more.Source [1, 53]
Verified
Agent identity model
None in the core; optional request attestation in mppx Optional DID source; Web Bot Auth and TAP profiles; TAP headers optional in the card method.Source [4, 18, 35]
Verified
User authorization model
The client's payment proof per request, or a rail grant Session deposit, SPT limits or Tempo access key; no user mandate object.Source [17, 27, 46]
Verified
Human-present and human-not-present support
Both Built for unattended clients; browser wallets should ask a human to confirm; SPT creation may prompt 3DS.Source [4, 17]
Verified
Merchant of record
The resource server With the stripe method the seller's Stripe account receives the PaymentIntent.Source [4, 17]
Verified
Credential type
Bearer Payment credential wrapping a method proof Signed Tempo transaction, SPT id, JWE network token, Lightning preimage or EIP-712 voucher.Source [4, 16, 17, 18]
Verified
Cryptography
HMAC-SHA256 binding, JCS, RFC 9530 digest, EIP-712 secp256k1, JWE RSA-OAEP TLS 1.2 or later required.Source [4, 18, 27]
Verified
Replay protection
Single-use challenge ids and single-use method proofs Idempotency-Key, digest binding, channel and domain binding.Source [4, 27]
Verified
Native spending controls
None in the core; caps come from rails Session deposit, SPT usage limits, Tempo access keys.Source [17, 27, 46]
Verified
Revocation
No core revocation; method-specific cancellation; forced channel close Source [27, 45]
Verified
Refunds and disputes
Depend on the method Card routes keep chargebacks; Stripe stablecoin payments have no disputes; session close refunds the unspent deposit.Source [27, 41, 42]
Verified
Privacy exposure
Chain settlements public; credentials private between client and server Card credentials may carry billing address and name; core forbids requiring accounts.Source [4, 18, 43]
Verified
Discovery mechanism
Optional /openapi.json with x-service-info and x-payment-info No .well-known path; mpp.dev directory and MPPscan.Source [15, 56]
Verified
Permissionless or registration required
Permissionless for chain methods; accounts for the stripe method Rails add methods without approval.Source [3, 17]
Verified
Decentralization
Open spec, concentrated authorship Five core authors from two companies; Tempo validators are permissioned; 126 of 129 listings accept Tempo.Source [4, 56, 102]
Verified
Observability score
3 of 5 Public chain settlement and MPPscan; credentials, Stripe and card payments private.Source [43, 44]
Verified
Fees and who pays them
No protocol fee; rail fees Tempo gas at most about 0.0006 USD per 50,000-gas transfer, paid by the client unless the server sponsors; Stripe minimums 0.50 USD (cards) and 0.01 USDC; Stripe stablecoin fee reported, not confirmed for MPP; SPT pricing not published (as of 2026-10-11).Source [4, 13, 63, 101]
Verified
Who pays (short)
Client pays gas unless the server sponsors; card economics unchanged Server always pays settle and close; Stripe can pay Tempo fees with hostedFeePayer.Source [13, 27]
Verified
Builds on (standards)
HTTP 402 auth (RFC 9110), JCS, RFC 9530, RFC 9457, HMAC, EIP-712, JWE, DID Plus OpenAPI and JSON-RPC for extensions.Source [4, 18, 27]
Verified
Composes with
x402, Stripe SPT (ACP), Visa TAP and VIC, Mastercard AP4M (Tempo's statement) AP2 complementary with no cross-reference; no UCP or ERC-8004 link.Source [17, 28, 30, 31, 32]
Verified
Reference implementations and SDKs
mppx 0.13.4 (TypeScript), pympp, Rust mpp, mpp-go, mpp-rb, Visa mpp-card Community SDKs in Elixir, Go and Swift.Source [11, 97, 117]
Verified
Adoption evidence
Live but small and mostly Tempo MPPscan: 4,072,426 transactions and 435,476 USD all time, 8,774 USD in the last 30 days (2026-10-11); 129 directory services.Source [44, 56]
Verified
Published security research
Yes: one formal analysis and six SDK advisories Tamarin model in arXiv:2609.00060; CVE-2026-34209, CVE-2026-34210, CVE-2026-63627, CVE-2026-63628 and two critical GHSAs.Source [47, 48, 52]
Verified
Regulatory touchpoints
Card law for card methods; stablecoin, AML and sanctions rules for chain methods No KYC or sanctions layer in the core.Source [4, 70, 75]
Verified
Biggest open question
Will it become a real standard with a neutral home, and is the traffic real commerce? Source [5, 44]
Not only. Tempo Labs and Stripe co-author it: three of the five core authors work at Tempo Labs and two at Stripe. Rails such as Visa, Lightspark and Circle write their own payment methods. Source [1, 2, 3, 4, 18, 19, 24]
MisconceptionIs MPP an IETF standard?
No. The core is an individual Internet-Draft, draft-httpauth-payment-01 (2026-09-09), with no working group, stream or intended status. IANA has registered none of its header or scheme names as of 2026-10-11. Source [5, 12]
MisconceptionIs MPP crypto-only?
No. Besides stablecoin methods on Tempo and other chains, the stripe method carries Shared Payment Tokens for cards and wallets, the Visa-authored card method carries encrypted network tokens, and the lightning method pays BOLT11 invoices. Source [1, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26]
MisconceptionIs the MPP in AP2 documents the same thing?
No. In AP2, MPP abbreviates Merchant Payment Processor, a role in the payment flow. It has nothing to do with the Machine Payments Protocol. Source [33]
MisconceptionWas the IETF draft renamed on 2026-09-09?
No. The new name draft-httpauth-payment first appeared as -00 on 2026-06-19; 2026-09-09 is its -01 revision. The old name, draft-ryan-httpauth-payment, expired on 2026-09-18. Source [5, 10, 40]
MisconceptionIs session a standard MPP intent?
Not yet. Only charge and subscription are in specs/intents. Session is defined inside six method specs, and the pull request for a generic session intent closed unmerged on 2026-09-28, even though a June blog post called sessions a formal intent. Source [1, 19, 20, 21, 23, 26, 27, 34, 36]
How is MPP different from x402?
MPP uses HTTP authentication headers (WWW-Authenticate, Authorization, Payment-Receipt) and lets the server or rail settle; x402 uses its own headers and a facilitator. MPP maps x402 exact to charge, and mppx can serve both on one route. Source [28, 29]
Can a leaked credential be used by someone else?
Yes, until it is used. Credentials are bearer tokens, so servers and intermediaries must never log them, and TLS 1.2 or later is required. Source [4]
How much can an agent lose in a session?
At most the channel deposit, because vouchers cannot exceed it. On close the server may capture only what was spent and must refund the rest. Source [27]
What if the server never closes my channel?
Call requestClose on chain, wait the grace period of at least 15 minutes (the spec advises 16), then call withdraw. The server can still settle its newest voucher during the grace period. Source [27]
Does MPP support refunds and chargebacks?
It depends on the method. Card routes keep chargebacks; Stripe stablecoin payments have no disputes; on-chain charges are final unless the seller refunds. Source [41, 42]
MisconceptionDoes Mastercard support MPP?
Mastercard has not said so in its own words. In its 2026-06-10 Agent Pay for Machines release, Tempo says it is working with Mastercard on MPP compatibility. There is no Mastercard method spec; the Visa card method accepts mastercard as a network value. Source [1, 18, 31, 66]
MisconceptionWere Anthropic, OpenAI and Shopify MPP design partners?
No source says so. Tempo's launch post names them as partners for stablecoin use cases on Tempo; only Visa is called an MPP design partner. Source [8, 30]
R. Open questions and research frontier
Will the core reach an IETF working group?
The draft is an individual submission; its first name expired before renewal under a new name, and mpp.dev's standards-track wording is stronger than the Datatracker record. Source [3, 5, 10]
Will session become a standardized intent?
The contribution rules need two methods, and six methods already define session, yet PR #280 closed unmerged on 2026-09-28. Source [34, 54]
How much MPP activity is real commerce?
MPPscan's last 30 days average under one cent per transaction, and 126 of 129 directory listings accept Tempo. Source [44, 56]
Does Stripe's reported 1.5 percent stablecoin fee apply to MPP charges?
Reported in December 2025; the current Stripe page states no percentage and the MPP docs list only minimums. Source [13, 57]
Should channels expire?
Channels and vouchers have no expiry; servers are only advised to close idle channels after about 30 days. Source [27]
Will MPP gain a user authorization object, or rely on AP2-style mandates?
MPP carries no user mandate, and no specification binds it to AP2. Source [4, 33]
Will Mastercard publish an MPP method or statement of its own?
Only Tempo's quote inside Mastercard's release exists; no method spec. Source [1, 31]
What do the 40 Tamarin findings mean for MPP specifically?
The abstract does not break the findings out per protocol. Source [52]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
WWW-Authenticate: Payment
T. Notes
Notes stay in this browser. Nothing is sent anywhere.