AI Agent Payment Protocols Compared: x402, L402, MPP, and Fiat

The problem with protocol proliferation

When Stripe and Tempo launched the Machine Payments Protocol (MPP) on March 18, 2026 — with Visa as a design partner — Jon Markman called it the start of the machine-to-machine commerce era. He was right that the moment was significant — but the coverage missed a critical nuance: Stripe and Tempo were not alone. There were already meaningfully different protocols for agent payments in active production use, each backed by different actors with different assumptions about what AI agents look like, where they run, and who controls the money.

That fragmentation is not an edge case. It is the central infrastructure challenge for anyone building an API, an MCP server, or any other service that AI agents will call and pay for. As Forrester's Meng Liu put it, “those that wait for transaction volumes to materialize will find the identity, trust, and wallet layers already owned by fintechs, card networks, and crypto infrastructure providers.” The question is not whether to support agent payments — it is which protocols, and what happens to the revenue you lose from every agent that speaks a different one.

This article maps the full landscape: how each major protocol works technically, who the stakeholders are, what the real costs and tradeoffs look like, and what the fragmentation means in practice for API sellers and MCP server operators.

Protocol landscape at a glance

x402 — HTTP-native crypto micropayments

x402 is an open protocol proposed by Coinbase that repurposes the long-dormant HTTP 402 Payment Required status code to enable machine-to-machine micropayments at the HTTP layer. When an agent calls a resource that requires payment, the server responds with a 402 status and a payment payload describing the price, accepted tokens, and settlement address. The agent pays on-chain (typically USDC on Base), attaches a signed payment proof in the X-PAYMENT header, and retries. The server verifies the proof and serves the response.

What x402 does well

x402 is elegant in its simplicity: it requires no new infrastructure beyond an EVM-compatible wallet and a standard HTTP client. Payments settle in seconds on Base at near-zero gas cost. Because everything happens in the HTTP layer, it fits naturally into how AI agents already call external tools — as function calls with headers. The protocol is open-source, permissionless, and compatible with the Model Context Protocol (MCP) tool-calling interface.

The hard limit

x402 requires the agent to hold or control a funded crypto wallet. In enterprise settings — where agents run inside corporate infrastructure, are funded from budget line items, and must produce expense reports — this is a significant obstacle. A sales agent that books flights and pays for API calls with USDC from a hot wallet is not a product a CFO approves. x402 is well suited to crypto-native AI ecosystems; it is poorly suited to the enterprise majority of the agent market.

L402 / LSAT — Lightning Network for AI agents

L402 (formerly LSAT — Lightning Service Authentication Tokens) is a protocol developed by Lightning Labs that combines Lightning Network payments with macaroon-based authentication tokens. An agent requests a resource, receives a Lightning invoice, pays it via Lightning, and gets back a macaroon — a cryptographically attenuated credential that encodes the payment proof and can carry spend-limit constraints baked in.

Lightning's sub-cent, near-instant settlement makes L402 technically compelling for high-frequency, low-value agent calls — the kind that dominate LLM tool use. A search API called 1,000 times at $0.001 per call is exactly the workload Lightning was designed for. Projects like LND and emerging agent frameworks have begun exploring L402 as a first-class payment primitive.

Where L402 struggles

Like x402, L402 requires crypto infrastructure — specifically, a funded Lightning channel or custodial Lightning wallet. Routing failures on the Lightning Network, while increasingly rare, add latency and complexity that agents and their orchestrators need to handle. And, crucially, L402 adoption outside the Bitcoin/Lightning ecosystem is nascent. Most enterprise buyers have no Lightning infrastructure whatsoever.

MPP (Stripe + Tempo) — fiat-native agent payments

The Machine Payments Protocol (MPP), co-authored by Stripe and Tempo and launched as an open standard on March 18, 2026 (with Visa as a design partner), represents the most commercially significant development in this space. MPP extends card and bank rails — plus USDC settlement on Tempo, the Layer 1 blockchain co-incubated by Stripe and Paradigm — with an AI-native API surface that lets agents authorize and complete purchases against pre-funded corporate spending accounts, stored payment methods, or on-chain balances. As Jon Markman wrote on his Substack, MPP positions payment processors as “the tollbooth on every agent interaction, collecting fees from both sides.”

For enterprise buyers, this is immediately accessible: the agent is backed by a corporate card program, payments are denominated in fiat (or USDC on Tempo), and the expense flows through existing procurement systems. Stripe handles compliance, fraud detection, and cross-border settlement — the things enterprises actually care about. Because MPP is an open standard, other processors and wallets can implement it too; today Stripe is the dominant implementation.

The concentration risk

MPP solves the enterprise buyer problem but creates a different risk for sellers: platform dependence. An API seller who accepts only MPP via Stripe is invisible to every agent running on a crypto wallet, a Lightning-funded account, or a non-Stripe spending system. The infrastructure choice you make now shapes which agents can reach you later. Stripe's standard card fees — typically 2.9% + $0.30 per transaction — also make sub-cent micropayments economically unviable compared to crypto alternatives, though Tempo settlement can bring those costs down for USDC-denominated flows.

Custena — the multi-protocol proxy

Custena is not a protocol. It is a seller-side proxy that sits between an agent (which might speak x402, L402, MPP, or plain fiat) and a seller's API or MCP server (which just wants to get paid). Custena accepts payments in every major protocol, routes them to the appropriate settlement rail, and pays the seller out in fiat via Stripe Connect or in USDC — regardless of how the agent paid.

The insight behind this approach is that the fragmentation problem is not a protocol problem — it is an integration problem. No single protocol will win cleanly, just as no single authentication standard won cleanly (OAuth, SAML, API keys, and JWTs all coexist today). The value is in the translation layer and the unified compliance ledger that sits on top of it, not in picking the right protocol bet.

How the Custena proxy works for a seller

A seller registers their API endpoint or MCP server URL with Custena and sets a per-call price. Custena issues a proxy URL. When an agent calls the proxy, Custena inspects the payment header (or absence of one), identifies the protocol — x402 payment proof, L402 macaroon, MPP token, or platform balance — and routes accordingly. The seller's backend sees only authenticated, already-paid requests. Revenue accumulates in a dashboard and settles via Stripe Connect. The seller writes zero payment code.

Fiat / API key subscriptions — the status quo

The majority of APIs monetized today use the pre-agent model: API keys, rate limits, and monthly subscription billing via Stripe. This works for human developers who can configure a billing account and read documentation. It does not work for AI agents, which cannot complete a sign-up flow, pass a CAPTCHA, enter credit card details, or manage a subscription. An agent that hits a payment wall either fails silently, hallucinates a workaround, or falls back to a free-tier resource — all bad outcomes for the seller.

The transition from human-centric to agent-centric API monetization is not gradual. Agents are already the majority of API calls at some services. The window to update your monetization infrastructure before it becomes a meaningful revenue problem is closing.

Full comparison matrix

MCP servers: a special case

The Model Context Protocol (MCP), released by Anthropic in late 2024, has rapidly become the dominant standard for exposing tools and resources to LLMs. MCP servers are thin wrappers around APIs — they receive structured tool calls from an LLM, execute the underlying API request, and return structured results. By mid-2026, thousands of MCP servers are publicly available, most of them free.

MCP introduces a specific payment challenge: the MCP protocol itself has no payment primitive. A tool call carries no payment header, no token, no price signal. MCP server operators who want to monetize have to either (a) put a paywall at the MCP server level before the tool call is accepted, (b) wrap the MCP server in an HTTP proxy that handles payment, or (c) integrate a payment SDK into the server itself.

Option (b) — the proxy approach — is what Custena's no-code integration targets. Because MCP servers are accessed over HTTP, a reverse proxy that intercepts the tool call, validates payment, and forwards to the real server requires no changes to the MCP server at all. The server stays a standard MCP server; the monetization layer is entirely in the proxy.

EU AI Act compliance: the sleeper issue

Most protocol discussions focus on the technical mechanics. The EU AI Act compliance angle is underappreciated and commercially significant, especially for enterprise buyers.

Under the EU AI Act, high-risk AI systems — which include many agentic systems operating in regulated domains — must maintain audit trails of automated decisions, including spending decisions. An agent that authorizes API calls and payments must have its activity logged, attributable, and reviewable. x402 and L402 transactions are on-chain and auditable in principle, but not in the format compliance teams expect. Stripe provides transaction records, but not agent-level attribution.

A payment middleware layer that logs every transaction with agent identity, tool called, cost, timestamp, and outcome — and makes that data available via API and dashboard — is not a nice-to-have for EU-operating enterprises. It is a compliance requirement. This is the enterprise moat that raw protocol implementations do not address.

What this means for API and MCP server operators

The honest takeaway from this landscape is that there is no correct protocol bet to make right now. x402 will dominate crypto-native agent ecosystems. MPP will dominate enterprise agent budgets through Stripe and its card-network partners. L402 will remain relevant for Bitcoin-native tooling. None of these will disappear.

What this means practically for an API or MCP server operator:

• Supporting only one protocol means being invisible to every agent that speaks a different one.
• Building native support for each protocol means maintaining separate payment logic, separate settlement flows, and separate compliance records for each.
• Using a protocol-agnostic proxy layer means one integration, full coverage, with the settlement and compliance complexity abstracted away.

The payment layer for agentic commerce is not a single protocol. It is the infrastructure that speaks all of them.

Sources and further reading

• ↗Jon Markman (Substack) — Payments Without People: Stripe's New Machine Payments Protocol (March 20, 2026)
• ↗Meng Liu (Forrester) — Why Stripe's Machine Payments Protocol Signals a Turning Point for Micropayments (March 23, 2026)
• ↗Stripe — Machine Payments Protocol (MPP) announcement
• ↗Coinbase — x402 Protocol (GitHub)
• ↗Lightning Labs — L402 / LSAT Documentation
• ↗IETF RFC 9110 — HTTP Semantics: 402 Payment Required
• ↗Anthropic — Model Context Protocol (MCP) Introduction
• ↗Lightning Labs — LND (Lightning Network Daemon)
• ↗Custena — Integration Docs
• ↗Custena — Why AI Agent Payments Are the Future of Commerce Infrastructure
• ↗Custena — Ant Group, Alibaba, and the Race to Own AI Agent Payments in Asia