Back

Building on Privy with Tempo’s Machine Payments Protocol (MPP)

Programmable wallets for machine-to-machine payments, from request to settlement

Madeleine Charity

|

Mar 18, 2026

Start building with MPP today using Privy with our docs and starter repo.

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

Today, Tempo introduced the Machine Payments Protocol (MPP), a new standard for programmatic payments on the internet.

MPP defines how services can request payment, how clients can authorize it, and how transactions settle, all within a single, standardized flow.

As software becomes more automated and agent-driven, this shift matters. Payments are no longer something that happens outside the request, and instead become part of the request itself.

With Privy, developers can spin up programmable wallets to use MPP without stitching together onboarding, custody, and execution. This makes it possible to build real payment systems, from global payouts to agent-driven commerce. 

What is MPP?

MPP is an open protocol for machine-to-machine payments.

It extends the familiar HTTP request cycle: request → payment required → authorize → retry → response

Unlike earlier approaches, MPP is designed for production systems:

  • Payment-method agnostic (stablecoins, cards, Lightning, and more)

  • Built-in primitives for safety and reliability (idempotency, expiration, request binding)

  • Support for both one-time and continuous payments via sessions

Instead of building custom billing logic, developers can rely on a standard interface for requesting and settling payments across services.

How MPP works

MPP builds on HTTP 402, but expands it into a complete, production-ready payment flow. At a high level:

  1. A client requests a resource: This could be an API call, model inference, dataset, or service.

  2. The server responds with a payment requirement: It specifies the amount, payment methods, and constraints like expiration or request binding, tying the payment to that specific request.

  3. The client authorizes payment: A wallet signs a payment authorization based on that request.

  4. The client retries with payment attached: The request now includes proof of payment.

  5. The server verifies and returns the response: If payment is valid, funds are transferred and the request completes.

This turns payments into a standard part of application logic, not a separate system.

MPP also introduces sessions, which change how payments are executed. Instead of requiring a new transaction for every request, a client can:

  • Lock funds upfront

  • Issue signed vouchers offchain as it consumes services

  • Settle periodically onchain

This enables sub-100ms latency, near-zero per-request fees, and high-frequency, low-value transactions. In practice, sessions make “pay-as-you-go” viable at Internet scale, especially for agents and real-time services.

The difference between MPP and x402

MPP builds on the same foundation as x402. Both use HTTP 402 to signal that a request requires payment, and both enable programmatic, request-based payments within standard request flows.

MPP extends this model in a few ways:

  • Payment methods: MPP supports multiple payment methods, including stablecoins, cards, Lightning, and custom rails.  x402 is designed around blockchain-based payments.

  • Execution model: MPP introduces sessions, which allow for off-chain vouchers with periodic settlement. x402 typically uses a one-transaction-per-request model.

  • Performance: MPP supports high-frequency, low-value interactions through session-based flows. x402 is well-suited for discrete, per-request payments.

  • Production readiness: MPP includes primitives such as idempotency, expiration, and request binding. x402 focuses on a simpler request → authorize → retry pattern.

  • Extensibility: MPP allows new payment methods and intent types to be defined independently. x402 follows a more fixed structure centered on blockchain payment flows.

MPP is also compatible with x402. Existing x402-style flows map directly to MPP’s charge model, while MPP introduces additional patterns such as sessions and multi-rail support.

Building on MPP with Privy wallets

Privy provides the programmable wallet infrastructure that makes MPP usable in real applications.

With Privy, you can:

  • Provision wallets for users and agents

  • Securely authorize payments within your app

  • Enable delegated and automated execution

  • Manage funding and asset flows across payment rails

All without building your own wallet system or custody layer.

This means you can go from: user or agent → wallet → payment → execution within a single integration.

Whether you’re building payouts, APIs, or agent workflows, Privy provides secure, scalable wallet infrastructure so you can focus on the product experience.

Looking ahead

MPP is an early step toward a more programmable internet of payments.

As agents become more capable, payments will become part of how software coordinates work, not just how humans check out.

We’re already seeing this unlock:

  • Agents paying for APIs, data, and compute in real time

  • Streaming, usage-based pricing models

  • Multi-step workflows that coordinate payments across services

  • Global payment systems built directly into applications

Privy is building to make this shift accessible, with wallet infrastructure that is simple, secure, and ready for production.

Start building with MPP today using Privy with our docs and starter repo.

Share this post


RELATED POSTS