Agent Payments Protocol (AP2) primary-source snapshot

Last reviewed: 2026-04-29 UTC

Project status snapshot

What the official materials say

1) Introduction page: AP2 is a commerce layer above agent messaging and payment rails

  • URL: https://agentpaymentsprotocol.info/docs/introduction/
  • Key takeaways:
    • The intro page describes AP2 as the commerce layer for the emerging agent economy rather than as a wallet, marketplace, or payment processor.
    • It explicitly says AP2 builds on A2A for messaging and capability discovery, while x402 supplies the first programmable settlement rail.
    • The page positions Google as providing identity, policy, and compliance scaffolding while Coinbase provides the initial stablecoin settlement path.
    • This is the clearest first-party clue that AP2 should be cataloged as an agentic commerce trust framework, not simply as another crypto payment rail.

2) Mandates and verifiable credentials are the trust model, not a side detail

  • URL: https://agentpaymentsprotocol.info/docs/introduction/
  • Key takeaways:
    • The docs define three core mandate types: Intent Mandate, Cart Mandate, and Payment Mandate.
    • These mandates capture delegated buying authority, final basket details, user approval, and payment-context signaling to processors or settlement rails.
    • The docs repeatedly frame mandates as tamper-evident, signed, and non-repudiable, which makes the authorization model central to AP2’s identity.
    • This matters for categorization because AP2 is trying to solve merchant and processor trust around agent actions, not merely transport funds.

3) Core specification: object model and control-plane semantics are already explicit

  • URL: https://agentpaymentsprotocol.info/specification/core/
  • Key takeaways:
    • The core spec formalizes Agent Identity, Payment Intent, Settlement Proof, and mandate schemas.
    • Agent Identity includes DIDs, verification keys, policy claims, business metadata, and optional delegations.
    • Payment Intent includes amount, participants, capture terms, line items, evidence, and policy-trace outputs.
    • Settlement Proof includes rail identifier, ledger entries, content-addressable hash, detached signatures, and compliance metadata.
    • The REST surface covers intent creation, confirmation, cancellation, escrow release, refunds, evidence upload, event streaming, and identity retrieval.
    • The spec also states mutual TLS plus bearer policy tokens and HTTP message signatures, showing AP2 is designed as an enterprise-grade control-plane protocol rather than a loose conceptual framework.

4) Payments rail guide: x402 is the default implementation, but AP2 is intentionally rail-agnostic

  • URL: https://agentpaymentsprotocol.info/docs/payments-rail/
  • Key takeaways:
    • The rail guide says AP2 ships with a production-ready x402 integration via a dedicated rail adapter.
    • Supported flow types include immediate capture, escrow release, milestone payments, and usage-metered draws, which is a strong clue that the protocol is designed for machine commerce rather than only ordinary checkout.
    • The docs explicitly say AP2 does not expose raw private keys to agents; the control plane issues credentials, evaluates policy, and signs rail requests on the agent’s behalf.
    • The same guide says new rails can be added by implementing authorize/capture/release/refund/status interfaces and publishing compliance attestations.
    • This makes AP2 look like a settlement-orchestration standard above individual rails, with x402 acting as the first concrete crypto-native implementation.

5) Quickstart and repo: AP2 is shipping runnable demos, not only a standards narrative

  • URLs:
  • Key takeaways:
    • The quickstart says the public repo includes shopping-agent, merchant-agent, credentials-provider, and x402-compatible payment-processor scenarios.
    • The repo surface exposes SDK code, canonical schemas, sample applications, and a demo web client, with implementations spanning Python, Go, and Android.
    • The repo explicitly says the samples use Google’s ADK and Gemini for demos but that the protocol itself does not require those tools.
    • This is important because it shows AP2 is being pushed as an open protocol with reference implementations, not a Google-only product surface.

6) Google launch post: payment-agnostic framework with strong enterprise and web3 positioning

  • URL: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
  • Key takeaways:
    • Google describes AP2 as an open protocol for securely initiating and transacting agent-led payments across platforms.
    • The post frames AP2 as compatible with multiple payment methods including cards, stablecoins, cryptocurrencies, and real-time bank transfers.
    • The launch narrative centers on three risks AP2 tries to solve: authorization, authenticity, and accountability.
    • Google also highlights a broad partner set across payments, commerce, fintech, and crypto, which suggests AP2 is aiming for standards-layer relevance rather than a niche demo audience.
    • The post specifically mentions the A2A x402 extension as the route for production-ready crypto payments and as an early bridge between AP2 and the web3 ecosystem.

7) A2A x402 extension: useful evidence that AP2 and x402 should not be collapsed into one project

  • URL: https://github.com/google-agentic-commerce/a2a-x402
  • Key takeaways:
    • The extension repo describes itself as bringing cryptocurrency payments to A2A by reviving HTTP 402-style agent monetization for decentralized services.
    • It defines payment-required, payment-submitted, and payment-completed message flows plus language-specific libraries and examples.
    • This is a helpful primary-source distinction: x402 and the A2A x402 extension are the crypto payment-rail side, while AP2 is the higher-level mandate, identity, and accountability layer spanning many possible rails.

Whitepaper / technical-doc status

  • No canonical standalone AP2 whitepaper or litepaper PDF surfaced in this pass.
  • The official docs/spec site plus the GitHub repo appear to be the real source of truth.
  • The launch blog is important because it is where the payment-agnostic and multi-partner positioning is spelled out most clearly.
  • The A2A x402 extension repo is also a useful companion source because it shows how AP2 expects to interoperate with crypto-native payment rails without being reduced to one of them.

Research notes

  • Best current category for the library: agentic commerce protocol / payment-authorization and trust framework / multi-rail settlement orchestration standard.
  • The most important insight is that AP2 is trying to solve “can this agent legitimately buy this thing under these conditions?” rather than just “how do funds move?”
  • The mandate chain is the central architecture clue: intent, cart, and payment evidence are treated as signed objects that create accountability for both human-present and delegated flows.
  • AP2 should be kept distinct from x402 in the library. x402 is closer to a machine-payment rail/protocol, while AP2 is the broader commerce and trust framework that can sit above x402, cards, or bank-transfer rails.
  • The public repo and sample scenarios make the project more concrete than many standards efforts; it already has enough implementation surface to merit separate cataloging.