AP2, ACP, x402, MPP: the agent payments stack explained for builders

“AP2 vs x402” headlines keep getting written, and they keep being the wrong frame. The four specs at the center of agent payments in May 2026, AP2, ACP, x402, and MPP, do not compete. They sit at different layers of the same stack, and the work for builders is composing them, not picking one. Treating them as competitors is the same category mistake as asking whether OAuth competes with TLS.

This piece walks each layer. What it does, what it does not do, what is adoption-ready in May 2026, and where the seams sit when you put the four together. The aim is the operational picture a builder needs to decide what to integrate, in what order, and how each piece hands off to the next.

Tobira does not own a layer in this stack. Tobira composes alongside it. The piece closes with where the @handle layer sits relative to the four payment specs, because that is the question that comes up every time the stack diagram gets drawn.

Why a stack, not a spec

Payments online are never one operation. They are at least four, and the same is true for agent payments. The four specs at the center of the stack each answer a different question, and skipping any one of them produces a system that works in a demo and breaks the first time a real merchant or a real refund appears.

The first question is authorization. Who is allowed to spend, what may they spend it on, up to what limit, and for how long. The web answers this with OAuth scopes and refresh tokens; the agent stack answers it with AP2, a signed mandate from a human to an agent.

The second question is checkout. What exactly is being purchased, at what price, on what terms, with what acknowledgment from the merchant. The web answers this with cart APIs and the messages a merchant returns at the order-confirm step; the agent stack answers it with ACP, the structured negotiation between buyer-agent and seller-agent.

The third question is settlement. How does value actually move from one account to another, atomically, with idempotency, with a receipt. The web answers this with Stripe, Adyen, ACH, wire, or stablecoin rails depending on context; the agent stack answers it, in May 2026, with x402, the HTTP-native protocol that carries settlement on the HTTP 402 Payment Required status code.

The fourth question is metering. When the workload is not a one-shot purchase but a continuous flow (an LLM streaming tokens through an intermediary agent, an API granting per-second access, a tool call billed by milliseconds of compute), the cart model breaks. The web has subscription billers and metered APIs; the agent stack has MPP, the Machine Payments Protocol, for continuous in-flight settlement.

Pick the wrong spec for the wrong question and you build the wrong thing. Adopt only x402 and your agent moves value with no authorization boundary; spend caps live in app code, not at the auth layer, and the next time you change a limit you ship a deploy. Adopt only ACP and you have a cart with nowhere to settle. Treat the four as one stack and the seams line up; the rest of this piece walks each layer in order so the seams are explicit.

AP2: authorization (the mandate before the payment)

AP2, the Agent Payments Protocol, was introduced by Google around a single operational primitive: a cryptographically signed mandate from a human to an agent that bounds what the agent may spend on the human’s behalf. The mandate carries a limit, a category, a merchant constraint, and an expiry. The agent presents the mandate alongside any payment attempt; the verifier checks the signature and the bounds before letting the payment proceed.

The reason this matters is the gap in the web payments analogy. OAuth scopes have ACL-style granularity (“can read your email,” “can post to your timeline”) but they were never designed to bound dollar amounts, merchant categories, or per-day caps. When you give an LLM-powered agent an API key to your payment provider, the provider sees a generic API client. There is no spend cap at the auth layer; there is only the cap you remembered to write in your app code. AP2 closes that gap by making the mandate the unit of authorization, not the API key.

The token format matters too. AP2 mandates are signed, time-bounded, and presentable to multiple downstream layers. An ACP buyer-agent presents the mandate as part of the checkout proposal so the seller-agent can pre-verify the engagement will clear authorization before negotiating terms. An x402 client presents the mandate alongside the payment-attached HTTP header so the settlement layer can verify the bounds before the on-chain move. An MPP streamer presents the mandate to its metering loop so an over-budget tick blocks the flow before it bills. One token, three different consumers, one canonical authorization decision.

Adoption status in May 2026: AP2 is in spec-and-pilot phase. Google is the primary author; partner integrations are underway. Production-ready in the sense that a builder can implement against the spec; production-deployed in the sense that real merchants accept AP2 mandates today is narrower than the announcement makes it sound. The realistic expectation for builders is to design for AP2 as the authorization slot in the architecture while running interim controls (rate limits, hardcoded caps, manual approval gates) until the partner ecosystem catches up.

The seam to remember: AP2 produces a verifiable token. Every downstream layer in the stack consumes it. Treat AP2 as the bouncer at the door; everything that happens after is contingent on the mandate being present and within bounds, and the moment you let a payment flow forward without one you have rebuilt the unbounded-API-key problem under a new name.

ACP: checkout (the structured cart between buyer and seller)

ACP, the Agentic Commerce Protocol, comes from OpenAI and Stripe (launched September 2025, in beta with founding-maintainer governance heading toward a neutral foundation). Where AP2 says who may spend, ACP says what is being bought. The protocol carries the structured negotiation between a buyer-agent and a seller-agent: the proposed purchase, the price, the metadata, the merchant’s acknowledgment, and the receipt-shape that closes the transaction. The cart is the unit.

The reason this matters is the reconciliation problem. A settlement layer, x402 or otherwise, moves value and writes a transaction hash. The transaction hash by itself does not know what the value was for. Was it a one-shot tool call, a monthly subscription, a refundable purchase, a donation? Without structured checkout metadata, every downstream operation that depends on knowing the answer (refunds, disputes, accounting categorization, tax reporting, merchant-side fulfillment) has to reconstruct the intent from out-of-band signals, and reconstruction is where reconciliation breaks.

ACP packages the intent. A buyer-agent proposes a purchase as a structured ACP message: line items, prices, merchant identifier, fulfillment expectations, refund policy reference. The seller-agent accepts, counters, or rejects, also as a structured message. When both sides have agreed, the resulting checkout intent is the input to the settlement layer; x402 (or any other settlement primitive) settles against that intent, not against a free-form integer dollar amount.

The seam matters in both directions. Upstream, ACP consumes the AP2 mandate so the seller-agent can pre-check whether the buyer is authorized for the proposed cart before any negotiation work happens. Downstream, ACP hands x402 a structured intent so the settlement layer can produce a receipt that carries the cart-level metadata into the audit log. The link between intent and settlement is what makes a refund possible without escalating to a human review queue every time something needs to be reversed.

Adoption status in May 2026: ACP has a public beta spec maintained by OpenAI and Stripe and is moving toward broader merchant integration. The shape of the protocol is set; the surface area of accepting merchants is still small. The realistic expectation for a builder is the same shape as AP2: design for ACP as the checkout slot, run interim cart-management in app code, and migrate to ACP as merchant counterparties come online.

A builder writing the architecture today can sketch the seams clearly. The AP2 mandate flows from the human to the buyer-agent. The buyer-agent presents the mandate to the seller-agent inside an ACP propose. The seller-agent verifies the mandate, accepts the proposal, and returns a checkout intent. The buyer-agent calls the settlement layer with the checkout intent. The settlement layer returns a receipt. The receipt closes the ACP transaction loop. Four layers, two protocols, one clean state machine.

x402: settlement (HTTP-native value movement)

x402 is the settlement layer in the stack and the one with actual production traffic. The spec originated at Coinbase, governance moved to the Linux Foundation x402 Foundation in April 2026 (announced at MCP Dev Summit North America on April 2), and the design fits in one sentence: when an HTTP resource costs money, the server responds with HTTP 402 Payment Required and a payment-attached header; the client retries with proof of payment; the server verifies and returns the resource. The status code that has sat unused in the HTTP specification since the 1990s is now the carrier for machine-to-machine commerce.

The mechanic matters because it is HTTP-native. An agent that already knows how to make web requests does not need a new transport or a new client library; it needs to recognize a 402, attach a payment header on retry, and parse the receipt. Stablecoin settlement (USDC is the default) plays well with the model because per-call settlement at small amounts is operationally cheap; non-stablecoin variants exist, but the production traffic in May 2026 is stablecoin-dominated.

The adoption surface is where the May 2026 picture got interesting. Coinbase launched Agentic.Market on April 20, 2026 as the canonical x402 marketplace and developer platform. AWS announced Amazon Bedrock AgentCore Payments on May 7, 2026, bundling x402 alongside Coinbase and Stripe as preview-stage payment options for agents discovering, evaluating, and paying for resources inside one execution loop. Circle’s Agent Stack, announced on May 11, 2026, ships Agent Wallets, an Agent Marketplace, Circle CLI, and Nanopayments powered by Circle Gateway, with x402 as the settlement substrate. In three weeks the spec went from “Coinbase ships a marketplace” to “the major payment-infrastructure vendors all have an x402-shaped offering in the field.” That is unusual velocity, and it is the reason x402 is the layer with real merchants on the other side today.

The numbers around x402 require a careful citation pattern. Coinbase Agentic.Market headline figures (around 69K agents and roughly $50M cumulative volume from the April 20, 2026 launch period) cumulate every on-chain pinger, every dashboard ping, every test transaction, and every onboarding flow. The a16z and Allium filtered analysis of x402 organic activity over the same window estimates real 30-day commerce closer to $1.6M after wash-trade and self-traffic filtering. Both descriptions are accurate of what they measure; the canonical pattern is to cite them side by side, never one alone. The headline says how big the on-chain pool is; the filter says how much of it is organic agent commerce. A builder evaluating the layer needs both numbers, not either.

The seam to remember on x402: it is a settlement primitive. It moves value, it writes a receipt, it returns the resource. It does not authorize (AP2 does), it does not negotiate (ACP does), it does not meter continuous flows (MPP does). x402 is the layer with the most ecosystem gravity in May 2026, which makes it the easiest to ship against first. It is also the layer most likely to be over-relied on if a builder forgets that settlement alone is not a payments stack.

MPP: streaming (continuous metered flows)

MPP, the Machine Payments Protocol, is the layer for workloads that do not fit the cart model. A purchase is discrete: one cart, one settlement, one receipt. A stream is continuous: an LLM intermediary agent piping tokens from a backend model to a downstream consumer; an API granting per-second access until cancellation; a tool call that bills by milliseconds of compute. Neither side of a stream wants to negotiate a fresh ACP cart per second.

MPP answers this with a metered loop. The buyer-agent and seller-agent agree on a rate (per token, per second, per call) and a billing breakpoint (every N units, every M seconds, every $K accumulated). The meter runs; at each breakpoint, settlement fires. If the AP2 mandate has been exhausted or the buyer-agent revokes, the meter halts and the stream stops within one breakpoint. If the seller-agent disconnects or fails, the meter records the last verified state and settles to that point.

The format is engineering-grade specifics. A meter requires verified state at each breakpoint, idempotent settlement (so a network glitch at the breakpoint does not double-charge), revocation that propagates fast enough to bound the over-charge window, and an audit log that reconstructs the streamed total from the breakpoints. None of these are surprising on their own; what is new is the agent-to-agent shape, where both sides are programmatic and neither side can call a human to resolve an edge case in flight.

Adoption status in May 2026: MPP is nascent. The concept and an early specification exist; production deployments are limited to specific high-volume use cases like LLM intermediary agents and streaming inference resale. Most builders shipping agent payments today do not need MPP yet; pay-per-call x402 is sufficient until you have a genuine continuous flow where per-call settlement overhead dominates the unit economics.

The seam to remember on MPP: it consumes AP2 (the mandate that bounds the cumulative spend) and emits periodic settlement events (often delegated to x402 for the actual movement). Treat MPP as the meter that turns a continuous flow into a finite, settleable sequence; treat the layer below it as the thing that actually moves the money at each breakpoint.

Where Tobira fits

Tobira does not own a payment layer. The Tobira one-pager is explicit on this: the standard stack framing has Tobira as @handle plus human-readable mutual-reveal UX for human-to-agent professional networking, sitting alongside MCP (tools), A2A v1.2 (task delegation plus Agent Card machine discovery), ERC-8004 plus ENSIP-25 (on-chain identity and reputation), World AgentKit (proof-of-human credential), the capability declaration multi-spec landscape (A2A Agent Card, OSSA, Microsoft APM, Agent Skills), and the layered agent payments stack (AP2 plus ACP plus x402 plus MPP) walked above. The layers are complementary, not competitive.

The place Tobira surfaces is one step earlier than payment. When two agents transact via x402 with an AP2 mandate over an ACP cart, the harder question is: who are those two agents, why do they trust each other, and which of their humans agreed to the engagement that the transaction settles. The payments stack moves value once an engagement exists. Discovery and consent are how engagements come into existence in the first place.

The @handle is the human-readable layer above the payments rails, not inside them. A founder reads @chris and knows who that is; a verifier reads did:web:tobira.ai:agents:chris and gets the cryptographic primitive; an A2A discovery handshake reads the Agent Card; an x402 client reads the settlement endpoint. Each layer has its job; the @handle layer is the surface that lets a human glance at a verdict in their inbox the next morning and recognize the counterparty without translating from a wallet address.

For builders sketching an agent that pays for things, this is the practical takeaway. Compose the payments stack: AP2 plus ACP plus x402 plus (MPP if you actually stream). Carry an A2A Agent Card so other agents can discover what your agent does. Carry a Tobira @handle so the human on the other side of the engagement reads a name. The piece on why an agent needs a name, not a wallet address walks the identity layer in full; the deployment-side discussion of how identity binds across the stack lives in the Pillar 3 piece on portable agent identity.

Takeaways

• AP2, ACP, x402, and MPP do not compete. They sit at four different layers of one stack. AP2 authorizes (Google), ACP carries the cart (OpenAI and Stripe), x402 settles over HTTP (Coinbase, now governed by the Linux Foundation x402 Foundation), MPP meters continuous flows.
• Skip AP2 and you have settlement without spend caps at the auth layer. Skip ACP and you have settlement without cart-level metadata for reconciliation, refunds, and audit. Skip x402 (or another settlement primitive) and you have intent without value movement. Skip MPP and you cannot bill continuous flows where per-call cart negotiation breaks.
• x402 is the layer with real production traffic in May 2026. Coinbase Agentic.Market (April 20, 2026), AWS Bedrock AgentCore Payments (May 7, 2026), and Circle Agent Stack (May 11, 2026) shipped x402-shaped offerings inside three weeks. AP2 and ACP are in spec-and-pilot phase; MPP is nascent.
• Cite Coinbase Agentic.Market numbers in pairs. Headline figures (around 69K agents, roughly $50M cumulative volume) cumulate dashboard pings and test traffic; the a16z plus Allium filter estimates organic 30-day commerce closer to $1.6M. Both are accurate descriptions of what they measure, and the canonical pattern is side-by-side citation.
• Tobira sits above the payments stack as the @handle plus human-readable mutual-reveal UX layer. The payments stack moves value once an engagement exists; Tobira is how the engagement comes to exist in the first place.
• For builders sketching an agent that pays for things: compose AP2 plus ACP plus x402 plus (MPP if you stream), carry an A2A Agent Card for machine discovery, carry a @handle for the human surface. Day-one integration of all four is not required, and clean seams between layers are what let each spec slot in as it becomes production-deployable.

FAQ

What is the difference between AP2, ACP, x402, and MPP?

AP2 authorizes spending (a signed mandate from a human to an agent bounding the spend), ACP carries the cart (the structured negotiation between buyer-agent and seller-agent), x402 settles value (HTTP 402 Payment Required carrying the actual transaction), and MPP meters continuous flows (per-token or per-second billing with periodic settlement breakpoints). The four are layers of one stack, not competing specs.

Is x402 a competitor to ACP?

No. x402 is a settlement primitive; ACP is a checkout primitive. ACP produces a structured checkout intent that x402 settles, with cart-level metadata travelling through the transaction so refunds, disputes, and reconciliation can be done downstream. Reading them as competitors is the same category mistake as asking whether Stripe competes with shopping-cart libraries.

Which agent payments layer is production-ready in May 2026?

x402 is the layer with real production traffic in May 2026. Coinbase Agentic.Market launched on April 20, 2026 as the canonical marketplace; AWS Bedrock AgentCore Payments (May 7, 2026) and Circle Agent Stack (May 11, 2026) shipped x402-shaped offerings within three weeks. AP2 and ACP are in spec-and-pilot phase; MPP is nascent, with production deployments limited to specific high-volume cases like streaming inference resale.

Do I need to integrate all four specs to ship an agent that pays for things?

Not all at once, and probably not all four ever. Most builders need x402 for settlement first; AP2 and ACP follow as the partner ecosystem catches up; MPP is needed only if you have genuine continuous metered flows where pay-per-call x402 overhead dominates. The point of the four-layer model is to design seams that let you slot each spec in as it becomes production-deployable, not to require day-one integration.

Where does Tobira sit relative to the agent payments stack?

Tobira sits above the payments stack as the @handle plus human-readable mutual-reveal UX layer. The payments stack moves value once an engagement between two agents exists; Tobira is how two agents (and their humans) discover each other and consent to the engagement that the transaction eventually settles. The layers are complementary; Tobira does not own a payment primitive and does not compete with AP2, ACP, x402, or MPP.

Sources

• Tobira one-pager v7.2 (18 May 2026), § Standard stack framing, § Agent payments (layered)
• Tobira canonical-entities v3.2 (4 May 2026), § x402 numbers, § Coinbase paired-citation rule
• A2A protocol specification, current stable v1.2 (Linux Foundation, late April 2026): https://a2a-protocol.org
• x402 specification and Linux Foundation x402 Foundation governance (announced April 2, 2026 at MCP Dev Summit NA): https://www.x402.org and https://www.linuxfoundation.org/press/linux-foundation-is-launching-the-x402-foundation-and-welcoming-the-contribution-of-the-x402-protocol
• Coinbase Agentic.Market announcement (April 20, 2026): https://www.coinbase.com/developer-platform
• a16z + Allium x402 organic-activity analysis (April 2026 filtered data)
• AP2 announcement (Google Cloud blog, 2026)
• Agentic Commerce Protocol (ACP) specification, maintained by OpenAI and Stripe: https://github.com/agentic-commerce-protocol/agentic-commerce-protocol
• AWS Bedrock AgentCore Payments (May 7, 2026): https://aws.amazon.com/blogs/machine-learning/agents-that-transact-introducing-amazon-bedrock-agentcore-payments-built-with-coinbase-and-stripe/
• Circle Agent Stack press release (May 11, 2026): https://www.circle.com/pressroom/circle-launches-ai-infrastructure-to-power-the-agentic-economy