What Is the Machine Payments Protocol?

The Machine Payments Protocol (MPP) is a payment protocol designed by Stripe and Tempo specifically for machine-to-machine transactions. While traditional payment protocols were built around human-initiated, one-time transactions, MPP was built for a different reality: machines that need to pay other machines continuously over the course of an ongoing interaction.

The core idea behind MPP is the payment session. Instead of treating every payment as an isolated event, MPP opens a persistent session between two parties, a payer and a payee. Within that session, payments stream incrementally. The payer does not need to authorize each individual microtransaction. Instead, the session defines the terms (rate, maximum spend, settlement chain), and value flows automatically as the service is consumed.

This model maps directly to how machines actually interact. When an AI agent connects to a real-time data feed, it does not consume one data point and disconnect. It maintains a connection and receives a continuous stream of updates. When an agent delegates a complex research task to another agent, the work happens over minutes or hours, not in a single request-response cycle. MPP gives these interactions a native payment layer that matches their structure.

Stripe's involvement signals the protocol's enterprise ambitions. After acquiring Bridge for $1.1 billion and launching stablecoin infrastructure, Stripe co-developed MPP with Tempo to standardize how machines pay each other across their networks. The protocol settles in stablecoins like USDC, leveraging the speed and finality of chains like Polygon PoS, Base, and Tempo.

For a broader view of how AI agent payments work across all protocols, see our pillar guide.

How MPP Works

MPP follows a three-phase session lifecycle: open, stream, and close. Understanding this lifecycle is the key to understanding why MPP exists and when to use it instead of simpler one-shot protocols like x402.

Phase 1: Open Session

The payer initiates a session with the payee. The session request includes the payer's wallet address, the proposed payment rate (for example, 0.001 USDC per second), a maximum session budget, and the preferred settlement chain. The payee evaluates the request and, if the terms are acceptable, returns a session ID. At this point, no money has moved. Both sides have simply agreed on the rules of engagement.

Phase 2: Stream Payments

Once the session is open, payments flow incrementally. The payer signs small payment commitments at regular intervals, and the payee can claim these commitments on-chain at any time. In practice, most implementations batch these claims for efficiency, settling accumulated value periodically rather than on every micro-increment. The service continues as long as the session is active and the payer's budget has not been exhausted.

This streaming model has an important property: the payee is never more than one interval behind on payment, and the payer never overpays for service it has not yet received. Both parties share minimal risk at any given moment.

Phase 3: Close Session

Either party can close the session. When the session ends, a final settlement occurs. Any unclaimed payment commitments are settled on-chain, and both parties receive a complete record of the session: duration, total amount transferred, number of payment increments, and the settlement transaction hash. This record serves as an immutable audit trail.

Here is the lifecycle visualized:

  OPEN SESSION
  Payer -> Payee: "I want to pay 0.001 USDC/sec, max 5 USDC, on Polygon"
  Payee -> Payer: "Accepted. Session ID: mpp_sess_abc123"
            |
            v
  STREAM PAYMENTS
  [0s]   Payer signs commitment: 0.001 USDC
  [1s]   Payer signs commitment: 0.002 USDC (cumulative)
  [2s]   Payer signs commitment: 0.003 USDC (cumulative)
  ...
  [300s] Payer signs commitment: 0.300 USDC (cumulative)
  Payee claims batch settlement on-chain periodically
            |
            v
  CLOSE SESSION
  Either party sends close signal
  Final settlement: 0.300 USDC settled on Polygon PoS
  Both parties receive session receipt with audit trail

The key difference from x402 is structural. With x402, every HTTP request is a complete payment cycle: the server sends a 402, the agent pays, the server delivers. With MPP, the payment channel stays open, and value streams through it continuously. This eliminates the overhead of negotiating and settling payment on every single interaction.

MPP vs x402: When to Use Which

MPP and x402 are not competing protocols. They solve different payment patterns. Choosing between them depends on the nature of the interaction your agent is performing.

Dimension x402 MPP
Payment Model One-shot per request Streaming within a session
Best For Individual API calls, discrete purchases Ongoing sessions, continuous services
Complexity Low: single request-response cycle Moderate: session lifecycle management
Latency One settlement per request Batched settlements, lower per-interaction overhead
Use Cases Paid APIs, data lookups, one-time tool calls Real-time feeds, long-running tasks, agent-to-agent delegation
Protocol Layer HTTP (402 status code) Session-based (transport-agnostic)
MoltPe Support Native, via agent wallets Native, via agent wallets and moltmpp.dev

A practical rule of thumb: if the interaction is a single question and answer, use x402. If the interaction involves an ongoing connection where value is exchanged over time, use MPP. Many real-world agent systems use both. An agent might use x402 to pay for a one-off geocoding lookup, then open an MPP session to stream payments for a 30-minute real-time market data feed.

From the developer's perspective, MoltPe abstracts the complexity of both protocols behind the same agent wallet infrastructure. Your agent's wallet, spending policies, and audit trails work identically whether the payment flows through x402 or MPP.

MPP Use Cases

MPP unlocks payment patterns that were impractical with one-shot protocols. Here are the four categories where it delivers the most value.

Streaming AI Services

When an agent connects to a hosted LLM, image generator, or speech synthesis service, the cost scales with usage over time. MPP lets the agent open a session and pay incrementally as tokens are generated or audio is synthesized. The service provider gets continuous payment assurance. The agent only pays for what it actually consumes. If the agent decides mid-stream that the output quality is poor, it closes the session and stops paying immediately.

Long-Running Agent Tasks

Multi-step agent workflows can run for minutes or hours. An orchestrator agent might delegate research, data collection, and analysis to specialized sub-agents, each of which charges for their compute time. MPP sessions let the orchestrator pay each sub-agent for the duration of their work without needing to estimate costs upfront or settle a lump sum after the fact. The payment streams alongside the work.

Subscription-Like Machine Payments

Traditional subscriptions are monthly billing cycles designed for humans. Machines need more granular access. An agent that needs a weather API for a two-hour data collection job should not pay for a monthly subscription. MPP enables pay-by-the-session access where the agent opens a session, consumes the service for exactly the duration it needs, and closes the session. The cost is proportional to actual usage, down to the second.

Real-Time Data Feeds

Financial data, IoT sensor streams, live event feeds: these are inherently continuous. An agent monitoring stock prices needs a persistent connection with continuous payment. MPP's streaming model is a natural fit. The agent pays a per-second rate for the feed, and the data provider can cut access the instant payment stops. No invoicing delays, no accounts receivable, no payment disputes.

Integrating MPP with MoltPe

MoltPe provides native MPP support through the same agent wallet infrastructure that powers x402, MCP, and REST API integrations. If you already have a MoltPe agent wallet, you can start using MPP without any additional setup.

How MoltPe Agents Use MPP

Every MoltPe agent wallet can act as both an MPP payer and an MPP payee. To initiate an MPP session, the agent calls the session-open endpoint with the payee's address, the proposed rate, and a session budget. MoltPe handles the payment signing, commitment tracking, and on-chain settlement. The agent's existing spending policies apply to MPP sessions: if a session would exceed the daily spending limit, MoltPe blocks it automatically.

For agents receiving payments via MPP, MoltPe manages incoming session requests, validates payment commitments, and credits settled funds to the agent's wallet. The full session history, including every payment increment, is visible on the MoltPe dashboard and through the REST API.

Try It Live

MoltPe maintains a dedicated MPP demo environment at moltmpp.dev. You can open a test session, stream payments between two wallets, and close the session to see the full lifecycle in action. The demo uses testnet USDC, so there is no real money involved. It is the fastest way to understand how MPP sessions behave before integrating into your production agent.

Integration Options

MoltPe supports MPP through multiple integration paths:

The Future of Machine Payments

MPP and x402 represent two complementary approaches to the same fundamental problem: machines need to pay other machines without human intervention. As the agent economy matures, these protocols will likely converge rather than compete.

The trajectory is already visible. x402 started as a simple pay-per-request mechanism and is evolving toward more complex payment patterns. MPP started as a session-based streaming protocol and is adding support for simpler one-shot interactions. The end state is likely a unified machine payment layer where agents automatically select the optimal payment pattern (one-shot, streaming, or batched) based on the interaction type.

The broader trend is that every machine-to-machine interaction will have a native payment component. APIs will not need separate billing systems. Agent-to-agent communication will include built-in compensation. Data feeds will charge by the second instead of by the month. The infrastructure for this future is being built now, and protocols like MPP are a critical piece of it.

MoltPe is positioned at the intersection of these protocols. By supporting x402, MPP, MCP, and REST API natively, MoltPe ensures that your agents can pay and get paid regardless of which protocol the counterparty uses. The agent wallet is the constant; the payment protocol is a detail that the infrastructure handles.

For developers building AI agent payment systems today, the practical advice is straightforward: start with whichever protocol fits your immediate use case, and choose infrastructure that supports both. The protocol landscape will keep evolving. Your agent wallets and spending policies should not need to change when it does.