---
title: "The agent payments 'war' is actually a stack — and there's nothing at the bottom"
date: 2026-05-27
summary: "x402, AP2, ACP, and Visa's TAP are described in the trade press as competing protocols. The primary specs say otherwise — they compose into layers. The interesting gap is the one no layer covers."
slug: agent-payments-stack-identity-gap
author: "Damiën Semler"
hero_glyph: coins
---

Every few weeks a new piece appears framing agent payments as a winner-takes-all
contest: Coinbase's x402 versus Google's AP2 versus Stripe's ACP versus Visa's
TAP, the [implied subtitle](https://blockeden.xyz/blog/2026/03/14/payment-giants-agent-protocol-war-visa-tap-google-ap2-coinbase-x402-paypal-ai-commerce/)
being "who will own AI commerce."

Read the primary specs and the picture inverts. The protocols don't compete;
they stack. An agent paying for a SaaS API call can use [AP2 to prove the user
authorized the spend, A2A to negotiate with the merchant agent, and x402 to
settle](https://atxp.ai/blog/agent-payment-protocols-compared/) the actual
transfer — and the documentation for each protocol *explicitly assumes* the
others are doing their job at adjacent layers. The interesting observation
isn't which one wins. It's that the stack, taken together, has no answer to a
basic question: *which agent is signing the mandate*.

![Scaffolding rising against a structure under construction — the layered, partially-finished shape of an infrastructure stack.](https://images.unsplash.com/photo-1616320999187-3c004dad4f0b?fm=jpg&q=70&w=1600&auto=format&fit=crop)
<small>Photo: <a href="https://unsplash.com/@artbyjackson">Jackson Allan</a> on Unsplash.</small>

## The layers, as the specs describe themselves

The clearest statement comes from [AP2's own
documentation](https://ap2-protocol.org/), which describes the protocol as
"available as an extension for the open-source Agent2Agent (A2A) protocol"
and ships reference samples for both card-based settlement and x402
settlement. AP2 doesn't replace A2A or MCP; it slots in above them and below
the settlement rail.

The settlement rail itself is where x402 sits.
[x402](https://www.x402.org) is a payment transport — it revives the HTTP 402
status code so that a server can demand a stablecoin payment in response to a
request and the client can attach a signed payment to the next attempt. There
is no notion of intent, consent, or audit trail in x402; those are out of
scope. [Coinbase reported](https://atxp.ai/blog/agent-payment-protocols-compared/)
50 million transactions across the protocol by early 2026, almost all of them
machine-to-machine micropayments where the "user authorized this" question is
either trivial or absent.

AP2 was [announced in September 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol)
explicitly to fill the layer above. Its core primitive is the *mandate* — a
verifiable-credential-signed digital contract that captures user intent and,
later, the cart that intent resolved into. AP2 is payment-agnostic; it does
not move money. It records and proves that the user told the agent to spend
it. The protocol's three stated goals are authorization, authenticity, and
accountability, none of which are settlement.

Stripe's ACP and Visa's TAP sit elsewhere on the same plane. ACP is a
merchant-side checkout protocol with Stripe's existing payment relationships
behind it; TAP is Visa's answer to the same authorization problem AP2
addresses, scoped to card networks. They are competitive *with each other* in
the way that Stripe and Visa have always competed, not with the stack as a
whole.

Drawn as a stack, with the layers labelled by the question each one answers:

<svg viewBox="0 0 640 360" xmlns="http://www.w3.org/2000/svg" style="max-width:100%;height:auto;display:block;margin:28px auto" role="img" aria-labelledby="stack-title stack-desc">
  <title id="stack-title">The agent payment stack</title>
  <desc id="stack-desc">A vertical stack of five layers. From top: Transport (x402), Authorization (AP2, TAP), Merchant checkout (ACP, UCP), Agent coordination (A2A, MCP). The bottom layer — Identity — has no protocol and is shown with a dashed outline.</desc>
  <style>
    .lb { fill: none; stroke: var(--c-fg-3, #6b7280); stroke-width: 1.4; }
    .lm { fill: none; stroke: var(--c-pink, #F472B6); stroke-width: 1.6; stroke-dasharray: 7 5; }
    .lt { font-family: 'Geist', system-ui, sans-serif; font-size: 14px; fill: var(--c-fg, #0a0a0a); }
    .lp { font-family: 'Geist Mono', ui-monospace, monospace; font-size: 12px; fill: var(--c-fg-2, #404040); letter-spacing: 0.02em; }
    .mt { fill: var(--c-pink, #F472B6); }
    .ll { font-family: 'Geist Mono', ui-monospace, monospace; font-size: 10px; fill: var(--c-fg-4, #9ca3af); letter-spacing: 0.14em; }
  </style>
  <text x="0" y="20" class="ll">THE AGENT PAYMENT STACK</text>
  <rect x="0" y="40" width="640" height="50" rx="4" class="lb"/>
  <text x="20" y="71" class="lt">Transport / settlement</text>
  <text x="620" y="71" text-anchor="end" class="lp">x402</text>
  <rect x="0" y="100" width="640" height="50" rx="4" class="lb"/>
  <text x="20" y="131" class="lt">Authorization / audit</text>
  <text x="620" y="131" text-anchor="end" class="lp">AP2, TAP</text>
  <rect x="0" y="160" width="640" height="50" rx="4" class="lb"/>
  <text x="20" y="191" class="lt">Merchant checkout</text>
  <text x="620" y="191" text-anchor="end" class="lp">ACP, UCP</text>
  <rect x="0" y="220" width="640" height="50" rx="4" class="lb"/>
  <text x="20" y="251" class="lt">Agent coordination</text>
  <text x="620" y="251" text-anchor="end" class="lp">A2A, MCP</text>
  <rect x="0" y="280" width="640" height="50" rx="4" class="lm"/>
  <text x="20" y="311" class="lt mt">Identity</text>
  <text x="620" y="311" text-anchor="end" class="lp mt">— no protocol</text>
</svg>

The same picture, with the detail per row:

| Layer | Concern | Protocol(s) |
|---|---|---|
| Transport / settlement | Move money | x402, traditional rails |
| Authorization / audit | "Did the user say to do this?" | AP2, TAP |
| Merchant checkout | "Is this a real cart with real prices?" | ACP, UCP |
| Agent coordination | "Which agent is talking to which agent?" | A2A, MCP |
| Identity | "*Which* agent is this, and can we trust it?" | — |

The bottom row is the load-bearing one. None of the four payment protocols
specifies it. A2A 1.0 — [released by the Linux Foundation on April 9,
2026](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year)
with "Signed Agent Cards for cryptographic identity verification" — gets
closer than the others, but a signed card answers "this card was signed by
this key," not "this key belongs to an agent you have any reason to trust."

## Why the gap is structural, not temporary

The omission isn't an oversight that the next spec revision will fix. Each
protocol in the stack delegates identity to the layer below it, and the layer
below it delegates the same question further down, until the stack runs out of
layers.

- x402 [verifies that a wallet signed a payment](https://www.x402.org), not
  that the wallet corresponds to a particular agent.
- AP2 mandates are [signed with verifiable
  credentials](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol),
  but the VC issuer is a question AP2 punts on.
- A2A Signed Agent Cards bind a card to a key. The trust decision about that
  key is left to the consumer.

This is the same pattern that produced the certificate-authority ecosystem on
the web: at some point a layer above PKI had to decide which roots to trust,
and the answer became a system of audited CAs and Certificate Transparency
logs. Agents are arriving at the same architectural moment, and the candidates
for the "root trust" layer are still being prototyped in parallel:

- **ERC-8004**, the [Ethereum Improvement
  Proposal](https://eips.ethereum.org/EIPS/eip-8004) authored by Marco De
  Rossi and others, proposes three on-chain registries — Identity, Reputation,
  Validation — and [went live on Ethereum
  mainnet](https://eco.com/support/en/articles/13221214-what-is-erc-8004-the-ethereum-standard-enabling-trustless-ai-agents)
  on January 29, 2026.
- **AGNTCY's OASF**, governed under the [Linux Foundation
  AGNTCY](https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos)
  project, defines a schema for agent capabilities used as a discovery
  primitive.
- **MCP server registries**, now coordinated under the [Agentic AI
  Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)
  formed in December 2025, are converging on signed publication but have not
  yet adopted a single transparency-log model.

None of these is itself a complete identity layer. ERC-8004 provides a handle
and a place to attach reputation; it does not verify that the agent at that
handle responds, serves a valid card, or behaves the way the registry claims.
OASF provides a schema; it does not provide a probe. MCP registries provide
publication; they do not yet provide continuous conformance evidence.

The payment-stack diagram, drawn honestly, has a missing-basement problem.

## What this means for builders

If you're shipping an agent that pays for things, the practical implication
is that you cannot get end-to-end trust by adopting any single protocol from
the list. The payment stack will validate that *some* key signed *some*
mandate. Whether the agent on the other end of A2A is the agent you think it
is — that question lives in a different layer, and that layer is still being
written.

This is the layer Agenstry works on. Specifically, the question "does the
agent at this address actually exist, serve a valid card, and conform to the
spec it claims to implement" is a live-probe question, not a registry-lookup
question. A registry can record that an agent claimed to be MCP-compliant on
the day it published. A probe is what tells you it still is.

The interesting work over the next six months is whether the three
identity-adjacent efforts — ERC-8004 on-chain handles, OASF capability schema,
MCP/A2A registry consolidation under AAIF — converge into something that
plugs cleanly into the bottom of the payment stack.

## What we're watching

Three concrete things, all observable in the next two quarters:

1. Whether AAIF's hosted MCP registry adopts a transparency-log model — the
   CT-for-agents analogue — or stays as a publication-only directory. The
   difference matters for downstream protocols that want to verify the
   registry's claims rather than trust them.
2. Whether AP2 v0.3 or later names a specific identity provider for the agent
   side of its mandate signature, or continues to leave that question to the
   integrator.
3. Whether ERC-8004's reputation registry attracts enough independent
   validators to produce signal that survives without a probing layer.
   Reputation that derives entirely from self-reported feedback collapses
   into the same problem registries already have.

The payment-protocol coverage will keep framing this as a competition. The
specs themselves are clearer: it's a stack with a hole at the bottom.

## Sources

- [Agent Payments Protocol (AP2) Documentation](https://ap2-protocol.org/) — AP2 Protocol Documentation, accessed May 2026.
- [Announcing Agents to Payments (AP2) Protocol](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) — Google Cloud Blog, September 16, 2025.
- [Every Agent Payment Protocol Compared: x402, ACP, UCP, AP2](https://atxp.ai/blog/agent-payment-protocols-compared/) — ATXP, 2026.
- [A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) — Linux Foundation, April 9, 2026.
- [Linux Foundation Announces the Formation of the Agentic AI Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) — Linux Foundation, December 9, 2025.
- [ERC-8004: Trustless Agents](https://eips.ethereum.org/EIPS/eip-8004) — Marco De Rossi et al., Ethereum Improvement Proposals, August 2025.
- [What is ERC-8004? The Ethereum Standard Enabling Trustless AI Agents](https://eco.com/support/en/articles/13221214-what-is-erc-8004-the-ethereum-standard-enabling-trustless-ai-agents) — Eco.com Support, 2026.
- [Linux Foundation Welcomes the AGNTCY Project](https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos) — Linux Foundation, 2025.
- [The Agent Payment Protocol War: Visa TAP vs Google AP2 vs Coinbase x402 vs PayPal](https://blockeden.xyz/blog/2026/03/14/payment-giants-agent-protocol-war-visa-tap-google-ap2-coinbase-x402-paypal-ai-commerce/) — BlockEden, March 14, 2026.
