MPP: How Can Machines Coordinate Payments and Ongoing Billing?

A research agent may pay once for a data query or call an analytics service continuously. The price of a query may be known upfront, while streaming model output may consume an unknown number of tokens. Client and server need to agree on when to pay, how to prove payment and when the process ends.

The Machine Payments Protocol (MPP) defines a structure for paid interactions between machines. It standardizes payment challenges, client credentials and receipts while allowing different payment methods to provide their own implementations.

This is a conceptual explanation based on public documentation. Examples are hypothetical and untested; sources reviewed October 28, 2026.

Three billing questions

Mode	Suitable question	Example	Check
Charge	Is the price fixed for this request?	$0.01 for one query	Total price, recipient, validity of credential
Session	Does usage increase while the service runs?	Metered streaming output	Session limits, top-ups, closure and unused funds
Subscription	Is access granted for a period?	Monthly API access	Period, renewal permission and cancellation

MPP sessions can let clients establish a session, increase authorized amounts with use and close the session. Payment methods can work differently: do not treat one network’s channel design as the universal session implementation. See MPP sessions.

A streaming task

Suppose an agent wants at most $2 of metered analysis:

flowchart LR A[Request streaming analysis] --> B[Server offers session payment terms] B --> C[Client opens session with supported method] C --> D[Service streams and meters usage] D --> E[Increase authorization with use] E --> F{Continue or stop?} F -->|Continue within limits| D F -->|Stop| G[Settle and handle unused funds under implementation]

The $2 is an illustrative user limit. Check whether the service supports limits, when funds are charged, and how unused funds are returned. The MPP session description covers funded sessions, metering, top-ups where needed and closure; implementation details vary by method.

Charge, session and subscription

For a fixed-price query the question is how much the request costs. For continuous output, it is how much has been delivered, the amount currently collectible and how far the session may continue. A session may reduce per-payment overhead but adds balance, timeout, closure and reconciliation concerns.

MPP also describes subscriptions. In its documented Tempo implementation, the user authorizes access associated with a merchant and period, and the server checks subscription status on later requests. Supported payment methods, renewals and cancellation depend on the implementation. See MPP subscriptions.

Relationship with x402

Both can use HTTP 402 to coordinate paid access and require compatible implementations and usable payment methods. Sharing the 402 status code does not make credentials, SDKs or session mechanisms automatically interoperable. MPP documents an mppx SDK implementation supporting compatible x402 exact flows through one interface. Check versions, methods, networks, pricing and error handling, then test interoperability. See MPP x402 support.

Question	Integration check
Pricing	Fixed, metered or periodic? How is maximum spending limited?
Funds	Which payment method, credential custodian and network fee payer?
Failure	How are interruptions, timeouts and duplicate requests recovered?
Delivery	Does a receipt show payment status or prove complete service delivery?
Compatibility	Do client and server support matching versions, methods and networks?

MPP structures the interaction; budget governance, data quality, service reliability and disputes need additional design. Further reading: sessions, subscriptions and MPP.