221 The Agent Payments Protocol (AP2): Trust and Accountability in Agentic Commerce

221.1 1. Introduction and Motivation

The previous two chapters built the foundation of the agent stack: MCP connects an agent to tools and data, and A2A connects agents to one another. A third problem appears the moment an agent is asked to do something with economic consequence, buy the concert tickets, reorder the supplies, book the flight. The entire edifice of digital payments was built on an assumption that autonomous agents violate: that a human is directly clicking “buy” on a trusted surface. Card networks, fraud models, and merchant liability rules all presume a person, present at the moment of purchase, looking at the exact cart.

When an agent transacts on a user’s behalf, that assumption collapses, and a trust gap opens that Google’s launch material frames as three questions:

Authorization, How does a merchant know the user actually gave this agent authority to make this particular purchase?
Authenticity, How does the merchant know the agent’s request faithfully reflects the user’s true intent, rather than a hallucination or a manipulated instruction?
Accountability, When a fraudulent or incorrect transaction occurs, who is responsible, the user, the merchant, the issuer, or the agent?

The Agent Payments Protocol (AP2) is an open protocol, announced by Google on September 16, 2025, that answers these questions with cryptographic, non-repudiable proof. It launched with more than sixty partners drawn heavily from the payments industry, Mastercard, American Express, PayPal, Adyen, Worldpay, Checkout.com, Coinbase, Intuit, and others, and is designed as an extension layer that rides on top of A2A (and is usable alongside MCP). This chapter develops AP2’s trust model, its central abstraction of the Mandate, its actors and flows, and its payment-method-agnostic design.

221.2 2. Position in the Agent Stack

AP2 occupies the commerce layer of the stack, above agent-to-agent coordination:

flowchart TD
    AP2["AP2: payments / commerce (Mandates, signed VCs)"]
    A2A["A2A: agent to agent (Agent Cards, Tasks)"]
    MCP["MCP: agent to tools/data (tools, resources)"]
    AP2 --> A2A --> MCP

Concretely, AP2 is implemented as an A2A extension. An agent advertises AP2 support through the A2A extension mechanism (an X-A2A-Extensions header), and AP2’s mandates and credentials are carried as structured data payloads inside ordinary A2A messages. AP2 inherits A2A’s transport, discovery, and security machinery and adds the one thing commerce requires that agent coordination does not: a verifiable, tamper-evident chain of authorization tying a payment back to a real human’s instruction. The reference implementations use Google’s Agent Development Kit and Gemini, but the protocol mandates neither, it is model- and framework-agnostic by design.

221.3 3. The Central Abstraction: Mandates

The trust primitive in AP2 is the Mandate: a tamper-proof, cryptographically signed digital contract that serves as verifiable proof of a user’s instructions. Mandates are expressed as Verifiable Credentials (the W3C standard; the specification also uses the term Verifiable Digital Credentials), tamper-evident, cryptographically signed digital objects, ideally signed with a hardware-backed device key so that each mandate is both non-repudiable and attributable to a specific party.

AP2 defines three mandate types, which chain together to form a complete audit trail.

221.3.1 3.1 The Intent Mandate

The Intent Mandate captures the user’s initial request and the constraints around it, the “rules of engagement.” It encodes the natural-language instruction together with bounds such as a maximum price, acceptable merchants or SKUs, timing conditions, and an expiry. The Intent Mandate is the vehicle for delegated, human-not-present authority: by signing it up front, the user authorizes the agent to act later, autonomously, but only within the pre-declared bounds. “Buy two tickets the moment they go on sale, up to $150 each” is an Intent Mandate.

221.3.2 3.2 The Cart Mandate

The Cart Mandate is the user’s explicit approval of an exact cart, precise items and a precise total, in a human-present flow. It is “a secure, unchangeable record of the exact items and price,” delivering the guarantee that what you see is what you pay for. A defining feature is that the Cart Mandate is signed by both parties: the merchant signs the cart to guarantee it will honor those items at that price, and the user signs to approve the purchase. This dual signature is what closes the authenticity gap, neither side can later claim a different cart.

221.3.3 3.3 The Payment Mandate

The Payment Mandate is a minimal credential derived from the Cart (or Intent) Mandate and appended to the payment authorization itself. Its purpose is narrow but critical: it signals to the payment network and the issuing bank that an agent was involved, and whether a human was present at the moment of purchase. It carries a tokenized payment reference and a cryptographic link back to the cart, giving the rail and the issuer the signals they need for risk decisioning on agent-initiated transactions, a category their existing fraud models were never built to see.

221.3.4 3.4 The Audit Chain

Chained together, the three mandates form a non-repudiable record of the full transaction:

flowchart LR
    Intent["Intent Mandate<br/>what was delegated<br/>user-signed,<br/>constraints + expiry"]
    Cart["Cart Mandate<br/>what was approved<br/>merchant-signed + user-signed,<br/>exact items + price"]
    Payment["Payment Mandate<br/>what the network executed<br/>derived, carries<br/>agent-presence signal to issuer/rail"]
    Intent -->|"cryptographically bound"| Cart -->|"cryptographically bound"| Payment

Given a disputed transaction, any party can verify exactly what the user authorized (Intent), what they approved (Cart), and what was charged (Payment), with each step cryptographically bound to the last. Accountability is thereby tied to real-world entities, user, merchant, issuer, and explicitly not to the agent, which is the only way agentic commerce can integrate with existing liability frameworks.

221.4 4. Actors

An AP2 transaction involves roughly five roles:

User / Payer, originates intent and signs mandates, ideally with a hardware-backed key.
Shopping Agent (User Agent), represents the user: gathers preferences, queries merchants, assembles and presents carts, orchestrates the flow.
Merchant Agent, represents the merchant: makes offers and builds and signs carts.
Credentials Provider (Payment Credential Provider), secures the user’s payment methods and shipping data and issues tokenized payment credentials, so that agents never handle raw card numbers.
Merchant Payment Processor / Issuer / Network, authorizes and settles the transaction on the appropriate rail.

The separation of the Credentials Provider from the agents is a deliberate security boundary: sensitive instruments stay with a dedicated custodian and are exposed to the flow only as tokens.

221.5 5. Transaction Flows

221.5.1 5.1 Human-Present Purchase

“Find me new white running shoes.”

The user states the request; the Shopping Agent captures it in an Intent Mandate.
The agent queries Merchant Agents for candidate offers.
The agent presents options; the user selects an exact item.
The merchant signs the cart, and the user signs the Cart Mandate, binding the exact items and total.
The agent obtains a tokenized payment credential from the Credentials Provider.
A Payment Mandate is generated and signed, flagging agent involvement (human present).
The agent initiates payment; the processor and network settle, with the Payment Mandate visible to the issuer for risk assessment.

221.5.2 5.2 Human-Not-Present (Delegated) Purchase

“Buy concert tickets the moment they go on sale, up to $150 each.”

The user pre-signs a detailed Intent Mandate encoding the price ceiling, timing, and conditions, verifiable, pre-authorized proof of delegated authority.
The Shopping Agent monitors for the trigger condition (tickets become available within the constraints).
When the conditions are met, the agent automatically generates a Cart Mandate on the user’s behalf, permitted only because, and only to the extent that, the signed Intent Mandate authorizes it.
A Payment Mandate is generated and the purchase executes autonomously, leaving the same signed audit chain.

The structural difference between the two flows is precisely where the user’s signature enters. In the human-present flow the user signs the Cart Mandate live; in the delegated flow the user’s earlier Intent Mandate signature is what authorizes the agent to produce a Cart Mandate without the user present. The cryptographic chain is identical in both cases, which is what lets merchants and issuers treat delegated purchases with the same accountability guarantees as live ones.

221.6 6. Payment-Method-Agnostic Design

AP2 cleanly separates two questions that legacy systems conflate: “did the user authorize this?” (answered by the mandate chain) and “is the payment valid?” (answered by whatever rail moves the money). Because the authorization layer is independent of the settlement layer, AP2 supports a wide range of payment methods. The announcement spans “credit and debit cards to stablecoins and real-time bank transfers”; the initial specification targets common card (“pull”) methods, with a roadmap adding e-wallets, “push” payments such as real-time bank transfers, and digital currencies.

For cryptocurrency, Google released the A2A x402 extension alongside AP2, developed with Coinbase, the Ethereum Foundation, and MetaMask. x402 is Coinbase’s open standard that repurposes the long-dormant HTTP 402 (“Payment Required”) status code to let agents make instant on-chain stablecoin (e.g., USDC) payments. Within AP2, an x402 settlement is authorized by an AP2 mandate, so a stablecoin payment carries exactly the same audit trail as a card payment. Google has indicated that extensions like x402 will shape how cryptocurrency support is folded into the core protocol over time.

221.7 7. Standardization, Status, and Open Questions

At launch (September 2025) AP2 was an early-stage, v0.x specification accompanied by reference implementations (Python, Go, and Android), Pydantic data models, and canonical JSON schemas, rather than a frozen standard. Google committed to ongoing updates and additional reference implementations, and standardization work is being pursued in collaboration with FIDO Alliance working groups on agentic authentication and payments.

Several aspects remain unsettled and should be read as a snapshot of a fast-moving protocol. AP2’s governance home is the least consolidated of the three core protocols: it is an open Google-led repository that intersects both the FIDO Alliance and the A2A/Linux Foundation orbit, without a single declared steward as of early 2026. The mandate terminology is still evolving, the live specification shows naming and state refinements (for instance, a “Checkout Mandate” framing and explicit open/closed states) beyond the announcement-era Intent/Cart/Payment triad, which nonetheless remains the dominant and well-corroborated model. Adoption figures (sixty-plus partners at launch, reportedly surpassing one hundred by late October 2025 around the PayPal, Google Cloud conversational-commerce announcement) come largely from vendor communications and should be cited as such. The deeper open questions are economic and legal as much as technical: how dispute resolution and chargebacks adapt to delegated authority, how spending limits are enforced across agents, and how regulators will treat autonomous purchases.

221.8 8. Conclusion

AP2 completes the agent stack’s commerce layer. Where MCP gives an agent hands (tools) and A2A gives it colleagues (peer agents), AP2 gives it a wallet, governed by verifiable, signed mandates that preserve the chain of human authorization a payment system requires. Its central insight is to separate authorization from settlement: the Intent → Cart → Payment mandate chain answers “who authorized this and what did they approve?” in a tamper-evident way, while remaining agnostic to whether the money ultimately moves over a card rail, a bank transfer, or a stablecoin. That separation is what allows agentic commerce to plug into existing liability and fraud frameworks rather than asking them to be rebuilt. AP2 is young and its governance is still settling, but it defines the structure on which trustworthy autonomous purchasing is being built.

221.9 References

Google Cloud. “Powering the next generation of agentic payments with the Agent Payments Protocol (AP2).” Google Cloud Blog, September 16, 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
AP2 Protocol, official specification and documentation. https://ap2-protocol.org/ and https://ap2-protocol.org/specification/
AP2 on GitHub (reference implementations, schemas). https://github.com/google-agentic-commerce/AP2
PayPal. “The Agent Payments Protocol.” PayPal Developer Blog, September 16, 2025. https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/
Coinbase. “x402: an open standard for internet-native payments.” https://www.coinbase.com/developer-platform/discover/launches/x402
Coinbase × Google. “A2A x402 extension.” https://www.coinbase.com/developer-platform/discover/launches/google_x402
Arthur Chiao. “An Illustrated Guide to AP2.” https://arthurchiao.art/blog/ap2-illustrated-guide/
W3C. “Verifiable Credentials Data Model.” https://www.w3.org/TR/vc-data-model/

# The Agent Payments Protocol (AP2): Trust and Accountability in Agentic Commerce ## 1. Introduction and Motivation The previous two chapters built the foundation of the agent stack: MCP connects an agent to tools and data, and A2A connects agents to one another. A third problem appears the moment an agent is asked to do something with economic consequence, buy the concert tickets, reorder the supplies, book the flight. The entire edifice of digital payments was built on an assumption that autonomous agents violate: that **a human is directly clicking "buy" on a trusted surface**. Card networks, fraud models, and merchant liability rules all presume a person, present at the moment of purchase, looking at the exact cart. When an agent transacts on a user's behalf, that assumption collapses, and a trust gap opens that Google's launch material frames as three questions: 1. **Authorization**, How does a merchant know the user actually gave this agent authority to make *this particular* purchase? 2. **Authenticity**, How does the merchant know the agent's request faithfully reflects the user's true intent, rather than a hallucination or a manipulated instruction? 3. **Accountability**, When a fraudulent or incorrect transaction occurs, who is responsible, the user, the merchant, the issuer, or the agent? The **Agent Payments Protocol (AP2)** is an open protocol, announced by Google on September 16, 2025, that answers these questions with cryptographic, non-repudiable proof. It launched with more than sixty partners drawn heavily from the payments industry, Mastercard, American Express, PayPal, Adyen, Worldpay, Checkout.com, Coinbase, Intuit, and others, and is designed as an **extension layer that rides on top of A2A** (and is usable alongside MCP). This chapter develops AP2's trust model, its central abstraction of the **Mandate**, its actors and flows, and its payment-method-agnostic design. ## 2. Position in the Agent Stack AP2 occupies the commerce layer of the stack, above agent-to-agent coordination: ```{mermaid} flowchart TD AP2["AP2: payments / commerce (Mandates, signed VCs)"] A2A["A2A: agent to agent (Agent Cards, Tasks)"] MCP["MCP: agent to tools/data (tools, resources)"] AP2 --> A2A --> MCP ``` Concretely, AP2 is implemented as an **A2A extension**. An agent advertises AP2 support through the A2A extension mechanism (an `X-A2A-Extensions` header), and AP2's mandates and credentials are carried as structured data payloads inside ordinary A2A messages. AP2 inherits A2A's transport, discovery, and security machinery and adds the one thing commerce requires that agent coordination does not: a verifiable, tamper-evident chain of authorization tying a payment back to a real human's instruction. The reference implementations use Google's Agent Development Kit and Gemini, but the protocol mandates neither, it is model- and framework-agnostic by design. ## 3. The Central Abstraction: Mandates The trust primitive in AP2 is the **Mandate**: a tamper-proof, cryptographically signed digital contract that serves as verifiable proof of a user's instructions. Mandates are expressed as **Verifiable Credentials** (the W3C standard; the specification also uses the term *Verifiable Digital Credentials*), tamper-evident, cryptographically signed digital objects, ideally signed with a hardware-backed device key so that each mandate is both non-repudiable and attributable to a specific party. AP2 defines three mandate types, which chain together to form a complete audit trail. ### 3.1 The Intent Mandate The **Intent Mandate** captures the user's initial request and the constraints around it, the "rules of engagement." It encodes the natural-language instruction together with bounds such as a maximum price, acceptable merchants or SKUs, timing conditions, and an expiry. The Intent Mandate is the vehicle for **delegated, human-not-present authority**: by signing it up front, the user authorizes the agent to act *later*, autonomously, but only within the pre-declared bounds. "Buy two tickets the moment they go on sale, up to \$150 each" is an Intent Mandate. ### 3.2 The Cart Mandate The **Cart Mandate** is the user's explicit approval of an *exact* cart, precise items and a precise total, in a **human-present** flow. It is "a secure, unchangeable record of the exact items and price," delivering the guarantee that **what you see is what you pay for**. A defining feature is that the Cart Mandate is **signed by both parties**: the merchant signs the cart to guarantee it will honor those items at that price, and the user signs to approve the purchase. This dual signature is what closes the authenticity gap, neither side can later claim a different cart. ### 3.3 The Payment Mandate The **Payment Mandate** is a minimal credential *derived from* the Cart (or Intent) Mandate and appended to the payment authorization itself. Its purpose is narrow but critical: it signals **to the payment network and the issuing bank that an agent was involved**, and whether a human was present at the moment of purchase. It carries a tokenized payment reference and a cryptographic link back to the cart, giving the rail and the issuer the signals they need for risk decisioning on agent-initiated transactions, a category their existing fraud models were never built to see. ### 3.4 The Audit Chain Chained together, the three mandates form a non-repudiable record of the full transaction: ```{mermaid} flowchart LR Intent["Intent Mandate what was delegated user-signed, constraints + expiry"] Cart["Cart Mandate what was approved merchant-signed + user-signed, exact items + price"] Payment["Payment Mandate what the network executed derived, carries agent-presence signal to issuer/rail"] Intent -->|"cryptographically bound"| Cart -->|"cryptographically bound"| Payment ``` Given a disputed transaction, any party can verify exactly what the user authorized (Intent), what they approved (Cart), and what was charged (Payment), with each step cryptographically bound to the last. Accountability is thereby tied to real-world entities, user, merchant, issuer, **and explicitly not to the agent**, which is the only way agentic commerce can integrate with existing liability frameworks. ## 4. Actors An AP2 transaction involves roughly five roles: - **User / Payer**, originates intent and signs mandates, ideally with a hardware-backed key. - **Shopping Agent (User Agent)**, represents the user: gathers preferences, queries merchants, assembles and presents carts, orchestrates the flow. - **Merchant Agent**, represents the merchant: makes offers and builds and signs carts. - **Credentials Provider** (Payment Credential Provider), secures the user's payment methods and shipping data and issues *tokenized* payment credentials, so that agents never handle raw card numbers. - **Merchant Payment Processor / Issuer / Network**, authorizes and settles the transaction on the appropriate rail. The separation of the Credentials Provider from the agents is a deliberate security boundary: sensitive instruments stay with a dedicated custodian and are exposed to the flow only as tokens. ## 5. Transaction Flows ### 5.1 Human-Present Purchase "Find me new white running shoes." 1. The user states the request; the Shopping Agent captures it in an **Intent Mandate**. 2. The agent queries Merchant Agents for candidate offers. 3. The agent presents options; the user selects an exact item. 4. The merchant signs the cart, and the **user signs the Cart Mandate**, binding the exact items and total. 5. The agent obtains a tokenized payment credential from the Credentials Provider. 6. A **Payment Mandate** is generated and signed, flagging agent involvement (human present). 7. The agent initiates payment; the processor and network settle, with the Payment Mandate visible to the issuer for risk assessment. ### 5.2 Human-Not-Present (Delegated) Purchase "Buy concert tickets the moment they go on sale, up to \$150 each." 1. The user **pre-signs a detailed Intent Mandate** encoding the price ceiling, timing, and conditions, verifiable, pre-authorized proof of delegated authority. 2. The Shopping Agent monitors for the trigger condition (tickets become available within the constraints). 3. When the conditions are met, the agent **automatically generates a Cart Mandate on the user's behalf**, permitted only because, and only to the extent that, the signed Intent Mandate authorizes it. 4. A Payment Mandate is generated and the purchase executes autonomously, leaving the same signed audit chain. The structural difference between the two flows is precisely *where the user's signature enters*. In the human-present flow the user signs the Cart Mandate live; in the delegated flow the user's earlier Intent Mandate signature is what authorizes the agent to produce a Cart Mandate without the user present. The cryptographic chain is identical in both cases, which is what lets merchants and issuers treat delegated purchases with the same accountability guarantees as live ones. ## 6. Payment-Method-Agnostic Design AP2 cleanly separates two questions that legacy systems conflate: **"did the user authorize this?"** (answered by the mandate chain) and **"is the payment valid?"** (answered by whatever rail moves the money). Because the authorization layer is independent of the settlement layer, AP2 supports a wide range of payment methods. The announcement spans "credit and debit cards to stablecoins and real-time bank transfers"; the initial specification targets common card ("pull") methods, with a roadmap adding e-wallets, "push" payments such as real-time bank transfers, and digital currencies. For cryptocurrency, Google released the **A2A x402 extension** alongside AP2, developed with Coinbase, the Ethereum Foundation, and MetaMask. **x402** is Coinbase's open standard that repurposes the long-dormant **HTTP 402 ("Payment Required")** status code to let agents make instant on-chain stablecoin (e.g., USDC) payments. Within AP2, an x402 settlement is authorized by an AP2 mandate, so a stablecoin payment carries exactly the same audit trail as a card payment. Google has indicated that extensions like x402 will shape how cryptocurrency support is folded into the core protocol over time. ## 7. Standardization, Status, and Open Questions At launch (September 2025) AP2 was an early-stage, v0.x specification accompanied by reference implementations (Python, Go, and Android), Pydantic data models, and canonical JSON schemas, rather than a frozen standard. Google committed to ongoing updates and additional reference implementations, and standardization work is being pursued in collaboration with **FIDO Alliance** working groups on agentic authentication and payments. Several aspects remain unsettled and should be read as a snapshot of a fast-moving protocol. AP2's governance home is the least consolidated of the three core protocols: it is an open Google-led repository that intersects both the FIDO Alliance and the A2A/Linux Foundation orbit, without a single declared steward as of early 2026. The mandate terminology is still evolving, the live specification shows naming and state refinements (for instance, a "Checkout Mandate" framing and explicit open/closed states) beyond the announcement-era Intent/Cart/Payment triad, which nonetheless remains the dominant and well-corroborated model. Adoption figures (sixty-plus partners at launch, reportedly surpassing one hundred by late October 2025 around the PayPal, Google Cloud conversational-commerce announcement) come largely from vendor communications and should be cited as such. The deeper open questions are economic and legal as much as technical: how dispute resolution and chargebacks adapt to delegated authority, how spending limits are enforced across agents, and how regulators will treat autonomous purchases. ## 8. Conclusion AP2 completes the agent stack's commerce layer. Where MCP gives an agent hands (tools) and A2A gives it colleagues (peer agents), AP2 gives it a wallet, governed by verifiable, signed mandates that preserve the chain of human authorization a payment system requires. Its central insight is to separate authorization from settlement: the Intent → Cart → Payment mandate chain answers "who authorized this and what did they approve?" in a tamper-evident way, while remaining agnostic to whether the money ultimately moves over a card rail, a bank transfer, or a stablecoin. That separation is what allows agentic commerce to plug into existing liability and fraud frameworks rather than asking them to be rebuilt. AP2 is young and its governance is still settling, but it defines the structure on which trustworthy autonomous purchasing is being built. ## References 1. Google Cloud. "Powering the next generation of agentic payments with the Agent Payments Protocol (AP2)." Google Cloud Blog, September 16, 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol 2. AP2 Protocol, official specification and documentation. https://ap2-protocol.org/ and https://ap2-protocol.org/specification/ 3. AP2 on GitHub (reference implementations, schemas). https://github.com/google-agentic-commerce/AP2 4. PayPal. "The Agent Payments Protocol." PayPal Developer Blog, September 16, 2025. https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/ 5. Coinbase. "x402: an open standard for internet-native payments." https://www.coinbase.com/developer-platform/discover/launches/x402 6. Coinbase × Google. "A2A x402 extension." https://www.coinbase.com/developer-platform/discover/launches/google_x402 7. Arthur Chiao. "An Illustrated Guide to AP2." https://arthurchiao.art/blog/ap2-illustrated-guide/ 8. W3C. "Verifiable Credentials Data Model." https://www.w3.org/TR/vc-data-model/