Agentic Payments: MPP, x402, ACP and AP2 Compared

Last updated: October 1, 2026.

AI agents are spending real money. Stripe processed $1.9 trillion in payment volume in 2025 and its newest infrastructure is purpose-built for autonomous buyers. Google has 100+ partners aligned on an authorization standard for agent-initiated payments. x402 has cleared more than 140 million transactions. And Tempo, a new L1, launched specifically as the settlement layer for machine payments.

Four protocols have shaken out as the defining standards: MPP, x402, ACP, and AP2. They don't compete head-on; each solves a different problem at a different layer of the stack. This guide breaks down what each does, how they compare, and which to implement for your use case. (For the wallet layer underneath these protocols — where the keys actually live and spending limits actually fire — see Openfort's agent wallets.)

What are agentic payments?

Agentic payments are payments that an AI agent starts and completes on behalf of a person or a business, inside limits that someone set in advance. No human approves each transaction. The agent pays for an API call, a dataset, compute, or a purchase as part of the task it is running.

Card checkout assumes a human at the screen who types a card number, passes a 3-D Secure challenge, and reads the receipt. An agent can't do any of that, so agentic payments need three pieces that checkout leaves to the human:

• A way to pay. A wallet or a payment credential the agent can use without holding a person's card details.
• Authorization. Proof that the agent is allowed to spend, and limits on how much, where, and how often.
• A machine-callable settlement rail. A payment step that fits inside a request, such as an HTTP 402 Payment Required response, rather than a hosted checkout page.

The four protocols below each standardize part of that stack. None of them decides how much an agent may spend: that limit lives in the wallet underneath. For the wallet layer, see Openfort's agent wallets.

The Four Protocols at a Glance

x402: Permissionless Machine Payments

x402 is the protocol that revived HTTP's long-dormant 402 "Payment Required" status code. Coinbase created it and open-sourced it under Apache 2.0, then donated it: x402 is now developed under the x402 Foundation, operating under the Linux Foundation, with the canonical repository at x402-foundation/x402. For a deeper walkthrough of the protocol and what changed between v1 and v2, see how x402 works.

How it works

A client requests a resource. The server responds with 402 Payment Required and a structured JSON payload specifying the price, accepted asset (typically USDC), and settlement network. The client signs a payment authorization using its wallet. A facilitator verifies and settles the transaction on-chain. The server delivers the resource.

The entire flow happens within a single HTTP request cycle: no accounts, no API keys, no subscriptions, only an HTTP request and a wallet.

When to use x402

x402 is ideal for pay-per-request API monetization, machine-to-machine data feeds, and any scenario where you want fully permissionless, crypto-native settlement. It fits best when the buyer and seller have no pre-existing relationship. A machine can discover an x402-enabled endpoint, pay for it, and consume the response, all without ever creating an account.

The trade-off is that x402 is stateless by design: every request is an independent payment event, and session handling is explicitly listed as out of scope in the specification. For high-frequency micropayments (thousands of calls per session), per-request settlement can become expensive even on L2s. The v2 specification addresses this with a batch-settlement scheme — a signed commitment grants access immediately and value moves later through the network binding — alongside upto for metered pricing and auth-capture for payments that may need to be held, partially captured or refunded. Replay protection is handled in the core spec through 32-byte nonces and validity windows; wallet-ownership proof and signed receipts ship as named extensions (sign-in-with-x, offer-and-receipt) rather than core features.

x402 is not stablecoin-only, despite a common shorthand. x402.org describes the protocol as blockchain-agnostic, supporting all EVM-compatible chains, Solana and more, and extensible to traditional payment methods; stablecoin payments are the primary use case rather than the only one. The exact scheme has published bindings for 16 chains, including Aptos, Stellar, Hedera, Sui, NEAR, Cardano, Starknet and the XRP Ledger, where it settles native XRP or issued currencies. The v2 spec also permits non-blockchain network identifiers in CAIP-2 form, offering ach:us and sepa:eu as examples, and already ships a cloudflare:402 binding under the batch-settlement scheme.

Key numbers

x402 has processed over 140 million cumulative transactions with $600+ million in payment volume. At peak throughput in October 2025, the protocol handled roughly 1 million transactions per week.

MPP: Enterprise-Grade Machine Payments

MPP (Machine Payments Protocol) is, in the words of its own specification repository, "co-authored by Tempo and Stripe" — Tempo being a Layer 1 blockchain incubated by Stripe and Paradigm. The specifications are published by Tempo at tempoxyz/mpp-specs under CC0, with tooling under Apache 2.0 or MIT. It launched on March 18, 2026 alongside Tempo's mainnet, backed by a $500 million Series A at a $5 billion valuation.

How it works

MPP also uses the HTTP 402 status code, but adds a session layer on top. Instead of settling each request individually, an agent pre-authorizes a spending limit — analogous to opening a tab at a bar. The agent then consumes resources and streams micropayments continuously, with all payments within the session batch-settling into a single on-chain transaction. Stripe describes this as "OAuth for money."

The settlement layer is Tempo, a purpose-built payments blockchain with approximately 0.5-second deterministic finality, no re-orgs, and dedicated payment lanes that separate payment traffic from smart contract activity. Critically, Tempo has no native gas token — fees are paid in stablecoins via a protocol-native AMM.

MPP is rail-agnostic. It supports stablecoins on Tempo, fiat cards via Stripe (Visa, Mastercard), buy-now-pay-later providers (Affirm, Klarna), and Bitcoin via Lightning through Lightspark. Payments flow into the merchant's existing Stripe dashboard alongside traditional revenue.

When to use MPP

MPP is the right choice when you need streaming micropayments with session-based pre-authorization, fiat and crypto support on the same endpoints, or Stripe integration for compliance, fraud protection, and merchant tooling. It's designed for enterprises that want machine payments without leaving the Stripe ecosystem.

The trade-off is that MPP is more opinionated than x402. It assumes Stripe as the payment processor and Tempo as the settlement chain. The integration requires the Stripe API and uses SharedPaymentTokens — a Stripe-specific mechanism. This makes it less permissionless than x402 but more enterprise-ready.

It is also worth being precise about how much of MPP's advantage is still architectural. The usual framing is that MPP brings payment-processor semantics that x402 lacks, and that gap has narrowed on two fronts, not one. Batch settlement is the front people cite; the sharper one is the auth-capture scheme, which gives an x402 payment a full authorization lifecycle — hold an amount, capture less than the ceiling once the work is done, cancel it, or return it after the fact. That is the card-network model of authorize-then-capture, and with it refunds and buyer protection become expressible in x402 itself, where previously exact moved a fixed amount once with no way to give it back. What remains genuinely MPP's is the session layer, since session handling is listed as out of scope in the x402 spec, plus settlement on Tempo and access to Stripe's fiat, BNPL and Lightning rails.

Key numbers

MPP launched with 100+ integrated service providers, including Browserbase, DoorDash, Nubank, Ramp, and Revolut. Extension partners include Visa, Mastercard, and Lightspark. Design partners include Anthropic, OpenAI, and Shopify.

ACP: Agent-to-Merchant Checkout

ACP (Agentic Commerce Protocol), created by OpenAI and Stripe, standardizes how AI agents interact with merchants to complete purchases. If x402 and MPP are about machines paying machines, ACP is about agents buying things from stores.

How it works

ACP defines four RESTful HTTP endpoints that model the checkout lifecycle: Create Checkout (agent sends a SKU, merchant creates a cart), Update Checkout (agent modifies quantities, shipping, customer details), Complete Checkout (agent provisions a SharedPaymentToken scoped to a specific amount and merchant, merchant processes payment), and Cancel Checkout (releases held inventory).

The SharedPaymentToken (SPT) is a single-use, time-bound, amount-scoped payment token that lets an agent pay on behalf of a user without ever touching raw card credentials. If the merchant tries to modify the amount, Stripe rejects the charge. The merchant remains the system of record for orders, taxes, and compliance throughout.

When to use ACP

ACP is designed for conversational commerce — an AI agent shopping on behalf of a human user. Think of an agent browsing a retailer's catalog, comparing options, and completing a purchase through dialogue. It's the right protocol when the transaction involves physical or digital goods with structured checkout flows, and when a human user is still the principal behind the purchase (even if they're not clicking buttons).

The trade-off is that ACP is fiat-only (cards and digital wallets through Stripe) and designed for human-present scenarios. It doesn't handle machine-to-machine micropayments, API monetization, or stablecoin settlement. It's a checkout protocol, not a settlement protocol.

Key numbers

ACP's first major deployment was OpenAI's Instant Checkout in ChatGPT, launched in February 2026 with Etsy sellers. Partners include Stripe, Shopify, Salesforce, PayPal, and brands like URBN (Anthropologie, Free People, Urban Outfitters), Coach, Kate Spade, and Revolve.

AP2: Authorization and Trust

AP2 (Agent Payments Protocol), created by Google with over 100 industry partners, solves a different problem: how a merchant or service knows that an agent is authorized to spend money.

How it works

AP2 uses Verifiable Digital Credentials (VDCs) — cryptographically signed mandates based on the W3C Verifiable Credentials standard. Three mandate types cover different authorization scenarios:

• Intent Mandate — Captures conditions under which an agent can purchase autonomously (price limits, timing, categories). Used when the human is not present at the moment of transaction.
• Cart Mandate — Captures the user's explicit authorization for a specific cart with exact items and total. Used when the human reviews and approves before the agent completes the purchase.
• Payment Mandate — Shared with the payment network to signal AI agent involvement and help issuers assess risk.

AP2 functions as an extension for Google's A2A (Agent-to-Agent) protocol and MCP (Model Context Protocol). It doesn't move money itself — it proves that the entity requesting the payment has the authority to do so.

When to use AP2

AP2 is essential for enterprise deployments where auditability and non-repudiation matter. Every agent-initiated transaction carries a cryptographic proof of user intent. This is critical for compliance-heavy industries — finance, healthcare, procurement — where "who authorized this?" needs an answer that holds up in court.

AP2 is payment-agnostic. It works with cards, real-time payment systems (UPI, PIX on the roadmap), and digital currencies. Google has launched an A2A x402 extension in collaboration with Coinbase for agent-based crypto payments, showing how AP2 and x402 compose together.

Key numbers

Partners include Adyen, American Express, Coinbase, Mastercard, PayPal, Visa, Shopify, Worldpay, UnionPay International, and more. Mastercard committed to enabling all U.S. cardholders for agent commerce by holiday season 2025.

How the Protocols Fit Together

These four protocols operate at different layers and are designed to be combined:

A real-world agent workflow might look like this:

1. A user creates an AP2 Intent Mandate authorizing their agent to purchase compute resources up to $50 per day.
2. The agent discovers a cloud GPU provider that supports ACP for structured checkout or x402/MPP for pay-per-request pricing.
3. For an e-commerce purchase, the agent follows the ACP checkout flow, provisioning a SharedPaymentToken through Stripe.
4. For API-level micropayments, the agent opens an MPP session and streams payments per GPU-minute, or pays per-request via x402.
5. The payment mandate from AP2 travels with each transaction, letting the provider verify authorization.

Not every application needs all four protocols. A simple API monetization endpoint only needs x402 or MPP. A shopping agent only needs ACP. But as agent systems grow more complex — orchestrating across multiple services, mixing e-commerce with API consumption, operating across compliance boundaries — the full stack becomes relevant.

Choosing the Right Protocol

You want to monetize an API with pay-per-request pricing

Use x402 if you want fully permissionless, crypto-native settlement with zero setup for buyers. Any wallet-holding agent can pay immediately.

Use MPP if you want session-based billing, Stripe dashboard integration, and support for fiat cards alongside stablecoins. Better for high-frequency callers who benefit from pre-authorized spending limits.

You want agents to buy physical or digital goods from your store

Use ACP to define a structured checkout flow that agents can navigate programmatically. ACP keeps your existing Stripe merchant infrastructure intact and handles cart management, fulfillment options, and payment through SharedPaymentTokens.

You need to prove that an agent is authorized to spend

Use AP2 as the authorization layer on top of whatever settlement protocol you choose. AP2's Verifiable Digital Credentials provide cryptographic proof of user intent, which is essential for enterprise compliance and dispute resolution.

You want the broadest payment rail coverage

Use MPP — it's the only protocol that natively supports stablecoins, fiat cards, buy-now-pay-later, and Bitcoin Lightning on the same endpoint today. x402 is blockchain-agnostic and designed to extend to traditional payment methods, but in practice its shipped bindings are overwhelmingly stablecoin ones. ACP is fiat-only. AP2 doesn't move money.

Who implements these protocols

Choosing a protocol is only half the decision. The other half is which provider gives you the wallet, signing, and settlement underneath it — and those are different questions than they look.

x402 works with any wallet that can produce a standard signature. Protocol compatibility is not the differentiator, because almost everything is compatible. What actually differs is who holds the keys, who submits and pays for the on-chain transaction (the facilitator role), and what limits you can put on an agent before it spends.

Two things follow from this table.

First, the protocol authors are not always the right provider. Stripe wrote MPP and ACP and also ships x402, but you are buying its rails, not a neutral wallet. Coinbase wrote x402 and pairs it with its own wallet product. If you want to stay portable across protocols as the standards settle, the wallet layer is where that portability lives.

Second, the runtime providers — Cloudflare, AWS — solve a different problem than the wallet providers. They make it easy for an agent running on their platform to pay. They do not decide what an agent is allowed to spend. That control belongs to whatever holds the keys, which is why agent wallets with spending policies sit underneath any of these protocols rather than competing with them.

The x402 Foundation came together in two stages. On April 2, 2026, at the MCP Dev Summit North America, the Linux Foundation announced it was launching the x402 Foundation and welcoming the contribution of the protocol from Coinbase — a governing body the Linux Foundation describes as initially developed by Coinbase, Cloudflare and Stripe, with around 22 organizations expressing initial support, among them Adyen, American Express, Circle, Fiserv, Google, Mastercard, Microsoft, Polygon Labs, Shopify, Solana Foundation and Visa. On July 14, 2026, Coinbase's transfer formally completed, putting x402 under vendor-neutral control for the first time, with 40 member organizations and the project formalized as "x402, a Series of LF Projects, LLC." The technical charter in the repository is dated March 31, 2026.

That breadth is the clearest signal that x402 is settling into a standard rather than a single vendor's protocol — and it is why attributing x402 to Coinbase today describes its origin, not its ownership. Cloudflare's presence among the founding developers is also the clearest sign that edge infrastructure is becoming payment-aware: its cloudflare:402 binding is a shipped network identifier in the v2 spec, not a proposal.

Where the Landscape Is Heading

The agentic payments space is moving fast, but three trends are clear:

Convergence, not winner-take-all. Stripe supports both MPP and x402. Google's AP2 has an x402 extension via Coinbase. ACP's SharedPaymentTokens work within MPP sessions. The industry is building a layered stack, not picking sides. Expect more cross-protocol integrations and composite solutions.

Settlement is getting faster and cheaper. Tempo's 0.5-second finality and feeless stablecoin transfers, combined with x402's facilitator batching and L2 settlement, are driving per-transaction costs toward zero. This unlocks use cases — sub-cent micropayments, continuous payment streaming, real-time IoT transactions — that were economically impossible with traditional rails.

Authorization becomes mandatory. As agents move from demos to production, the question of "who authorized this?" becomes non-negotiable. AP2's Verifiable Digital Credentials are the leading answer, but expect payment networks, regulators, and enterprise buyers to demand increasingly formal authorization frameworks. The Wild West phase of agent payments is short.

The total addressable market is substantial. Edgar Dunn & Company estimates AI agents will drive $136 billion in consumer-to-business transaction volume in 2025, growing to $1.7 trillion by 2030. McKinsey projects agents could mediate $3–5 trillion of global consumer commerce by the end of the decade. The protocols that capture this volume are being built now.

For infrastructure builders — whether you're creating APIs, operating marketplaces, or building agent frameworks — the time to integrate is early. The agents are already spending.