TL;DR: The Machine Payments Protocol (MPP) is one of the more interesting pieces of infrastructure to come out of the current agentic AI wave. Co-authored by Stripe and Tempo, it lets software agents and services coordinate payments programmatically, without forcing a human through signup, checkout, invoices, or subscriptions. The mechanics are elegant, but they expose a deeper problem: payments are complex economic decisions and the trust infrastructure agents need to make those decisions does not yet exist.
What MPP is
MPP stands for Machine Payments Protocol. It is an open standard for agent-to-service payments, co-authored by Stripe and Tempo, that lets agents and services coordinate payments programmatically, including microtransactions and recurring payments (Stripe). Tempo frames the protocol as extensible and payment-method agnostic; it is intended to work across stablecoins, cards, and other supported payment methods (Tempo).
What MPP removes from the standard payment flow is the part most people associate with payments:
- No checkout page
- No account creation
- No invoice
- No monthly plan
- No API key negotiation
For machine-to-machine commerce the last one is the clincher. Account creation and API key issuance are the parts that have always been the worst fit.
How it works
The basic protocol works like this: a client requests a paid resource, the server responds with an HTTP 402 Payment Required and the payment details, the client authorizes the payment, the client retries the request, and the server delivers the resource and a receipt (Stripe Docs).
Who is behind it
Stripe and Tempo co-authored the protocol. Tempo is a payments-focused blockchain incubated by Stripe and Paradigm. Furthermore Visa is the formal design partner extending MPP for card-based payments through its Visa Intelligent Commerce and Trusted Agent Protocol stack (Visa). Lightspark has extended the protocol for Bitcoin Lightning. Cloudflare lists MPP alongside x402 under Agentic Payments in its agents documentation, with Pay Per Crawl as a related content-monetization product (Cloudflare).
MPP is also backwards-compatible with x402, the earlier Coinbase-developed protocol that activated HTTP 402 for USDC (stablecoin) payments. MPP’s charge intent maps directly to x402’s payment flow, so existing x402 services can be consumed by MPP clients without modification. Stripe says it supports both protocols, and Visa designed its card spec to complement both.
What MPP is not
MPP is a payment rail for machine-to-machine payments, not the protocol for agentic retail commerce. The agent-to-merchant flow (shopping for a flight, a pair of shoes, a laptop) sits in a different protocol called the Agentic Commerce Protocol (ACP), co-authored by Stripe and OpenAI. ACP standardizes product discovery, cart management, checkout, and payment for agent-mediated retail.
The marketing for both protocols tends to muddy the deployment shape. ACP, in its most visible form (ChatGPT Instant Checkout with Etsy and Shopify merchants), keeps the human in the loop for each transaction. The user sees a confirmation card with the item and price, taps confirm, and a Shared Payment Token is generated for that single purchase scoped to that single merchant. Thus, ACP in its current form is friction reduction for human-decided purchases, much like Apple Pay or Shop Pay, rather than autonomous commerce. ACP the protocol is also designed to support a more autonomous mode (standing budgets, agent-policy-driven authorization, purchases without per-transaction consent), but this is mostly aspirational at the time of writing.
Furthermore, MPP is not trying to replace existing billing relationships, metering and rate limiting mechanisms. A SaaS provider who already has the customer’s card on file and bills overages for burst usage does not need MPP. Conventional metered overage on an existing account already handles it, and the customer relationship absorbs identity, entitlement, and dispute mechanics. MPP is suited to cases where the relationship does not yet exist.
The problem MPP is trying to solve
Software is moving toward agentic workflows, and agents trapped inside a single application can only do so much. To be useful they need access to external tools, data, services, and workflows. MCP standardized how agents call those tools. MPP is trying to standardize how agents pay for them.
Today monetizing an API, a data product, an MCP server, a piece of content, or a compute resource is a clunky process. The buyer creates an account, enters a card, picks a plan, accepts terms, gets an API key, configures authentication, and monitors spend. The seller manages accounts, stores billing details, defines pricing plans, issues API keys, meters usage, runs monthly billing, reconciles invoices, handles failed payments, enforces entitlements, and supports upgrades, downgrades, and cancellations.
This works fine for human-in-the-loop use cases, but it’s a poor fit for machine-to-machine transactions.
The buyer-side problem: agents can pay, but should they?
The standard MPP pitch focuses on payment mechanics: can the agent hold funds, sign a payment, use a scoped token, stay under a spending cap, and produce a receipt?
But how does an agent decide what is worth buying? That is an economic judgment problem, and a payment-infrastructure protocol cannot solve it.
Payments are not just execution
When a human buys something, the buying process carries a lot of implicit choices. Do I trust this seller? Is this price fair? Do I really need this? Are there better value alternatives? We are trained to be sophisticated shoppers all our lives, we learn how to cut through advertising, and how to compare alternatives to find the best value for the situation at hand. Even with all that, we are also manipulable in ways that are well-documented. Behavioral economics has spent decades cataloguing the biases that shape how we buy - anchoring, framing, scarcity, social proof, default effects; entire industries from advertising to retail design to dark-pattern UX have grown around exploiting them.
Agents can be manipulated in different and potentially worse ways. If paid resources become part of the agent’s operating environment, resource providers will have incentives to shape that environment so agents spend more. Instead of banner ads or dark patterns, sellers will compete to be the canonical source of truth somewhere in the agent’s stack: in the training data, in the harness, or in the search results the agent consults when exploring the web. The last layer already has a name, AEO, or answer-engine optimization.
Humans have a century of accumulated defenses against commercial manipulation. Agent equivalents are still primitive.
The agent’s incentives are not the buyer’s incentives
Most agents are optimized to complete tasks, and that is not the same as being economically efficient. If the agent has a budget and a goal, it will tend to spend because spending is often the path of lowest friction to completing the task.
Optimizing agents to spend only when the incremental value justifies the cost is hard. It requires training the agent to reason about value, alternatives, confidence, price, urgency, and opportunity cost - capabilities today’s agents are not consistently good at.
Constraining the agent narrows the use case
To mitigate the agency problem you could constrain the agent’s spending authority: small monthly budgets, per-transaction caps, category restrictions, approval thresholds, pre-approved vendor lists. Those help, but they also narrow the practical use case. An agent that can only spend small amounts under tight constraints is most useful for low-dollar, low-risk activity (small API calls, data lookups, one-off enrichments, browser sessions, lightweight compute, low-stakes content access).
Higher-stakes workflows like procurement, vendor selection, travel booking, ad spend, real estate data acquisition, hiring tools, legal services, and financial products will have to wait. Those need a solid governance model that closes the purchasing-intent gap.
The seller-side problem: friction is not always bad
The second part of the MPP story is the seller side. Sellers generally welcome less friction because it can mean more revenue. With no signup, account, API key, or billing relationship, sellers can capture revenue from buyers who would have given up before completing a sale.
However, removing seller-side friction beyond the legacy cruft also means giving up an important control surface.
Regulatory requirements
Most businesses benefit from knowing who their customers are, and for some that knowledge is required. For regulated or semi-regulated services, the seller has to collect a range of information on each buyer: legal entity identity, jurisdiction, business purpose, tax information, beneficial ownership, and user eligibility. In those cases, “no account required” becomes a compliance problem rather than a feature.
A financial data provider, identity verification company, telecom provider, legal data service, or healthcare-adjacent platform cannot expose a paid endpoint to any agent that can send a token, because they need an additional KYC or KYB mechanism before access. MPP does not cover that layer.
Fraud and abuse prevention
API keys and accounts are not just payment artifacts, they are enforcement handles. They let sellers ban bad actors, detect suspicious patterns, revoke credentials when they detect abuse, and comply with legal requests. MPP can support some of this through identity assertions, receipts, wallets, tokens, and emerging agent-identity frameworks. However a full implementation requires a non-trivial effort to rebuild what API key infrastructure already provides. Whether sellers find the payoff worth the cost depends on how much of their revenue actually comes through the MPP channel.
Marketing and customer development
User accounts are not just billing containers, but also relationship containers. When a user signs up for an account, the seller learns who the customer is, what company they represent, what use case they have, how often they use the product, etc. The relationship data feeds upsell opportunities, churn-prevention, and product development.
Contractual restrictions
Digital service providers (data brokers in particular) often have contractual restrictions on how their service can be used. When a customer purchases the service, they accept terms about storage, repackaging, resale, and model training. Beyond a payment, the seller needs identity, entitlement, contractual acceptance, usage declarations, and auditability, and MPP does not eliminate any of that.
A pure anonymous, low-friction pay-per-use model can monetize marginal demand, but it can also weaken the seller’s ability to build a customer relationship, satisfy regulatory and contractual obligations, and prevent fraud.
Where MPP makes sense today
Given the buyer-side and seller-side problems, the realistic MPP use cases are those where the human has already made the buying decision, the seller has acceptable answers to the regulatory and contractual questions, and the buyer-seller relationship is one the seller does not want to formalize.
Below-the-relationship-line demand capture
MPP could let SaaS companies capture demand below the subscription threshold. Use cases include:
- Infrequent buyers who would never consider subscribing
- Exploratory or first-time usage, where the buyer is evaluating whether the service is worth a relationship at all
- Paid APIs and data services where the buyer is already known or pre-approved (search APIs, scraping and browser APIs, AI inference, document conversion, public records lookups, data enrichment)
- MCP servers exposing paid tools that an admin or user has approved once with policy limits
- Low-risk machine-to-machine services like browser sessions, test infrastructure, sandbox environments, file conversion, and rendering
The common thread is that the principal has already approved the resource, and MPP just handles metered access without forcing the buyer through accounts, keys, or subscriptions. For demand the seller would otherwise lose, MPP turns un-monetizable interest into low-overhead pickup money.
However, the seller still has to solve the regulatory and contractual problems. And without a full-fledged customer relationship they will also need to weigh the heightened potential for abuse as well as the potential for cannibalization of their subscription base.
On the buyer side, the value-judgment problem is mostly outsourced (a human decided this paid service is worth it), but the wallet-integration problem is not. Most agent frameworks (LangChain, OpenAI Agents SDK, Anthropic SDK, MCP clients) do not yet have native wallets, and the agent-side ecosystem is currently a small, Tempo-flavored corner of the broader agent infrastructure landscape.
Content micropayments, maybe
Content micropayments have failed many times before. Forrester argues that older micropayment systems failed partly because they assumed humans had to make decisions on tiny purchases. MPP is structurally different because payment becomes a programmatic step rather than a conscious human decision in every instance. However, MPP’s success still hinges on whether agents can judge content value.
An agent that pays $0.05 for an article needs to be able to tell whether that article is better than a free one, whether it is SEO spam dressed up as analysis, or whether the agent is being nudged into premium content farms by upstream optimization. Today’s agents are not consistently good at any of those, and content economics are particularly vulnerable to the manipulation surface (training data, harness, AEO) discussed above.
Bottom line
Most of what humans do during a purchase is not actually about payment. It is about everything around the payment: identity, authorization, permitted use, budget, pricing comparison, seller reputation, contract terms, revocation, audit logs, dispute rights, compliance declarations. Each of those layers exists for a reason, and software that bypasses them does not eliminate the need, it just changes the shape of the problem.
What machine commerce actually needs is machine-friendly versions of each of those layers, so that an agent can satisfy them programmatically rather than route around them. MPP is a promising payment rail. For it to work, the rest of the machine-commerce trust infrastructure has to catch up.