x402 vs AP2 vs L402 vs Stripe: Agent Payment Rails Compared

"Which agent payment protocol should I pick?" is the wrong question until you say what the agent is paying for. A script buying a single API call for a fraction of a cent needs different plumbing than an assistant booking flights with a human's card. Most "x402 vs AP2" comparisons blur those two layers - and then reach conclusions like "Google beat Coinbase" that do not mean anything.

This article compares x402 with the protocols it is most often confused with or genuinely competes against: the Machine Payments Protocol (MPP) from Stripe and Tempo, L402 from the Lightning ecosystem, Google's AP2, the Agentic Commerce Protocol (ACP) from OpenAI and Stripe, the card network protocols from Visa and Mastercard, Cloudflare Pay per crawl, and plain API keys with invoicing. The picture reflects October 2026; this space changes every quarter, so each protocol links to its primary source.

Two different questions: pay per request and delegated purchase

Group the protocols by the problem they solve.

Pay per request (machine-to-machine). The client - usually software with no human at the keyboard - wants a specific HTTP resource and pays for it inside the request itself. Typical amounts are cents and fractions of a cent, transaction counts are high, and the customer has no account with the seller. This is where x402, MPP, L402 and Cloudflare Pay per crawl live. All four are built on the 402 Payment Required status code.

Delegated purchase (delegated commerce). A human authorizes an agent to shop on their behalf: a cart, delivery, a card, returns. The key question is not "how do we move value" but "how do we prove this human approved this purchase, and within what limits". This is AP2, ACP, Visa Trusted Agent Protocol and Mastercard Agent Pay. The money moves over existing card or bank rails.

The second group does not replace x402; it can use x402 as one of its payment methods. The real contest is inside the first group, mainly between x402 and MPP.

The one-screen overview

x402: payment as part of HTTP

x402 is the oldest and most widely used of the new generation of "402 protocols". Coinbase published it in May 2025, contributed it to the Linux Foundation in April 2026, and in July 2026 the standalone x402 Foundation began operating with 40 members; the premier members include Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Shopify, Stripe and Visa. According to the counter on x402.org, the protocol handled more than 75 million transactions worth roughly 24 million dollars in the last 30 days.

For comparison purposes the essence is enough (the Slovak edition has a step-by-step walkthrough):

• the server returns 402 with a list of acceptable payments in the PAYMENT-REQUIRED header: scheme, network, asset, amount, recipient,
• the client signs an authorization offline and retries with a PAYMENT-SIGNATURE header,
• a facilitator verifies the payment and settles it on-chain; the funds go straight to the seller's address.

Strengths. No sign-up and no API key, settlement in seconds with no chargebacks, amounts down to fractions of a cent, neutral governance and the broadest ecosystem: several facilitators, the Bazaar catalog for automatic service discovery, the x402scan explorer, SDKs in TypeScript, Python, Go and Java. V2 added extensions for wallet identity (repeat access without paying again), dynamic recipients and a formal place for facilitators of traditional rails (ACH, SEPA, cards). Since June 2026 charging AI agents via x402 is also built into AWS WAF: a site behind CloudFront turns it on with configuration, no custom code, from 0.001 USDC per request.

Weaknesses. In practice you get paid in stablecoins on a public blockchain. The client needs a wallet holding USDC or EURC, your accounting needs a procedure for crypto-assets, and card payments exist more in the specification than in deployments. Identity is pseudonymous (a wallet address), so KYC and sanctions screening stay with the facilitator or with you. The facilitator is an operational dependency: the CDP facilitator offers the first 1,000 transactions per month free and charges 0.001 USD per on-chain transaction after that.

When to reach for x402. Paid APIs and MCP tools for agents, data services, pay-per-crawl on your own infrastructure - anywhere the customer is software and the price of one request makes no sense for a card.

MPP: Stripe and Tempo build a competing 402

Stripe and Tempo (the blockchain Stripe incubated with Paradigm) introduced the Machine Payments Protocol in March 2026. It solves the same problem as x402 and also uses status 402, but packages the data differently: the payment challenge travels in the standard WWW-Authenticate header with a new Payment authentication scheme, and the client answers with Authorization: Payment .... The core is submitted as an IETF draft (draft-ryan-httpauth-payment) and the specifications are licensed CC0.

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="...", realm="api.example.com",
  method="tempo", intent="charge", request="<base64url JSON>",
  expires="2026-10-18T12:00:00Z"

The request value carries the amount, currency and recipient. A server may send several challenges at once, for example tempo and stripe, and the client picks one. Beyond a one-off charge, MPP defines further intents (authorize, subscription) plus extensions for discovery and identity.

Strengths. One protocol for several payment methods: stablecoins on the Tempo network, cards via Stripe Shared Payment Tokens, ACH bank transfers and, according to Tempo's documentation, Lightning. A seller with a Stripe account receives the money in a regular Stripe balance, and Stripe can cover the network fees for the client. A clean design on top of existing HTTP authentication machinery has a real shot at IETF standardization.

Weaknesses. A young protocol with one dominant operator. The stablecoin branch is tied to the Tempo network, the card branch to Stripe with a 0.50 USD minimum. The ecosystem of clients, wallets and directories is an order of magnitude smaller than x402's.

When to reach for MPP. If you already run on Stripe, want to offer agents cards and stablecoins without operating crypto yourself, and do not mind being early on a new network. Stripe is also a premier member of the x402 Foundation, so the two paths can run in parallel.

L402: bitcoin, Lightning and macaroons

L402 (originally LSAT) is the oldest attempt to give status 402 meaning; Lightning Labs has used it since 2020. The server answers 402 and sends two things in the WWW-Authenticate header: a Lightning invoice and a macaroon, a cryptographic capability token bound to the payment hash. The client pays the invoice, receives the preimage as proof, and sends further requests with Authorization: L402 <macaroon>:<preimage>. The server verifies both without a payment database.

HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="AGIAJEemVQUTEyNCR0exk7ek90Cg==", invoice="lnbc10n1p..."

Strengths. Micropayments in satoshis with instant off-chain settlement and no gas fees. Macaroons are elegant: a capability can be narrowed (read-only, this directory only) and delegated to another agent without involving the server. In February 2026 Lightning Labs released lightning-agent-tools: the lnget client that pays 402 challenges automatically, the Aperture proxy for the seller side, a separate key signer and an MCP server.

Weaknesses. Payment is in bitcoin only; a price in euros or dollars is converted and fluctuates. Both seller and client need access to a Lightning node with channels and liquidity, or a custodial service. There is no neutral governance, no standard discovery mechanism and little support outside the bitcoin community.

When to reach for L402. If your service and your customers live in the bitcoin ecosystem, or you want prices in satoshis and settlement without any on-chain write.

Cloudflare Pay per crawl: 402 without crypto

Cloudflare solves exactly one case: charging AI crawlers on sites that run behind it. The operator sets one price per request and chooses allow, charge or block for each crawler. The crawler identifies itself with a Web Bot Auth signature (an Ed25519 key and the Signature-Agent, Signature-Input and Signature headers) and handles the price either reactively (a 402 with a crawler-price header, retried with crawler-exact-price) or proactively (crawler-max-price on the first request). Cloudflare is the merchant of record: it bills the crawlers and pays the site operators in fiat.

For a site owner it is the simplest path, but a closed one: it works only behind Cloudflare, only for registered crawlers, and at the time of writing still in private beta. Cloudflare is also a co-founder of the x402 Foundation, so an overlap of the two worlds is to be expected. Anyone who wants to charge crawlers with an open protocol today can use x402 via AWS WAF or their own middleware.

AP2: Google and the proof that a human agreed

Google introduced the Agent Payments Protocol in September 2025 with some sixty partners as an extension of the A2A protocol. Version 0.2 shipped in April 2026 and Google donated the protocol to the FIDO Alliance, where a payments working group develops it together with Mastercard's Verifiable Intent. AP2 does not move value; it defines mandates: signed verifiable credentials with which the user first sets what the agent may buy (budget, allowed payment instruments, time window) and then approves a specific cart and amount. The chain of credentials creates an audit trail for the merchant, the credentials provider and the card network, including scenarios where the human is not present at purchase time.

Payment methods are deliberately kept separate: the first version targets cards, with wallets, push payments and digital currencies on the roadmap. For crypto-assets there is the A2A x402 extension, which Google developed with Coinbase, the Ethereum Foundation and MetaMask: the AP2 mandate authorizes the purchase and x402 settles it. On the shopping side it connects to the Universal Commerce Protocol (UCP) from January 2026, which Google built with Shopify and Etsy.

When AP2 makes sense. When you are building a shopping agent for humans and the merchant and the bank need to prove customer consent. For a paid API it is needlessly heavy gear.

ACP: checkout inside ChatGPT

OpenAI and Stripe released the Agentic Commerce Protocol at the end of September 2025 under the Apache 2.0 license; it powers Instant Checkout in ChatGPT. The merchant publishes a checkout interface (REST or MCP), the agent assembles the order in the chat and hands over payment through a Shared Payment Token: a one-time token bound to a single merchant and a specific amount, so ChatGPT never sees the card number. The merchant remains the merchant of record and decides on order acceptance, taxes, delivery and returns.

ACP is an e-commerce product, not a machine payment rail: minimums and fees are card-level, a human makes the decisions in the conversation, and distribution depends on the platforms that implement it. It competes head-on with AP2 and UCP over whose interface people will shop through in chat.

Card networks: Visa Trusted Agent Protocol and Mastercard Agent Pay

Visa and Mastercard are not inventing a new way to move money; they are solving how to recognize an agent and attach a card to it. Mastercard Agent Pay (April 2025) issues agentic tokens from the MDES tokenization service: the token stands in for the cardholder's card, is bound to a specific agent and purchase policy, and the card number never reaches the agent or the merchant. Visa Trusted Agent Protocol (October 2025, with Cloudflare) builds on HTTP Message Signatures just like Web Bot Auth: the agent registers, its public key sits in a directory, and every request carries a signature with a timestamp and a nonce; a tag in the signature separates browsing from payment.

For a merchant the advantage is accepting cards exactly as before, fraud protection and chargebacks included. For an API provider it is unusable for micropayments and assumes a cardholder stands behind the agent.

API key and invoicing: the null option

The most common "alternative" to x402 is doing nothing: the customer signs up, gets an API key and pays monthly by usage. For human B2B customers it remains the best choice - familiar accounting, contracts, limits, support. For an agent it is a wall: a form, an e-mail, a card, often KYC, all before it can even tell whether the service is worth it. The first group of protocols removes that wall. Nothing stops you from offering both: API keys for regular customers, 402 for occasional and machine ones.

Technical comparison

The table simplifies: in every row the details of the specific facilitator, PSP or network decide.

What to pick by use case

Can the protocols be combined

Yes, and most of the time that is the right answer. The first group is designed so a server can offer several options in one 402 response: x402 has the accepts array, MPP allows several WWW-Authenticate headers. Nothing stops one service from accepting both x402 and MPP while still selling API keys. The second group can adopt x402 as a payment method; that is exactly what the A2A x402 extension does. And since Stripe, Visa, Mastercard, Google and Cloudflare all sit in the x402 Foundation, convergence looks more likely than a standards war.

Practical advice for an EU API provider: start with x402 (least work, most clients), watch MPP for cards, and do not get pulled into AP2 or ACP until you sell goods to humans through chat.

Where to go next

• What is x402 - the introduction to the protocol,
• Ecosystem - facilitators, explorers and directories,
• primary sources: x402 specification, MPP, L402, Cloudflare Pay per crawl, AWS WAF AI traffic monetization, AP2, ACP, Visa Trusted Agent Protocol.