Stripe MPP Explained: The Fifth Agent Payment Protocol
Stripe MPP Explained: The Fifth Agent Payment Protocol
Five major protocols now govern how AI agents pay for things. For most of 2025 and early 2026, developers had four to evaluate: x402 from Coinbase, AP2 and UCP from Google, and ACP from Stripe. On March 18, 2026, that changed. Stripe launched MPP — the Stripe Machine Payments Protocol — and if you’re building on agent infrastructure today, the distinction matters more than the name suggests.
This post explains what the stripe MPP machine payments protocol actually is, why it’s categorically different from Stripe ACP (which already existed), and where it sits in the now five-protocol landscape. If you’ve been watching the space, the launch also reframes a few decisions you may have already made.
What Is Stripe MPP (Machine Payments Protocol)?
MPP stands for Machine Payments Protocol. Most payment infrastructure — including Stripe’s existing ACP — assumes a human somewhere in the loop: authorizing, reviewing, occasionally disputing. MPP drops that assumption entirely.
The core design decisions in MPP reflect machine-native requirements:
- No human confirmation step. Transactions are initiated, authorized, and settled programmatically. There is no checkout flow, no approval modal, no session-based authentication.
- Sub-cent granularity. The protocol handles micropayments at the resolution agents actually need — $0.001 for a single API call, not rounded to the nearest cent. This is a hard requirement for agent-native billing that most payment rails fail silently.
- Fiat and stablecoin hybrid. Unlike x402, which is crypto-native and requires stablecoin infrastructure on both sides, MPP supports traditional fiat settlement and stablecoin rails in a single protocol surface. Developers choose their settlement layer; the protocol handles both.
- Built on Stripe’s existing network. MPP inherits Stripe’s compliance coverage, fraud detection infrastructure, and global merchant reach — without requiring developers to add a new vendor.
In practice, MPP behaves more like an API billing protocol than a traditional payment protocol. It’s purpose-built for the scenario where an agent pays $0.003 for a web scraping call, then $0.008 for a vector search, then $0.15 for a high-quality LLM completion — all in the same workflow, all without any human approval in the chain.
How Is Stripe MPP Different from Stripe ACP?
This is the question developers are asking most, and it has a precise answer. Stripe now has two agent-related protocols. They are not interchangeable.
| Stripe ACP | Stripe MPP | |
|---|---|---|
| Full name | Agent Commerce Protocol | Machine Payments Protocol |
| Primary use case | Agent buys from a merchant (consumer commerce) | Machine pays machine (infrastructure commerce) |
| Typical transaction | Agent books a flight, purchases software | Agent pays for API call, vector DB query, LLM token |
| Merchant relationship | Extension of existing Stripe merchant network | No merchant relationship assumed |
| Settlement | Fiat (USD, EUR, etc.) | Fiat + stablecoin hybrid |
| Micropayment support | No — standard checkout flows | Yes — sub-cent granularity |
| Identity model | Consumer identity via Stripe account | Machine identity, no account required |
| Launched | 2025 | March 18, 2026 |
The short version: ACP is for agents acting as buyers in consumer-facing commerce. MPP is for agents paying infrastructure services directly — other machines, APIs, data providers, compute resources.
If your agent books a hotel room, that’s ACP territory. If your agent pays $0.002 per document it processes through a third-party extraction service, that’s MPP.
Conflating them will cause you to make wrong infrastructure decisions. Stripe built two different things here deliberately.
How Does Stripe MPP Compare to x402?
The more interesting comparison for developers evaluating protocol architecture is MPP versus x402 — both are explicitly designed for machine-to-machine payments, and both handle sub-cent transactions.
| x402 (Coinbase / x402 Foundation) | Stripe MPP | |
|---|---|---|
| Payment rail | Crypto-native (stablecoin, USDC) | Fiat + stablecoin hybrid |
| Fiat support | No | Yes |
| Open standard | Yes | Stripe-controlled |
| HTTP-native | Yes — single HTTP header | Protocol-specific implementation |
| Sub-cent capable | Yes | Yes |
| Edge deployment | Yes — Cloudflare partnership (March 2026) | Stripe-native only |
| Crypto wallet required | Yes | No |
| Developer onboarding | Requires stablecoin infrastructure | Stripe account (existing) |
| Settlement finality | On-chain | Stripe settlement pipeline |
The honest tradeoff: x402 is more open and more crypto-native. If your infrastructure already runs on stablecoin rails, or if you’re building for global reach where fiat settlement is a constraint rather than a feature, x402 is the right call. MPP is more accessible to developers already using Stripe — machine-native payment infrastructure without adding a wallet or stablecoin dependency.
x402’s Cloudflare partnership, announced in March 2026, adds edge-native HTTP payment capability that MPP doesn’t currently match. For agents deployed on Cloudflare Workers infrastructure making per-request payments, that’s a meaningful architectural advantage for x402. MPP’s fiat compatibility is the counterweight — relevant for enterprise buyers and compliance-constrained environments where crypto settlement isn’t on the table.
For context on how this comparison fits the full protocol landscape, see Every Agent Payment Protocol Compared (2026).
Where Does Stripe MPP Fit in the Five-Protocol Landscape?
With MPP’s launch, the agent payment protocol space has five distinct entries, each designed along a different primary axis:
| Protocol | Issuer | Primary design axis | Fiat | Crypto | Best fit |
|---|---|---|---|---|---|
| x402 | Coinbase / x402 Foundation | Open standard, HTTP-native micropayments | No | Yes (USDC) | Crypto-native stacks, per-request API payments |
| AP2 | Agent authorization and delegation | Via partner | No | Google ecosystem, A2A auth chains | |
| UCP | Universal agent commerce at scale | Yes | No | Enterprise, Google-scale deployments | |
| ACP | Stripe | Consumer agent commerce via existing merchants | Yes | No | Agents buying goods and services |
| MPP | Stripe | Machine-to-machine infrastructure payments | Yes | Yes (hybrid) | API billing, metered services, infrastructure payments |
No single protocol wins every scenario. A developer building an agent that books travel needs ACP. A developer building an agent that processes documents through a pipeline of paid APIs needs MPP. A developer building for a crypto-native stack benefits from x402. An agent operating in Google’s enterprise cloud ecosystem needs AP2 and UCP in scope.
This is the actual architecture decision in 2026. It is not as simple as picking the protocol with the most press coverage.
For a full comparison that includes Mastercard Agent Pay and Visa Intelligent Commerce, see the 2026 protocol comparison post.
What Does MPP Mean If You’re Building Agents Today?
Three practical implications for developers:
Your existing Stripe account just became agent payment infrastructure. If you already use Stripe for billing, MPP gives you a path to agent-native API billing without adding new vendors or wallet infrastructure. No new compliance onboarding, no new settlement pipeline, no crypto keys to manage.
Sub-cent economics are now accessible on fiat rails. Before MPP, if you wanted to charge or pay at sub-cent granularity, you needed crypto infrastructure (x402) or a custom IOU token model. MPP brings that granularity to fiat. If you’re building a metered service that agents will consume, MPP changes which pricing models are viable.
Five protocols is not simpler than four. The rational response to a growing protocol landscape isn’t to pick one and ignore the rest — it’s to build on infrastructure that handles the routing decision for you.
ATXP is compatible with all five major agent payment protocols. When an agent makes a payment through ATXP, the platform handles which rail to use based on the transaction type, amount, currency, and merchant requirements. The agent doesn’t carry the protocol decision — it just gets an answer and a receipt.
That’s the staircase basement argument applied directly: the industry keeps adding more stairs (more protocols), but the payment abstraction layer underneath is still what’s missing for most agent developers.
Connect your agent to ATXP at atxp.ai — one integration, every protocol, no credential sprawl.
What About ATXP Credits vs. MPP Payment Primitives?
MPP introduces its own pre-authorized payment primitives for machine-to-machine transactions. It’s worth being precise about how these relate to ATXP’s model.
ATXP credits are ATXP’s specific implementation of IOU tokens — conceptually similar to dollars held in a Starbucks wallet or airline eCredits. They can be used within ATXP’s merchant network, but only there. The value is pre-committed and spendable programmatically by agents, with hard limits enforced at the infrastructure level.
MPP’s machine-payment primitives are Stripe-native and settle against Stripe’s payment infrastructure. They’re not interchangeable with ATXP credits. An ATXP-connected agent can route transactions through Stripe MPP rails for merchants that support it — but the credits and the protocol are different layers.
For a full breakdown of how IOU tokens, shared payment tokens (Stripe’s SPTs), and virtual cards differ as models, see Shared Payment Tokens, Virtual Cards, and IOU Tokens: What’s the Difference?.
Agent identity — which matters for MPP’s machine identity model — is covered in Know Your Agent (KYA).
FAQ
Does Stripe MPP replace Stripe ACP? No. ACP is for agents acting as consumers in existing merchant relationships — booking flights, purchasing software licenses. MPP is for machine-to-machine infrastructure payments where no merchant relationship exists. Most production agentic systems will eventually need both, operating at different layers.
Is Stripe MPP available to all Stripe users? MPP launched March 18, 2026. Availability is rolling out — check Stripe’s developer documentation for current access status. ATXP users building on Stripe infrastructure will get MPP compatibility through ATXP’s protocol routing as it reaches general availability.
Does MPP require stablecoin support on the developer side? No. The fiat and stablecoin hybrid design means standard fiat settlement works out of the box. The stablecoin rails are available for developers who want them — not required for those who don’t. This is one of MPP’s key advantages over x402 for fiat-first developers.
How does MPP handle agent identity? MPP uses machine identity — it doesn’t require a traditional consumer account or merchant relationship. This is the key architectural difference from ACP, which extends existing Stripe merchant relationships into the agent context. For a broader look at agent identity standards across the industry, see Know Your Agent (KYA): The Identity Standard That Makes Agent Payments Safe.
Where does x402 fit now that MPP exists? x402 remains the leading open, crypto-native protocol for machine-to-machine payments. MPP provides a fiat-native alternative with Stripe’s infrastructure backing. x402’s open standard status, Cloudflare edge partnership, and HTTP-native design make it the better choice for crypto-infrastructure deployments and for developers who want a protocol that no single company controls. The two protocols serve overlapping but not identical markets — and ATXP routes to both.