Four protocols come up in nearly every agentic payments conversation right now: x402, AP2, MPP, and ACP. Most coverage frames this as a race, with one standard winning and the rest fading. The question is not which standard wins, but which ones you have to support. These four protocols mostly solve different problems at different points in the transaction, and a production agent system will likely touch more than one of them.
Here is what each one does, where they overlap, and what none of them handle.
What an AI Agent Has to Settle Before It Can Pay
Strip an agent-initiated payment down and it resolves into three distinct layers:
- Permission: A human has to have authorized the agent to spend, with limits on what, how much, and for how long. A merchant or card network receiving the transaction needs a way to verify that authorization exists.
- Commerce: The agent and the merchant have to agree on what is being bought, at what price, under what fulfillment terms, and who remains the merchant of record. That agreement has to be held without a human reading a checkout page.
- Settlement: Value has to move over a specific rail, within a specific finality window, and the agent needs confirmation it cleared before acting on it.
The four protocols cluster around these layers, which is why they read as competitors more often than they are. None of them tries to cover all three.
The Four Protocols and the Role Each One Plays
x402: Settlement Over HTTP
x402 revives the dormant HTTP 402 “Payment Required” status code. An agent requests a resource and the server returns a 402 carrying a structured payload with the price and accepted asset. The agent pays in stablecoins and access is granted within the same request cycle, with no account, no subscription, and no checkout page in between.
The protocol now sits with the x402 Foundation, which launched operationally with 40 member organizations including AWS, Circle, Cloudflare, Google, Mastercard, and Visa. Chainalysis counted more than 100 million cumulative x402 transactions on Base through Q1 2026, with value concentrating in larger payments rather than sub-cent calls. That concentration tracks where the protocol fits best, which is machine-to-machine flows such as API calls, inference, data access, and compute.
AP2: Authorization and Trust
AP2, the Agent Payments Protocol, launched in September 2025 with more than 60 partners including Mastercard, American Express, and PayPal. It sits at the permission layer, representing every agent purchase as three cryptographically signed mandates carried as verifiable credentials: an Intent Mandate for what the user asked for, a Cart Mandate for what the agent assembled, and a Payment Mandate for what gets charged. Each is signed by the user’s wallet or the agent’s key and passed between parties as a verifiable object.
AP2 does not move money. It travels alongside the transaction so merchants and networks hold verifiable proof of what was authorized, which is what makes dispute handling and audit possible when no human was present at checkout. It is rail-agnostic by design, covering cards, bank transfers, and stablecoins.
MPP: Sessions and Streaming
The Machine Payments Protocol launched in March 2026, co-authored by Stripe and Tempo and released the same day Tempo’s network went to mainnet. Its distinguishing primitive is the session. An agent pre-authorizes a spending limit once, then streams granular micropayments through an ongoing task without an onchain transaction per interaction.
MPP is rail-agnostic by design. Stablecoins settle natively on Tempo, Visa extended it to card payments across its network, and Lightspark adapted it for Bitcoin over the Lightning Network. More than 100 services were listed in the launch directory, spanning model providers, developer tools, compute platforms, and data vendors.
ACP: Consumer Checkout
The Agentic Commerce Protocol was co-developed by OpenAI and Stripe and open-sourced in September 2025. It standardizes checkout between an AI surface and a merchant, defining a common set of operations to create, update, complete, and cancel a checkout. The agent passes a narrowly scoped payment credential, and the merchant charges it through its existing payment provider while retaining the catalog, pricing, branding, fulfillment, and dispute handling.
ACP stays oriented toward consumer purchases of physical and digital goods on fiat rails rather than agent-to-service payments.
How the Four Agentic Payment Protocols Compare
| Protocol | Layer | Role | Rails | Best Fit |
| x402 | Settlement | Payment inside the HTTP request cycle | Stablecoins, onchain | Agents paying per API call, dataset, or compute job |
| AP2 | Permission | Verifiable proof of what a user authorized | Rail-agnostic, cards to stablecoins | Any flow needing provable spending authority and an audit trail |
| MPP | Settlement | Session-based authorization and streaming payment | Stablecoins, cards, Lightning Network | Metered or ongoing agent workloads |
| ACP | Commerce | Checkout between an AI surface and a merchant | Fiat via existing PSPs | Conversational purchases of goods |
Where the Protocols Stop
All four protocols define how a payment is requested, authorized, or settled. None of them define where the agent’s keys live, how spending limits are enforced before a transaction is signed, how a suspected compromise gets cut off mid-session, or how any of it gets reported for compliance and reconciliation. Those controls sit in the wallet and policy layer underneath.
That gap is the reason Fireblocks joined the x402 Foundation and contributed a security extension adding request integrity and spend governance to the protocol. Protocol maturity and operational readiness advance on different timelines, and financial institutions need both.
Which is also why the practical answer is to assume you will support more than one. Card networks, cloud providers, and PSPs have joined multiple protocol efforts at once, which is a reasonable signal about how this settles out. The durable question for a payments team is not which protocol to bet on, but whether the wallet, policy, and reporting layer underneath can support several without a rebuild each time a new spec ships.
Learn more about Fireblocks Agentic Payments Suite, and request access today.
