Google's AP2 is a real standard — and it's the third one this year, which is the problem
Google Cloud shipped Agent Payments Protocol (AP2): an open standard that lets LLM-based agents initiate, authorize, and settle online purchases across credit cards, bank transfers, digital wallets, and cryptocurrency, secured with cryptographically signed mandates.
the technical design is solid. cryptographically signed mandates are the right primitive — they give you a verifiable authorization record that can be checked at settlement without requiring the calling agent to expose credentials. the cross-rail coverage (card, bank, wallet, crypto) is genuinely ambitious.
here's the problem: AP2 is the third open agentic payment protocol to launch this year. Coinbase shipped x402 in February. Stripe and Tempo co-authored MPP. and now AP2 from Google.
three protocols in one year doesn't mean the problem is solved. it means three large companies each decided the problem was important enough to define independently — which is a different thing.
what three competing standards actually means for builders
for an MCP server creator or an agentic application developer, three competing protocols means a decision: pick one, implement all three, or wait for consolidation.
picking one is the fast path, but it creates a caller exclusion problem immediately. an MCP server that implements AP2 as its payment rail is already declining callers who come in on x402 or MPP. the caller has to adapt, not the server — which is a user experience problem for the developer and a revenue leakage problem for the server operator.
implementing all three is the comprehensive path, but it's also three payment integrations to maintain, three different auth models to reason about, and three different settlement rails to reconcile. for a small team or a solo developer running an MCP server, that's a meaningful engineering burden.
waiting for consolidation is the reasonable long-run view, but consolidation in payment standards historically takes years. VHS vs. Betamax ran for most of a decade. the x402/AP2/MPP race is unlikely to resolve in months.
the normalization approach
the alternative to picking a side is building a normalization layer — a protocol abstraction that sits between the MCP server and its callers and translates across all three rails without requiring the server to implement any of them directly.
that's what MnemoPay does. the server exposes one payment interface. MnemoPay handles the incoming protocol — AP2, x402, MPP, or Stripe-native — translates to the server's preferred settlement rail, enforces spend gates and per-session budgets, and produces a tamper-evident receipt per call. 672 tests, v1.0.0-beta.1 shipped, 1.4K weekly npm downloads.
the AP2 launch is a validation signal, not a solution signal. when Google ships an open payment standard for AI agents, it confirms that the market is real and the payment infrastructure problem is worth solving at scale. it doesn't mean the fragmentation problem goes away — it means there are now three credible players pushing three incompatible standards, which is exactly the condition where a normalization layer has the most value.
the signed mandate primitive is worth keeping
the part of AP2 that's genuinely good, and that will likely survive whatever consolidation happens: the cryptographically signed mandate as the core authorization primitive.
a signed mandate is a machine-verifiable record that says "agent X was authorized by principal Y to spend up to Z on behalf of scope W." that's the right abstraction because it's verifiable without the calling agent having to re-authenticate on every call, and it creates an audit artifact that survives the session.
that primitive — verifiable authorization at settlement, not just at initiation — is what's missing from most current payment integrations. AP2's version of it will likely influence how the other protocols evolve. the specific implementation will compete. the concept will converge.
for builders right now: the normalization problem is live, the fragmentation is real, and the teams that abstract it correctly now won't need to rebuild when consolidation happens.
Top comments (0)