03 — Protocol Deep Dive: Google's Agent Payments Protocol (AP2)

Section word-target: ≥5,000. Last reviewed: 2026-04-21.

Scope of this section. This is an English, technically precise walkthrough of the Agent Payments Protocol (AP2) as published by Google and its collaborators. It works directly from the spec document in the google-agentic-commerce/AP2 GitHub repository (commit 61f5de4, the v0.1 specification as of April 2026) and from the public Pydantic types that ship with the reference implementation. Where useful, it quotes the schema verbatim. Where a claim cannot be verified from the repo itself, it is attributed to a specific third-party source. Where the spec is explicit that something is deferred to a later version, this section says so rather than inferring behaviour.

Cross-references: ACP is covered in 04-protocol-deep-dive-acp.md; x402 and stablecoin rails in 05-protocol-deep-dive-x402-and-crypto.md; card-network counterparts (Visa Trusted Agent Protocol, Mastercard Agent Pay) in 06-card-networks.md; security analysis in 09-security-and-trust.md.

1. Origin and positioning

Google announced AP2 publicly on 16 September 2025 with a Cloud AI blog post titled "Announcing Agent Payments Protocol (AP2)"[^ap2-announce]. The CHANGELOG entry in the repository confirms the same date and pins the initial release to 0.1.0 (commit e66fc0b)[^ap2-changelog]. The project is hosted at github.com/google-agentic-commerce/AP2 under the Apache-2.0 licence, with a public documentation site at agentpaymentsprotocol.info and a spec file at docs/specification.md[^ap2-spec].

AP2 was not launched as a Google-only project. The Cloud blog explicitly names more than sixty collaborators; among those called out in the launch body are Adyen, American Express, Ant International, Coinbase, Etsy, Forter, Intuit, JCB, Mastercard, Mysten Labs, PayPal, Revolut, Salesforce, ServiceNow, UnionPay International, and Worldpay[^ap2-announce]. The live docs/partners.md in the repository, as of April 2026, lists 120+ partners, including 1Password, Accenture, Adobe, Affirm, Airwallex, Algorand, Alibaba, Binance, Block, Booking.com, BVNK, Checkout.com, China UnionPay, Circle, Cloudflare, Crossmint, EigenLayer, Ethereum Foundation, Fiserv, Global Payments, Klarna, Lightspark, MetaMask, Mollie, Nuvei, Okta, Paxos, Plaid, Polygon, Ramp, Shopify, Signifyd, Solana, Tether, Walmart, WooCommerce, Worldline, Worldpay, and Kite AI (added in PR #161)[^ap2-partners].

The positioning is deliberate. AP2 defines itself as an open extension, not a payment rail, and explicitly as "a non-proprietary, open extension for existing and future agent-to-agent (A2A) and model-context protocol (MCP)" rails[^ap2-spec-sec21]. Google, which also ships A2A[^a2a] and co-develops with Anthropic on MCP tooling, is thus layering a payments-mandate vocabulary on top of two existing agent-communication substrates rather than attempting to replace them. This contrasts with OpenAI/Stripe's Agentic Commerce Protocol (ACP), announced thirteen days later on 29 September 2025[^acp], which wires an LLM front end directly into a merchant checkout and a single payment rail (Stripe / SharedPaymentToken) — see 04-protocol-deep-dive-acp.md for that contrast. AP2 is also broader in scope than Visa's Trusted Agent Protocol (launched 14 October 2025[^visa-tap]), which focuses on server-to-server agent authenticity via HTTP Message Signatures and Web Bot Auth; AP2 is meant to carry semantic authorisation (what was bought, by whom, under what conditions), not just transport authenticity.

Version-wise, the project's roadmap confirms that as of this writing AP2 is at v0.1-alpha, scoped to pull payment methods (cards) in human-present mode, with Human-Not-Present, push payments, MCP reference servers, and subscriptions slated for v1.x[^ap2-roadmap]. The a2a-extension document carries the tag v0.1-alpha and the extension URI https://github.com/google-agentic-commerce/ap2/tree/v0.1[^ap2-a2a-ext].

2. Design principles

Four principles run through the specification. They are not merely marketing copy; each maps directly to a concrete structural choice in the data model and the flow.

Openness and interoperability. AP2 is designed as a payment-method-agnostic extension, grafted onto A2A for inter-agent messaging and (in a forthcoming release) onto MCP for tool invocation[^ap2-spec-sec21]. The spec is careful to note that "agents communicate about payments (mandates)" while "MCP: agents communicate with data (APIs); A2A: agents communicate with other agents (tasks and messages)"[^ap2-a2a-mcp]. The clean separation is the key affordance: an AP2-speaking agent can sit on top of any A2A fabric and still be verifiable.

User control and privacy by design. The spec insists that PCI-sensitive material never flows through the shopping agent. Privacy is enforced structurally by the role-based architecture (Section 3 below): the Credentials Provider (CP) is the only role that ever holds raw card data or tokenisation keys; the Shopping Agent (SA) receives opaque tokens[^ap2-privsec].

Verifiable intent, not inferred action. This is the cornerstone — and the single design decision that most distinguishes AP2 from naïve "give the LLM your credit card" approaches. Trust cannot rest on probabilistic LLM outputs; every transaction must terminate at one or more cryptographically signed user artefacts. The spec is blunt: "Transactions must be anchored to deterministic, non-repudiable proof of intent from all parties. This principle directly addresses the risk of agent 'hallucination' and misinterpretation."[^ap2-spec-sec23]

Clear transaction accountability. AP2 is designed so that, in a dispute, the adjudicator (card network, e-wallet operator, government agency) can consume the signed Cart Mandate / Intent Mandate / Payment Mandate and land liability on a real-world entity — user, merchant, or issuer — "and only land on an AI Agent if a load-bearing decision made by the AI Agent is determined to be wrong"[^ap2-spec-sec6]. The specification includes an illustrative liability table (Table 6.1) covering first-party misuse, mispicks approved vs. unapproved by the user, merchant non-fulfilment, account takeover, and man-in-the-middle attacks[^ap2-spec-sec6].

A fifth implicit principle — role-based minimum privilege — pervades the whole protocol: the SA never sees raw PANs, the CP never sees the user's natural-language prompt, the merchant never sees the user's payment-method list. Each actor receives only what its role requires.

3. Actors and role topology

The ecosystem model defines six roles[^ap2-spec-sec31]:

Role Abbrev. Primary responsibilities
User U Delegates the task; is the ultimate source of intent and financial authority; signs mandates.
User / Shopping Agent UA / SA Interprets the prompt, discovers products, negotiates with merchants, obtains the user's signed authorisation.
Credentials Provider CP Digital-wallet-like entity: holds payment methods, tokenises, handles step-up.
Merchant Endpoint ME Web, MCP or A2A agent representing a merchant; negotiates the cart and signs it.
Merchant Payment Processor MPP Assembles the transaction-authorisation message for the network/issuer.
Network / Issuer — Runs existing authorisation, risk and fraud rails; consumes Payment Mandate signals.

The same A2A agent can fill multiple roles (e.g., a small merchant may collapse ME and MPP into one), and the AP2 A2A extension schema allows an AgentCard to declare more than one role:

# From docs/a2a-extension.md at commit 61f5de4
AP2Role = "merchant" | "shopper" | "credentials-provider" | "payment-processor"

class AP2ExtensionParameters(BaseModel):
  # The roles this agent performs in the AP2 model. At least one value is required.
  roles: list[AP2Role] = Field(..., min_length=1)

— docs/a2a-extension.md, AP2 repo commit 61f5de4[^ap2-a2a-ext]

The spec is explicit that trust between roles is bootstrapped today via curated allowlists and is expected to migrate, in the long run, to real-time mutual verification layered over existing Web PKI (HTTPS, DNS ownership, mTLS, API-key exchange)[^ap2-spec-sec32]. There is no on-chain registry and no DID registry mandated in v0.1; instead, the SA keeps an allowlist of Credential Providers it trusts, each CP keeps its own allowlist of SAs, and each side may maintain its own allowlist of merchants.

4. The data model: Intent, Cart, and Payment Mandates

Mandates are the protocol's Verifiable Digital Credentials (VDCs). The spec aligns them conceptually with the W3C Verifiable Credentials Data Model 2.0[^w3c-vc2] but does not (in v0.1) force a strict VC-JSON-LD wrapper; the reference implementation uses Pydantic models serialised to JSON, with a JWT for the merchant's signature on the cart contents and a verifiable presentation (e.g., SD-JWT-VC) for the user's signature on the payment mandate[^ap2-mandate-py].

The three mandates play different parts in the chain of evidence. Broadly: the Intent Mandate captures what the user wants, the Cart Mandate captures what the merchant commits to deliver, and the Payment Mandate captures how the payment is to be executed and attests agent involvement to the network.

4.1 Intent Mandate

Authoritative definition (from the reference implementation):

# src/ap2/types/mandate.py, AP2 repo @ 61f5de4
class IntentMandate(BaseModel):
    """Represents the user's purchase intent.
    These are the initial fields utilized in the human-present flow. For
    human-not-present flows, additional fields will be added to this mandate.
    """
    user_cart_confirmation_required: bool = Field(True, ...)
    natural_language_description: str = Field(..., example="High top, old school, red basketball shoes")
    merchants: Optional[list[str]] = Field(None, ...)
    skus: Optional[list[str]] = Field(None, ...)
    requires_refundability: Optional[bool] = Field(False, ...)
    intent_expiry: str = Field(..., description="When the intent mandate expires, in ISO 8601 format.")

— src/ap2/types/mandate.py, lines 32–76[^ap2-mandate-py]

Field-by-field (v0.1):

  • user_cart_confirmation_required (bool, default True) — if False, the agent may complete the purchase autonomously once all conditions are satisfied; the spec requires this to be True when the Intent Mandate is not signed by the user[^ap2-mandate-py]. This is the single bit that flips the flow between Human-Present and Human-Not-Present semantics.
  • natural_language_description (string, required) — the agent's paraphrase of the user's prompt. Its presence is deliberate: it lets the merchant, and later an adjudicator, see what the agent understood (the spec calls this "Prompt Playback"[^ap2-spec-sec412]). It is the textual anchor on which "informed consent" is established.
  • merchants (list[str] | None) — optional allowlist of merchant identifiers the SA may transact with. If None, any merchant is allowed.
  • skus (list[str] | None) — optional list of specific SKUs; if None, any SKU meeting the other constraints is allowed.
  • requires_refundability (bool, default False) — if True, items must be refundable.
  • intent_expiry (ISO-8601 string, required) — TTL. The spec (Section 4.1.2) calls this "Time-to-Live (TTL): An expiration time for the mandate's validity"[^ap2-spec-sec412].

The spec's narrative section (4.1.2) additionally lists Payer/Payee Information (verifiable identities for user, merchant and their CPs), Chargeable Payment Methods (a list or category of authorised methods), a Risk Payload container, and Prompt Playback as conceptually part of an Intent Mandate for human-not-present scenarios[^ap2-spec-sec412]. These are not yet present in the Pydantic type in v0.1 — a discrepancy that the community has formally flagged in repo issue #150 "Security Inconsistencies Between Specification and Implementation in Mandate Design"[^ap2-iss150]. That gap is expected to close as v0.1 stabilises.

4.2 Cart Mandate

The Cart Mandate is the merchant's signed commitment to deliver specific goods at a specific price. It reuses the W3C Payment Request API PaymentRequest structure as its cart body — a pragmatic choice because browsers, wallets, and PSPs already speak it.

# src/ap2/types/mandate.py, @ 61f5de4
class CartContents(BaseModel):
    id: str
    user_cart_confirmation_required: bool
    payment_request: PaymentRequest        # W3C PaymentRequest
    cart_expiry: str                        # ISO-8601
    merchant_name: str

class CartMandate(BaseModel):
    contents: CartContents
    merchant_authorization: Optional[str]   # base64url JWT, see below

— src/ap2/types/mandate.py, lines 79–134[^ap2-mandate-py]

The merchant_authorization field is a base64url-encoded JWT whose claim set is documented in the docstring. Quoting the source verbatim:

merchant_authorization is a base64url-encoded JSON Web Token (JWT) that digitally signs the cart contents, guaranteeing its authenticity and integrity:

  1. Header includes the signing algorithm and key ID.
  2. Payload includes: iss, sub, aud (merchant issuer, audience such as a payment processor); iat, exp (short-lived, e.g. 5–15 minutes); jti (unique, prevents replay); cart_hash (hash over the canonical JSON representation of CartContents).
  3. Signature created with the merchant's private key.[^ap2-mandate-py]

This yields the concrete cryptographic properties of the Cart Mandate:

  • Integrity via cart_hash over canonical-JSON CartContents.
  • Authenticity via the merchant's signature on the JWT.
  • Replay-resistance via jti and a 5-to-15-minute exp.
  • Audience-binding via aud, so a Cart Mandate intended for MPP-A cannot be replayed at MPP-B.

Reading the spec (Section 4.1.1) alongside the code, the narrative additionally lists Payer/Payee Information, Payment Method (tokenised), a Risk Payload, Transaction Details (final cart, destination, amount, currency) and refund conditions[^ap2-spec-sec411] — but these are expressed through the embedded PaymentRequest (which carries displayItems, total, shipping_options, modifiers, and options.requestShipping) rather than as top-level siblings. The sample CartMandate in Section 7.2 of the spec confirms this structure:

{
  "contents": {
    "id": "cart_shoes_123",
    "user_signature_required": false,
    "payment_request": {
      "method_data": [{"supported_methods": "CARD",
                       "data": {"payment_processor_url": "http://example.com/pay"}}],
      "details": {"id": "order_shoes_123",
                  "displayItems": [{"label": "Nike Air Max 90",
                                    "amount": {"currency": "USD", "value": 120.0}}],
                  "total": {"label": "Total",
                            "amount": {"currency": "USD", "value": 120.0}}},
      "options": {"requestShipping": true}
    }
  },
  "merchant_signature": "sig_merchant_shoes_abc1",
  "timestamp": "2025-08-26T19:36:36.377022Z"
}

— docs/specification.md, §7.2, sample CartMandate[^ap2-spec-sec72]

An important subtlety is that in a Human-Present flow the Cart Mandate is first signed by the merchant (step 10 of the illustrative flow, see Section 5 below) and only then countersigned by the user via a device attestation surfaced at step 20–22. The merchant signature is a fulfilment guarantee; the user signature is the authorisation. The two are distinct and not redundant.

4.3 Payment Mandate

The Payment Mandate is the protocol's bridge to the legacy authorisation network. It is always bound to a Cart (or Intent) Mandate by ID/hash, but it contains separate fields and is directed at a different audience — the PSP, network and issuer, not the merchant.

# src/ap2/types/mandate.py, @ 61f5de4
class PaymentMandateContents(BaseModel):
    payment_mandate_id: str
    payment_details_id: str                 # ties to PaymentRequest.details.id
    payment_details_total: PaymentItem
    payment_response: PaymentResponse       # W3C PaymentResponse, contains method + token
    merchant_agent: str
    timestamp: str                          # ISO-8601, default now-UTC

class PaymentMandate(BaseModel):
    payment_mandate_contents: PaymentMandateContents
    user_authorization: Optional[str]       # base64url verifiable presentation

— src/ap2/types/mandate.py, lines 137–200[^ap2-mandate-py]

The user_authorization docstring is the most technically substantive cryptographic statement in the reference implementation:

user_authorization is a base64_url-encoded verifiable presentation of a verifiable credential signing over the cart_mandate and payment_mandate hashes. For example an SD-JWT-VC would contain: an issuer-signed JWT authorizing a cnf claim; a key-binding JWT with the claims aud, nonce, sd_hash (hash of the issuer-signed JWT), and transaction_data (an array containing the secure hashes of CartMandate and PaymentMandateContents).[^ap2-mandate-py]

This is an explicit reference to the IETF SD-JWT-based Verifiable Credentials draft (SD-JWT-VC) and to the key-binding JWT pattern: the user's key (held in a hardware-backed secure enclave on-device, per the spec) binds to a specific nonce/audience, and the transaction_data claim hashes cover both the Cart Mandate and the Payment Mandate contents, preventing either from being swapped out after the fact.

Critically, the spec (Section 4.1.3) states that:

  • "AI Agent presence and transaction modality (Human Present vs Not Present) signals must always be shared" with the network;
  • additional Cart/Intent-Mandate data may be shared contractually with the issuer "for purposes such as fraud prevention";
  • "at time of disputes, merchants may use the full cart and/or intent mandates as evidence during representment with the network/issuer as defined by network rules"[^ap2-spec-sec413].

The Payment Mandate is therefore the piece of the protocol that asks the card networks to extend their authorisation-message schemas to carry AI-agent signals — which is precisely what Mastercard Agent Pay (April 2025) and Visa Trusted Agent Protocol (October 2025) have done on the network side; see 06-card-networks.md.

5. Flows

5.1 Human-Present flow

The canonical Human-Present sequence diagram is given in Section 7.1 of the spec. A faithful rendering (participants and numbering preserved from the spec, condensed for readability):

MERMAIDPLACEHOLDER0END Adapted from docs/specification.md §7.1, AP2 repo @ 61f5de4[^ap2-spec-sec71]. Simplified from the original 32-step sequence.

Five load-bearing steps in this choreography:

  • Step 10 — the merchant entity (not an agent) signs the cart. This is the merchant's fulfilment commitment, and its key is meant to chain up to an organisational, not conversational, root of trust.
  • Step 13 — payment options may come from the CP or from the merchant directly (e.g. when the user has a card on file with the merchant and elects to use it, bypassing the CP).
  • Step 20–22 — the user is redirected to a trusted device surface (secure enclave / TEE / browser-based platform authenticator) and the device — not the LLM — produces the attestation. The spec calls step 21 "the load-bearing step where the user verifies everything and proceeds to make a purchase"[^ap2-spec-sec71]. Everything upstream of it is plan; everything downstream is execution.
  • Step 24 — the Payment Mandate is appended to the conventional transaction-authorisation packet; the PSP/network/issuer can now reason about AI-agent involvement.
  • Step 28 — existing network rails (3DS2, OTP challenges, risk scoring) still run; backwards compatibility is a hard requirement.

5.2 Human-Not-Present flow

In the Human-Not-Present (HNP) modality, the user signs an Intent Mandate, not a Cart Mandate, up front. The spec's canonical example:

"Buy 2 tickets to <this concert> from <this merchant> as soon as they become available for the Vegas show in July. Your budget is $1000 and we'd like to be as close to the main stage as possible."[^ap2-spec-sec52]

The three key departures from Human-Present are[^ap2-spec-sec52]:

  1. Cart prompt not required. The SA reads the intent back to the user ("Prompt Playback"), the user approves via in-session biometric, and the Intent Mandate is signed.
  2. Intent Mandate carries the authorisation, not the Cart Mandate.
  3. The merchant can force the user back in-session if the Intent Mandate is insufficient. Two sub-paths:
    • (i) present a small set of SKUs the user must choose from, producing a Human-Present Cart Mandate and shifting accountability to the user;
    • (ii) ask additional questions and update the Intent Mandate.

MERMAIDPLACEHOLDER1END HNP flow, synthesised from docs/specification.md §5.2[^ap2-spec-sec52]. v0.1 of the spec does not yet include a step-numbered HNP diagram; HNP is scheduled for v1.x per the roadmap[^ap2-roadmap].

The key cryptographic change is that in HNP, the user's user_authorization signature inside the PaymentMandate (or the attestation on the Intent Mandate) was produced before the Cart Mandate existed, and therefore must bind its transaction_data to the Intent Mandate (and the SA's derived cart hash at execution) rather than to a pre-existing Cart Mandate. The transaction_data claim of the SD-JWT-VC key-binding JWT is the designated carrier for this chaining[^ap2-mandate-py].

5.3 Transaction challenges

Any party may force a step-up challenge (Section 5.5 of the spec). In v0.1, a challenge is a redirect surfaced via the SA to the User, which lets existing 3DS2 / OTP surfaces plug in unchanged. The CP is notified of successful challenges so the user is not challenged twice, and in HNP mode a challenge forcibly drags the user back into the session[^ap2-spec-sec55].

6. Cryptography and key management

AP2 is deliberately un-opinionated about the exact signing algorithm but very opinionated about where keys live and what they cover.

Algorithms and signatures. The sample JWTs in the spec use RS256 for the merchant_authorization and the user_authorization examples use ES256K (secp256k1) — both consistent with common W3C VC-DM 2.0 deployments[^w3c-vc2]. The CSA analysis models signatures formally as Sig_U(M) = ECDSA.Sign(K_U, Hash(M)) and warns that AP2 is not yet quantum-safe and "future AP2 versions recommend hybrid schemes"[^csa-ap2]. In other words: v0.1 uses conventional ECDSA/RSA; post-quantum migration is an open problem.

Key domiciles. The spec is explicit that the user's signing key should be a device-bound, hardware-backed key ("typically using a hardware-backed key on their device with in-session authentication")[^ap2-spec-sec411]. This maps naturally to Android StrongBox / iOS Secure Enclave / platform WebAuthn authenticators, and the Android sample in samples/android/ exercises that path via the digital-payment-credentials scenario. The merchant key is an organisational key held by the merchant entity (not the merchant agent) — i.e. it lives in an HSM at the merchant or at its PSP, not in an LLM process.

What each signature covers. Three distinct signatures sit on the wire:

  1. The merchant JWT (merchant_authorization) over cart_hash(canonical_json(CartContents)), with iss/sub/aud/iat/exp/jti for replay and audience binding.
  2. The user verifiable presentation (user_authorization) which, via an SD-JWT-VC key-binding JWT, carries a transaction_data array whose members are hashes of the CartMandate and PaymentMandateContents — so the user's signature simultaneously binds to the merchant's commitment and to the payment mandate.
  3. The device attestation produced at step 21 of the Human-Present flow, which is the in-session proof that the human holding the device approved this exact cart + payment mandate pair. The spec treats the attestation as separate from (and typically in addition to) the VC-level user signature — which is why step 22 returns an attestation blob before step 23 bundles it into the forward payload.

Revocation and rotation. AP2 v0.1 does not prescribe a revocation mechanism. The spec's long-term section explicitly flags "Issuance of Trusted Public Keys" — i.e. how public keys are distributed and trusted — as an open community problem, and suggests issuers, networks, governments, merchants or third-party registries as plausible roots of trust[^ap2-spec-sec9]. In practice, short exp values on every JWT (5–15 minutes for the merchant JWT; the user's SD-JWT-VC carries its own exp), together with the jti replay guard and the allowlist-based trust model, constitute the de facto revocation story: mis-issued keys are removed from allowlists and outstanding mandates simply expire.

VC alignment. The docs/topics/ap2-and-x402.md and privacy-and-security.md documents describe the three mandates as "Verifiable Credentials" and the CSA paper observes that AP2 "leverag[es] W3C VC standards for schema alignment and DID-based verification"[^csa-ap2][^ap2-privsec]. However, as of v0.1, the Pydantic wire types do not fully embed @context / type / proof in VC-JSON-LD form; the Cart/Payment Mandates are plain JSON with a JWT / SD-JWT-VC envelope for signatures. Alignment with VC-DM 2.0 is conceptual in v0.1 and is expected to tighten in later releases.

7. Relationship to A2A and MCP

The three protocols compose:

MCP — agents communicate with data (tools and APIs). A2A — agents communicate with other agents (tasks and messages). AP2 — agents communicate about payments (mandates).

— docs/topics/ap2-a2a-and-mcp.md[^ap2-a2a-mcp]

AP2 as an A2A extension. The docs/a2a-extension.md document defines an A2A extension whose URI is https://github.com/google-agentic-commerce/ap2/tree/v0.1[^ap2-a2a-ext]. An A2A AgentCard that supports AP2 advertises this extension in its capabilities.extensions array and declares which of the four AP2 roles (merchant, shopper, credentials-provider, payment-processor) it performs. The sample Merchant Agent Card in §7.2 of the spec pairs the AP2 A2A extension with a Visa payment-method extension, illustrating composability[^ap2-spec-sec72]:

{
  "name": "MerchantAgent",
  "capabilities": {
    "extensions": [
      { "uri": "https://google-a2a.github.io/A2A/ext/payments/v1", "required": true, ... },
      { "uri": "https://visa.github.io/paymentmethod/types/v1",     "required": true, ... }
    ]
  },
  "skills": [{"id": "search_catalog", "name": "Search Catalog", ...}],
  "url": "http://example.com/a2a/merchant_agent",
  "version": "1.0.0"
}

— docs/specification.md §7.2[^ap2-spec-sec72]

The AP2 A2A extension defines three DataPart data_key values that carry the mandates on the A2A wire (ap2.mandates.CartMandate, ap2.mandates.IntentMandate, ap2.mandates.PaymentMandate), as declared in src/ap2/types/mandate.py[^ap2-mandate-py]:

CART_MANDATE_DATA_KEY    = "ap2.mandates.CartMandate"
INTENT_MANDATE_DATA_KEY  = "ap2.mandates.IntentMandate"
PAYMENT_MANDATE_DATA_KEY = "ap2.mandates.PaymentMandate"

A2A tasks and messages already carry DataPart objects; AP2 simply reserves these three data-keys so that any AP2-aware agent can pick them out of an A2A stream.

AP2 and MCP. The roadmap lists an "AP2 MCP server v0.1" as a pending deliverable; as of 2026-04-21 it is not yet shipped, though community work is tracked in issue #178 ("AgentPay MCP: open-source MCP payment server for AP2 scenarios")[^ap2-iss178]. The intended split is that MCP will expose AP2 operations to a single LLM-plus-tools agent (e.g. a merchant lets a single shopping agent call create_cart, commit_cart, submit_payment_mandate as MCP tools), while A2A keeps handling true multi-agent flows (SA↔MA↔CP↔MPP). The authorisation semantics (mandates) are identical in both cases.

8. The reference implementation

The repository ships three parallel reference surfaces at commit 61f5de4:

  • samples/python/ — the richest. It contains role servers for shopping_agent, merchant_agent, credentials_provider_agent, and merchant_payment_processor_agent, all built with Google's Agent Development Kit (ADK) and Gemini 2.5 Flash[^ap2-readme]. The scenarios/a2a/human-present/cards/ scenario runs the complete 32-step Human-Present flow end-to-end over A2A; scenarios/a2a/human-present/x402/ runs it with the x402 stablecoin rail.
  • samples/go/ — a Go re-implementation of the non-SA roles (merchant, credentials provider, MPP) with its own types package under samples/go/pkg/ap2/types, demonstrating the protocol is not Python-locked.
  • samples/android/ — a shopping assistant app plus a digital-payment-credentials scenario that exercises the on-device signing path. The DpcHelper component performs the device attestation at step 21 of the Human-Present flow using the Android Digital Payment Credentials API.

The Python type module is a useful lens: src/ap2/types/ contains mandate.py, payment_request.py (W3C Payment Request objects — PaymentCurrencyAmount, PaymentItem, PaymentRequest, PaymentResponse), payment_receipt.py, and contact_picker.py. That is the entire wire schema of v0.1[^ap2-src].

The README makes clear that ADK and Gemini are not protocol requirements: "The Agent Payments Protocol doesn't require the use of either. While these were used in the samples, you're free to use any tools you prefer to build your agents."[^ap2-readme] Google is careful here because AP2's whole value proposition is that it be model-agnostic and framework-agnostic.

9. Payment-rail adapters

AP2 in v0.1 is formally pull-payment only and the explicit first-class pull rail is cards[^ap2-roadmap]. Everything else is either roadmap (push payments, RTP, e-wallets) or delivered via a companion repo.

9.1 Cards

Card flows use the PaymentRequest.method_data.supported_methods = "CARD" channel (sample CartMandate in §7.2). The PaymentResponse.details.token field is where the CP injects the network token (e.g. a Visa or Mastercard DPAN, an Amex token, etc.) and the PaymentMandate binds it to the cart. At step 24 of the Human-Present flow, the MPP receives the Payment Mandate and appends it to the conventional ISO 8583 / network authorisation packet; from the issuer's perspective this is a tokenised card transaction with AI-agent context metadata.

9.2 ACH / real-time bank transfers

Explicitly roadmap, not v0.1[^ap2-roadmap]. The architectural expectation is that a push-payment will look structurally identical but with a supported_methods value such as "BANK_TRANSFER" or "RTP", and with the Cart Mandate declaring a destination (merchant IBAN / routing+account), per spec §5.4: "If the payment method is a push payment method, the merchant will define where to push funds to"[^ap2-spec-sec54].

9.3 Stablecoin agent-to-agent via x402

AP2 and Coinbase's x402 (a revival of HTTP 402 Payment Required for agent-to-agent stablecoin micropayments) are positioned as complementary: "AP2 provides the overarching secure, interoperable protocol and trust mechanisms necessary for AI agents to make payments, while x402 represents a type of emerging payment method that AP2 is specifically designed to accommodate"[^ap2-and-x402]. The concrete integration lives in the companion repo google-agentic-commerce/a2a-x402, which composes the A2A extension, AP2 mandates and the x402 settlement protocol (EIP-3009 stablecoin transfers on Base/Ethereum/Polygon/Arbitrum/Solana via a "facilitator" service)[^ap2-and-x402]. The launch blog names Coinbase, Crossmint, EigenLayer, Ethereum Foundation, MetaMask and Mysten Labs as collaborators on this web3 path[^ap2-announce][^ap2-and-x402]. See 05-protocol-deep-dive-x402-and-crypto.md for the full x402 treatment.

9.4 Other rails

The partner list implies a long tail of future adapters: Klarna (BNPL), Affirm (BNPL), Revolut, Ant International's Antom, Alipay/TenPay/UnionPay, Paxos and Circle (stablecoins), BVNK (cross-border stablecoin settlement), Plaid (bank data), Lightspark (Lightning) — but as of April 2026, none of these have landed as a published rail adapter in the AP2 repo. They are AP2 partners, meaning they have signed up to help shape v1.x; the actual v0.1 wire schema only covers "CARD" in its examples.

10. Security considerations

The most comprehensive public security analysis of AP2 to date is Ken Huang and Jerry Huang's October 2025 Cloud Security Alliance blog post, which applies both STRIDE and the newer MAESTRO threat-modelling framework to the protocol[^csa-ap2]. Its findings — and the spec's own security section — can be organised around the concrete attack classes the protocol is designed to resist.

Mandate spoofing and forgery. An adversary who forges a Cart or Payment Mandate, or swaps one mandate for another after signing, would break the liability chain. AP2's structural defence is that (i) the merchant's JWT over cart_hash binds the cart body bit-exactly, (ii) the user's SD-JWT-VC key-binding JWT's transaction_data array hashes both the CartMandate and the PaymentMandateContents, so neither can be swapped without re-signing, and (iii) the aud claim on both JWTs audience-binds the credential to the intended recipient[^ap2-mandate-py]. The CSA paper notes a residual risk of signature stripping where a man-in-the-middle could attempt to replay the user_authorization across mandates, mitigated by the transaction_data hash-binding and short exp values[^csa-ap2]. Repo issue #211 "CartMandate ↔ PaymentMandate Binding and Verification Gap" raises that, in the Human-Present flow as currently implemented, the binding between the Cart Mandate and Payment Mandate is under-specified at the verification side — flagging a real gap between narrative and code[^ap2-iss211].

Replay. Two-layer defence: jti (nonce) plus iat/exp on every JWT; CPs and MPPs are expected to cache seen jtis for the exp window. Short merchant-JWT expiries (5–15 min per the docstring) keep the cache bounded[^ap2-mandate-py].

Key compromise. If the user's device key is exfiltrated, the attacker inherits the ability to sign arbitrary mandates. v0.1 mitigates this structurally by requiring the key to be hardware-backed (StrongBox / Secure Enclave / platform authenticator), which in practice prevents exfiltration without physical possession of the device and an unlocked biometric. Merchant-key compromise is mitigated by the issuer allowlist and by rotating short-lived JWTs; the spec nonetheless lists "Issuance of Trusted Public Keys" as an open community problem[^ap2-spec-sec9]. There is no formal revocation registry in v0.1.

Agent coercion (prompt injection, workflow hijacking). This is the class of attack the spec is most thoughtful about, because the shopping agent is an LLM and therefore inherently vulnerable to prompt-injection via product descriptions, seller metadata, email content, etc. The protocol's architectural answer is the Verifiable Intent principle: the authoritative artefact is the user-signed mandate, not the LLM's reasoning trace. Even if the SA is fully compromised, it cannot create a valid Cart Mandate without the merchant's organisational-key signature, and it cannot create a valid Payment Mandate without the user's hardware-backed device signature[^ap2-spec-sec23]. The CSA paper additionally flags Layer 3 "Workflow Hijacking via Prompt Injection" (compromised instructions redirecting agent delegation), Layer 1 "Emergent Decision Biases" (fine-tuned LLM favouring malicious merchants), and Layer 2 "Memory Poisoning in Embedding Spaces" (corrupting the agent's retrieval memory to skew cart construction), none of which are defeated by the mandate layer alone — they require adversarial training, sandboxed execution, and on-device verification as additional controls[^csa-ap2].

Account takeover. If a fraudster gains control of the user's account or device, they can issue valid-looking mandates. The spec's liability table (6.1) places accountability on the user or issuer depending on authentication-signal analysis at mandate-sign time[^ap2-spec-sec6]. AP2 does not solve ATO directly — it relies on existing authentication and device-attestation layers — but it does improve forensics because every disputed transaction has a chain of signed mandates that an adjudicator can verify post-hoc.

Man-in-the-middle. The signed-VDC design makes in-flight tampering cryptographically detectable (Table 6.1, MITM row: "Verification of digital signatures and payload integrity. The signed VDCs are designed to make this infeasible")[^ap2-spec-sec6].

First-party misuse. A user approves a Cart Mandate and later disputes the transaction claiming fraud. AP2's novel defence: the user-signed Cart Mandate VDC, produced with a hardware-backed device key, is itself the forensic artefact that defeats the dispute[^ap2-spec-sec6]. This inversion — where the user's own signature, not network-side heuristics, establishes first-party consent — is one of the protocol's most commercially significant affordances for merchants.

Privacy leakage. Role separation is the defence: the SA never sees PAN, the CP never sees the user's prompt, the merchant never sees the user's full payment-methods list. The CSA analysis notes AP2's alignment with PCI-DSS through this segregation[^csa-ap2]. Residual risks include metadata leakage in the natural_language_description field of the Intent Mandate (which is visible to the merchant) and cross-merchant Intent Mandate visibility, the subject of repo issue #180 "Restrict IntentMandate Visibility to User ↔ Shopping Agent Boundary"[^ap2-iss180].

Quantum horizon. All signatures in v0.1 are classical ECDSA/RSA; the CSA paper explicitly warns of quantum threats and recommends hybrid schemes for future AP2 versions[^csa-ap2]. No migration plan is on the v0.1 roadmap.

11. Known limitations and open issues (as of 2026-04-21)

Working from the repository itself, the live gap-list is substantive. Highlights from open issues at commit 61f5de4:

  • #150 — Security Inconsistencies Between Specification and Implementation in Mandate Design. The spec narrative lists fields (Payer/Payee Information, Risk Payload, Chargeable Payment Methods) on the Intent Mandate that are absent from the v0.1 Pydantic class[^ap2-iss150].
  • #211 — CartMandate ↔ PaymentMandate Binding and Verification Gap. Argues that Human-Present verification logic does not enforce the hash-binding between the two mandates in the reference code[^ap2-iss211].
  • #215 — Human-present approval chain remains underdefined in AP2. Step 20–22 of §7.1 is not fully specified at the A2A-message level.
  • #214 — Challenge flow underdefined at the AP2/A2A contract layer. §5.5's "redirect challenge" is conceptual rather than wire-specified.
  • #192 — PaymentCurrencyAmount.value type is inconsistent with W3C Payment Request API spec. The reference code uses float where W3C specifies decimal string; can produce rounding on the signed hash.
  • #207 — Cross-merchant budget enforcement for IntentMandates. Today the merchants allowlist is enforceable per-transaction but there is no spec for a multi-merchant budget ceiling.
  • #180 — Restrict IntentMandate visibility to User ↔ Shopping Agent boundary. As above.
  • #163 — Define structured Risk Payload schema for §7.4. The spec explicitly leaves the Risk field open-ended; a schema would improve interoperability.
  • #178 — AgentPay MCP server. MCP server is still not shipped — a roadmap deliverable not yet in repo[^ap2-iss178].
  • #224, #183, #181 — community proposals for on-chain escrow (PactEscrow, Arbitrum One), an agent-reputation layer (SwarmScore), and a VCAP settlement binding for delivery-confirmation-before-release. These hint at a gap AP2 does not address: settlement finality conditional on delivery.

Beyond the issue tracker, four categories of limitation are structural to v0.1:

  1. Pull payments only; push payments are v1.x. Real-time bank transfer (SEPA Instant, FedNow, UPI, Pix) is not yet supported.
  2. Human-Not-Present is narratively described but not fully wire-specified. The Pydantic IntentMandate is explicit that it contains the initial fields utilized in the human-present flow; HNP-specific fields are deferred[^ap2-mandate-py].
  3. No MCP reference server. A2A is exercised end-to-end in samples/python/; MCP is not.
  4. No formal revocation, no mandated root-of-trust registry. Trust bootstrap is allowlist-based in v0.1, and the spec openly defers "Issuance of Trusted Public Keys" to the ecosystem[^ap2-spec-sec9].
  5. No specified handling of refunds, partial refunds and chargebacks at the mandate layer. The spec references "refund conditions" inside the Cart Mandate[^ap2-spec-sec411] and the sample PaymentMandate shows a refund_period on payment_details_total[^ap2-spec-sec72], but there is no separate "RefundMandate" and no specified flow for representment beyond "merchants may use the full cart and/or intent mandates as evidence" at dispute time[^ap2-spec-sec413].

12. Adoption status, April 2026

Four adoption signals are visible at the time of writing:

Partner breadth. The partner list in docs/partners.md stands at roughly 125 organisations as of commit 61f5de4[^ap2-partners], up from the ~60 named at launch[^ap2-announce]. It spans card networks (Mastercard, American Express, JCB, UnionPay, China UnionPay), card issuers and BNPL (Affirm, Klarna, Synchrony, Ramp, ZIP), PSPs (Adyen, Worldpay, Checkout.com, Nuvei, Global Payments, Fiserv, Mollie, Gr4vy, GMO PG, JusPay), e-wallets (PayPal, Revolut, Block, Toss, GrabPay, MoMo, ShopeePay, Alipay/TenPay via Ant), stablecoin infrastructure (Circle, Tether, Paxos, Crossmint, BVNK, MetaMask), blockchains and L2s (Solana, Polygon, Algorand, EigenLayer, Ethereum Foundation, Mysten Labs/Sui, Kaia, MegaEth), identity and risk (Okta, Auth0, 1Password, Ping Identity, Plaid, Trulioo, Vouched, Experian, Sardine, Signifyd, Riskified, Forter), infrastructure (Cloudflare, Red Hat, Confluent, Gravitee, Palo Alto Networks), and merchants/marketplaces (Walmart, Shopify, Etsy, Wayfair, Alibaba, AliExpress, Lazada, Shopee, Mercado Livre, Booking.com, Trip.com, Dafiti, The Iconic, Zalora, Minor Hotels, WooCommerce). The absence of OpenAI, Visa and Stripe from this list is notable and reflects the genuinely competitive split in the industry between AP2 and OpenAI/Stripe's ACP.

Production pilots. Google's October 2025 Gemini at Work keynote showcased AP2 demos with named partners[^ap2-partners]. As of April 2026, no full commercial at-scale deployment has been publicly announced by any AP2 partner. Intuit, Salesforce and ServiceNow have committed to AP2 in B2B/enterprise contexts (Google's "Gemini Enterprise" and AI Agent Marketplace are the explicit go-to-market vehicles, per the launch blog[^ap2-announce]).

Reference-implementation maturity. End-to-end Python samples for Human-Present + cards and Human-Present + x402 work out-of-the-box; the Android digital-payment-credentials scenario exercises device-attestation signing; the Go samples cover the non-SA roles[^ap2-readme]. The Python and Android SDKs remain marked as pending on the roadmap[^ap2-roadmap].

Standardisation trajectory. The Cloud launch blog commits to "evolving this protocol in an open, collaborative process, including through standards bodies"[^ap2-announce]. No specific SDO filing (IETF, W3C, EMVCo) has been publicly confirmed as of April 2026. The A2A-x402 extension has been filed as a separate repository and is positioned as a path for web3 integration rather than a standards submission.

Competitive dynamics. AP2 sits at the "mandate/semantic" layer of the agentic-commerce stack. OpenAI/Stripe ACP (see 04-protocol-deep-dive-acp.md) occupies the "conversational-checkout + SharedPaymentToken" layer; Visa's Trusted Agent Protocol (see 06-card-networks.md) occupies the "agent-transport authenticity" layer via Web Bot Auth and HTTP Message Signatures; x402 occupies the "stablecoin settlement rail" layer. These are not strictly rivals — ACP + AP2 could conceivably coexist (ACP for ChatGPT-initiated flows, AP2 for multi-agent flows), and AP2 already composes with x402 — but they are competing for developer mindshare and merchant integration budget. The key question for 2026 is whether Mastercard and Amex's joint presence on both AP2 and Visa's partner list translates into convergent implementations or parallel-and-redundant ones.

13. Summary

AP2 v0.1 is best understood as a mandate vocabulary laid on top of existing agent communication and payment rails. Its technical contribution is not a new crypto primitive or a new payment rail; it is the careful separation of intent, cart and payment authorisation into three distinct Verifiable Digital Credentials, each signed by a different party, each bound to the others by cryptographic hash, and each delivered to the actor that specifically needs it. By doing so, it converts the hardest problems of agentic commerce — "did the user actually agree to this?", "did the merchant agree to deliver it?", "how does the network know an agent was involved?" — into questions answerable by offline signature verification. The trade-off is that v0.1 leaves large areas (HNP wire format, revocation, push rails, MCP binding, post-quantum migration, refunds) explicitly open for the community. Whether AP2 becomes the interoperability layer or just an interoperability layer will depend less on the elegance of the spec — which is already credible — and more on whether the 100+ partner organisations ship real, interoperable implementations in 2026.

Sources

[^ap2-announce]: Google Cloud Blog, "Announcing Agent Payments Protocol (AP2)", 16 September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol. Verified 2026-04-21.

[^ap2-changelog]: CHANGELOG.md, google-agentic-commerce/AP2, commit 61f5de4 (HEAD of main, April 2026): "0.1.0 (2025-09-16) — Create Agent Payments Protocol (AP2), e66fc0b". https://github.com/google-agentic-commerce/AP2/blob/main/CHANGELOG.md.

[^ap2-spec]: AP2 specification document, docs/specification.md at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/docs/specification.md.

[^ap2-partners]: docs/partners.md at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/docs/partners.md. 125 partner entries as of April 2026; most recent addition Kite AI via PR #161.

[^ap2-spec-sec21]: Ibid., §2.1 "Openness and Interoperability".

[^a2a]: A2A Protocol official site, https://a2a-protocol.org/.

[^acp]: Agentic Commerce Protocol (OpenAI + Stripe), announced 29 September 2025. https://agenticcommerce.dev/.

[^visa-tap]: Visa, "Visa Introduces Trusted Agent Protocol", 14 October 2025. https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx.

[^ap2-roadmap]: docs/roadmap.md at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/docs/roadmap.md.

[^ap2-a2a-ext]: docs/a2a-extension.md at commit 61f5de4. Extension URI https://github.com/google-agentic-commerce/ap2/tree/v0.1, tag v0.1-alpha. https://github.com/google-agentic-commerce/AP2/blob/main/docs/a2a-extension.md.

[^ap2-privsec]: docs/topics/privacy-and-security.md at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/docs/topics/privacy-and-security.md.

[^ap2-spec-sec23]: Specification, §2.3 "Verifiable Intent, Not Inferred Action".

[^ap2-spec-sec6]: Specification, §6 "Enabling Dispute Resolution" and Table 6.1 "New Evidence in Common Scenarios".

[^ap2-spec-sec31]: Specification, §3.1 "The Actors".

[^ap2-spec-sec32]: Specification, §3.2 "The Flow of Trust" (§§3.2.1–3.2.2).

[^w3c-vc2]: W3C Verifiable Credentials Data Model 2.0 (Recommendation). https://www.w3.org/TR/vc-data-model-2.0/.

[^ap2-mandate-py]: src/ap2/types/mandate.py at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/src/ap2/types/mandate.py. Source of the Pydantic class definitions, merchant_authorization JWT docstring, and user_authorization SD-JWT-VC docstring quoted in §4.

[^ap2-spec-sec412]: Specification, §4.1.2 "The Intent Mandate".

[^ap2-iss150]: GitHub issue, google-agentic-commerce/AP2 #150, "[Bug]: Security Inconsistencies Between Specification and Implementation in Mandate Design". https://github.com/google-agentic-commerce/AP2/issues/150.

[^ap2-spec-sec411]: Specification, §4.1.1 "The Cart Mandate".

[^ap2-spec-sec413]: Specification, §4.1.3 "The Payment Mandate for AI Agent Visibility to Payments Ecosystem".

[^ap2-spec-sec71]: Specification, §7.1 "Illustrative Transaction Flow" (32-step Mermaid sequence diagram).

[^ap2-spec-sec72]: Specification, §7.2 "Code Samples" — Merchant Agent Card, Credential Provider Agent Card, sample CartMandate, sample PaymentMandate.

[^ap2-spec-sec52]: Specification, §5.2 "Human Not Present Transaction".

[^ap2-spec-sec54]: Specification, §5.4 "Payment Method Selection".

[^ap2-spec-sec55]: Specification, §5.5 "Transaction Challenges".

[^ap2-spec-sec9]: Specification, §9 "A Call for Ecosystem Collaboration" — "Issuance of Trusted Public Keys".

[^ap2-a2a-mcp]: docs/topics/ap2-a2a-and-mcp.md at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/docs/topics/ap2-a2a-and-mcp.md.

[^ap2-iss178]: GitHub issue, google-agentic-commerce/AP2 #178, "AgentPay MCP: Open-source MCP payment server for AP2 scenarios". https://github.com/google-agentic-commerce/AP2/issues/178.

[^ap2-readme]: README.md at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/README.md.

[^ap2-src]: src/ap2/types/ package at commit 61f5de4: mandate.py, payment_request.py, payment_receipt.py, contact_picker.py. https://github.com/google-agentic-commerce/AP2/tree/main/src/ap2/types.

[^ap2-and-x402]: docs/topics/ap2-and-x402.md at commit 61f5de4. https://github.com/google-agentic-commerce/AP2/blob/main/docs/topics/ap2-and-x402.md.

[^csa-ap2]: Ken Huang and Jerry Huang, "Secure Use of the Agent Payments Protocol (AP2): A Framework for Trustworthy AI-Driven Transactions", Cloud Security Alliance, 6 October 2025. https://cloudsecurityalliance.org/blog/2025/10/06/secure-use-of-the-agent-payments-protocol-ap2-a-framework-for-trustworthy-ai-driven-transactions.

[^ap2-iss211]: GitHub issue, google-agentic-commerce/AP2 #211, "[Security Hardening Suggestion] AP2 Human-Present: CartMandate ↔ PaymentMandate Binding and Verification Gap". https://github.com/google-agentic-commerce/AP2/issues/211.

[^ap2-iss180]: GitHub issue, google-agentic-commerce/AP2 #180, "[Proposal]: Restrict IntentMandate Visibility to User ↔ Shopping Agent Boundary". https://github.com/google-agentic-commerce/AP2/issues/180.