MPP: What Early Machine Payments Look Like

27 August 2026

When AI agents start transacting, the infrastructure beneath them changes shape. Software needs to discover prices, understand payment terms, authorize spend and receive proof without relying on a human checkout flow.

The Machine Payments Protocol (MPP) gives us one of the clearest early places to observe this change. It brings payment authentication into HTTP itself, allowing software to negotiate access and pay through stablecoins, cards and other rails.

For agentic finance, that makes MPP particularly interesting: it is early, real, measurable and easy to misread. MPP-mediated payments are already reaching production services, but a transfer count is not a customer count, a funded channel is not a purchase, and onchain activity does not by itself prove agent demand.

Summary

• MPP is an early piece of agentic payments infrastructure. MPP is an HTTP payment coordination and authentication protocol co-authored by Tempo and Stripe. It defines how a service requests payment, how a machine provides payment authorization or proof, and how the service returns a receipt. MPP can settle payments through Tempo, Stripe/card infrastructure, among other networks.
• MPP puts payment negotiation inside the HTTP request/response loop. A machine can encounter a 402 Payment Required, receive machine-readable terms, authorize, and receive the resource plus a receipt without requiring the typical human-actions of account creation, checkout, prepaid credits or a manually configured subscription. MPP coordinates existing payment infrastructure rather than replacing it.
• Expansion in machine settlements. Sessions are high-volume, optimized for micropayments. Between June and July, observable session activity increased by 7,462.8%. Active payer addresses rose 271.8% and payment frequency per active payer increased 1,933.9%. At the same time, total priced value transferred fell 22.7% and the median priced session transfer fell 86.5%.
• From verified Tempo session infrastructure, we reconstructed 192,964 onchain transfers to service providers across 192,953 Tempo transactions, involving 1,672 payer addresses and 70 recipient addresses. These transfers can settle multiple paid requests accumulated within a session, so they should not be read as individual purchases.
• USDC.e dominates in settlement. Within the measurable MPP Tempo sessions, it represents 99.96% of visible settlements.

The largest missing number is complete charge activity. Tempo charges do not have one mandatory marker used by every implementation. A current standard MPP tag lets us identify a large subset of transfers, but not reconstruct every charge. This post does not produce complete Tempo MPP settlement count, value, charge/session share. MPP has real services and observable economic settlement. What the current evidence does not support is a claim of broad, independently distributed economic adoption, a global MPP market size until these numbers can be reviewed.

What is MPP and where it fits in agentic payments

MPP standardizes payment authentication over HTTP.

Like x402, it lets software encounter a price and pay for a resource inside the request-response flow rather than requiring a separate account, billing relationship or checkout.

Its main contribution is separating that payment from both the settlement rail and the billing model. The same Challenge–Credential–Receipt exchange can support different payment methods, such as stablecoins, cards or Lightning, and other payment models: one-time charges, sessions or subscriptions.

AP2 and ACP, though standards as well, solve different problems:

• AP2 focuses on proving that an agent was authorized to make a purchase
• ACP manages checkout and order lifecycle. MPP handles payment for a resource; it does not prove human intent or manage a cart.

An MPP payment can be generated by an AI agent, an agent following a predefined spending policy, a deterministic bot, a cron job, an ordinary API client, a developer test and also human-triggered software.

One useful way to understand an MPP payment is to separate the components:

MPP sits at the top of this stack. Tempo sits lower, as one possible settlement environment.

Tempo has been designed with MPP-friendly primitives—including stablecoin-oriented transactions, scoped access keys, fee sponsorship and dedicated payment-channel infrastructure.

MPP is useful beyond stablecoin-native services. Stripe can process MPP payments through its existing payments infrastructure, including card-based payments. MPP coordinates the payment request and authorization; Stripe handles processing and merchant settlement. These payments do not necessarily produce a public blockchain transaction.

MPP is not limited to agent-to-agent digital services: the protocol can mediate software purchasing browser time, data, physical mail, physical goods or other services.

How MPP works: HTTP 402, authorization and receipts

MPP extends normal HTTP authentication to payments:

request
   ↓
402 Payment Required
WWW-Authenticate: Payment ...
   ↓
client authorizes payment
   ↓
retry original request
Authorization: Payment ...
   ↓
server validates / settles
   ↓
resource + Payment-Receipt

The 402 carries the payment terms, the credential carries authorization or proof, and the receipt confirms the result. The price and accepted payment method can therefore be discovered and handled by software at request time.

The HTTP exchange remains offchain. Whether payment produces a blockchain transaction depends on the payment method.

Charge

A charge is a one-time payment for a resource.

On Tempo, charges can use direct TIP-20 transfers or split payments. There is no single mandatory contract or event that identifies every MPP charge.

Session

A session is designed for repeated, small payments.

A payer funds a payment channel and signs cumulative payment authorizations offchain as the service is used. Rather than settling every request individually, the provider can settle the accumulated amount periodically or when the channel closes.

fund channel onchain
        ↓
request → payment authorization
request → larger authorization
        ↓
optional settlement
        ↓
more requests
        ↓
final settlement + refund of unused funds

This means one onchain transfer can settle multiple paid requests, making blockchain transaction counts a poor proxy for actual service usage.

How to read the numbers

Not every observable event represents the same thing.

This is why the numbers below cannot be read interchangeably: paid requests, onchain transfers, blockchain transactions and channel activity measure different things.

Where MPP can operate

MPP is not tied to one payment rail, but implementation and production evidence vary.

MPP may operate across several rails, but Tempo provides the clearest public view of settlement activity.

MPP on Tempo: stablecoin settlement by the numbers

Tempo gives us the clearest public view into MPP's onchain payment rails. It is particularly useful for studying the combination of stablecoin settlement, payment channels and micropayments that agentic finance is expected to rely on.

Throughput

Tempo MPP session infrastructure had produced:

• 472,004 lifecycle events
• 192,964 onchain session transfers to service providers
• 192,953 Tempo transactions containing those transfers
• 1,672 payer addresses and 70 recipient addresses

There are 11 more transfers than transactions because a single Tempo transaction can contain more than one transfer to a provider.

A separate attribution method identified 2.57 million MPP-tagged Tempo transfers through August 26. This expands what we can observe beyond sessions, but it is still not a complete charge count: not every implementation uses the tag, and one charge can produce multiple transfers.

Asset mix on Tempo's observable data

Asset composition is overwhelmingly concentrated in USDC.e:

USDC.e also represents 99.8087% of priced session value. This also shows how early MPP activity is converging around programmable stablecoin money rather than a broad mix of assets.

Concentration

Recipient payment routes:

• top recipient by count: 98.43% of session;
• top 10 recipients by count: 99.58%.

The MPP directory identifies many of these services as third-party integrations accessed through shared proxy infrastructure. The address receiving 189,935 session transfers is shared across multiple services: standard-tagged transfers associated with 30 distinct server fingerprints also route to it.

The 98.43% concentration by transfer count is largely an infrastructure effect: the dominant recipient is shared across multiple services. Recipient-address concentration therefore cannot be read directly as service-market concentration.

Value:

• top recipient by priced value: 20.86%;
• top 10 recipients by priced value: 96.57%.

The count-dominant recipient received 189,935 session transfers but approximately 297.7 USDC.e in native settled value.

Payers:

• top payer: 1.67% ofsession transfers
• top 10: 7.97%;
• top 100: 69.75%;
• payer-count Gini: 0.884.

A small number of payer addresses are responsible for most of the money, but not for most of the payments: the top 10 payers account for 54.36% of priced value.

Growth in July

Observable Tempo session activity exploded primarily because each active payer address generated far more, much smaller transfers—not because economic value grew proportionally.

By August 26, the month had already recorded 127,621 session transfers.

Channel funding and completion

A channel opens when the payer wants to start or prepare a session-based payment relationship with a service. But it might not actually purchase a service.

For example:

Among 16,536 completed channels:

• 54.35% had 0% utilization and were fully refunded.
• median utilization was 0% and mean 7.48%.

Channel funding should not be treated as consumer intent. The current SDK can open and fund a channel automatically after the first 402. Reusing the same channel across process restarts also depends on client state.

Short, fully refunded channels are possible without implying a completed purchase. The 54.35% of completed channels with zero utilization could include rejected or abandoned first attempts, explicit closes, stateless deployments, testing or other automation. The chain cannot distinguish among those causes.

What it does establish is that a deposit is reserved capacity; only value ultimately allocated to the payee is settlement.

The 45k statistic

The historical public figure around 45,000 reconciles precisely to:

• 45,274 legacy lifecycle events not payments;
• 36,504 distinct transactions emitting those events;
• 84.66% of lifecycle events consisting of channel opens or closes.

A channel can produce multiple lifecycle events without any corresponding purchase, and a session can support multiple paid requests without producing a separate lifecycle event for every request.

The data also shows why at Agentic Zero we focus on what has to change in financial rails for agents: a transfer count is not a customer count. A channel open is not a purchase. Funding is not utilization. As machine payments become easier to generate, understanding what the underlying event actually represents becomes more important, not less.

Payer-address activity and retention

Among the 1,672 payer addresses in the reconstructed settlement dataset: 64.06% were active on at least two days.

Exact-day retention:

• After 1 day: 19.27%
• After 7 days: 19.78%
• After 30 days: 12.97%
• After 60 days: 0.81%

These figures describe payer-address retention, not customer, company or agent retention. Exact-day retention also means activity on that specific future day.

Services and ecosystem

MPP's public directory contains:

• 141 current services
  • 91 have a published realm or endpoint hostname whose cryptographic fingerprint appears in standard-tagged Tempo transfers.
    • 50 are categorized as data services
    • 23 as AI services
• 1,449 endpoints
• 139 services advertising Tempo
• 133 advertising Tempo charge
• 7 advertising Tempo session

The visible services footprint is concentrated in programmatic data, search, model/media and infrastructure APIs rather than broad consumer checkout. The strongest production examples include Parallel, Dune, Allium, Browserbase, Orthogonal, StableEnrich, Alchemy and KeeperHub.

Agent402 separately documents scheduled canary purchases of roughly 204 Tempo charges per day, down from an earlier roughly 1,000 per day.

Current public evidence shows where MPP is being offered and used, but it does not identify most buyers or establish broad independent demand.

What the data says about adoption and market structure

MPP is early, real, measurable and easy to misread.

• Breadth is increasing, but throughput is increasing much faster. The jump from 142 to 528 active payer addresses between June and July demonstrates expansion in address-level participation
• Throughput increased far faster. Session transfers per active address moved from 5.46 to 111.01.
• July produced more than 75 times as many session settlements than June. It shows that the system is being used for very small units of value, precisely the use the architecture is designed to support.
• Repeat activity exists. A majority of observed payer addresses appear on more than one day. This is a proxy since, of course, one user can control many addresses.

Why this matters for agentic finance

Agentic finance is not just about AI agents transacting onchain. It requires financial infrastructure that software can actually use: prices that can be discovered programmatically, payments that can be authorized under delegated controls, stablecoins or card rails that can settle without a human checkout, and receipts that machines can verify.

MPP is one early implementation of that idea. x402, AP2 and ACP approach adjacent parts of the same problem from different directions. Their emergence suggests that financial infrastructure is beginning to be designed with machine actors in mind.