AP2 Protocol ​

选择语言 / Choose a language：

• 中文
• English

FAQ ​

Question: What is the AP2 Protocol?

Answer: The AP2 Protocol (Agent Payments Protocol) is an open protocol developed by Google to establish a secure, interoperable framework for AI agent-initiated payment transactions. AP2 can be used as an extension of the Agent2Agent (A2A) protocol and Model Context Protocol (MCP), establishing a payment-agnostic framework for users, merchants, and payment providers to transact with confidence across all types of payment methods.

Question: Why is the AP2 Protocol needed?

Answer: Traditional payment systems assume humans directly click "buy" on trusted surfaces, but the rise of AI agents breaks this fundamental assumption. AP2 addresses three critical questions: 1) Authorization - proving users gave agents specific authority for particular purchases; 2) Authenticity - ensuring merchants can verify agent requests accurately reflect user intent; 3) Accountability - determining responsibility when fraudulent or incorrect transactions occur.

Question: What is the core architecture of the AP2 Protocol?

Answer: AP2 uses a role-based architecture with key roles including: Users (individuals delegating tasks), User Agents/Shopping Agents (AI interfaces users directly interact with), Credential Providers (specialized entities managing payment credentials), Merchant Endpoints (interfaces or agents representing merchants), Merchant Payment Processors (entities building final transaction authorization messages), and Networks and Issuers.

Question: What are Verifiable Credentials in the AP2 Protocol?

Answer: Verifiable Credentials (VCs) are AP2's core innovation - tamper-proof, portable, cryptographically-signed digital objects serving as transaction building blocks. There are three main types: Cart Authorizations (foundational credentials when users are present), User-Signed Intent Authorizations (for when users are absent), and Payment Authorizations (providing visibility to payment networks and issuers about AI agent transactions).

Question: What payment methods does the AP2 Protocol support?

Answer: AP2 is designed as a payment-agnostic protocol supporting a wide range of payment types including traditional credit and debit cards, real-time bank transfers, digital wallets, and emerging digital payment methods like stablecoins and cryptocurrencies. This flexible design ensures future adaptability, with the A2A x402 extension supporting agent-based crypto payments through collaboration with Coinbase, Ethereum Foundation, MetaMask, and other organizations.

Question: How does AP2 handle 'human present' vs 'human absent' transaction scenarios?

Answer: AP2 supports two main transaction modes: 1) Human Present - when users make real-time requests like 'find me new white running shoes,' an Intent Authorization is created, and after the agent presents a cart, user approval signs a Cart Authorization; 2) Human Absent - when users delegate tasks like 'buy concert tickets the moment they go on sale,' users pre-sign detailed Intent Authorizations specifying price limits, timing, and conditions, allowing agents to auto-generate Cart Authorizations when conditions are met.

Question: How does AP2 ensure transaction security and prevent agent 'hallucination'?

Answer: AP2 addresses this risk through the principle of 'Verifiable Intent, Not Inferred Action.' Transactions must be anchored to deterministic, non-repudiable proof of intent from all parties, such as user-signed cart or intent authorizations, rather than relying solely on interpreting language models' probabilistic and ambiguous outputs. This creates a complete evidence chain from intent to cart to payment, forming an irrefutable audit trail.

Question: How do I get started with the AP2 Protocol?

Answer: Developers can access the AP2 Protocol's public GitHub repository to review complete technical specifications, documentation, and reference implementations. You can use Google's ADK (Agent Development Kit) and Agent Builder, or choose any other platform to build agents. Any agent on any framework (like LangGraph, AG2, or CrewAI) or runtime can implement the AP2 Protocol. Example agents built around the core AP2 Python library are currently available.

Question: How does AP2 handle dispute resolution?

Answer: AP2 provides a clear, predictable framework for handling disputed transactions through an authenticated, evidence-based system for assigning responsibility. When disputes occur, network arbitrators (like card networks) can obtain additional information from merchants, including carts, hashes, and cart/intent authorizations along with existing evidence. Arbitrators can determine whether users approved the final cart and whether merchants delivered what users requested based on evidence available within the protocol.

Question: How does AP2 integrate with existing payment ecosystems?

Answer: AP2 is designed to be compatible with existing payment infrastructure by extending the existing Agent-to-Agent (A2A) protocol and Model Context Protocol (MCP). It doesn't require any changes to existing risk/fraud handling systems but provides additional signals and data points to help payment networks, issuers, and merchants better assess and manage risk. All existing user challenge mechanisms (like 3DS2 or OTP) remain available for agent transactions.

Question: Which companies support the AP2 Protocol?

Answer: AP2 is supported by more than 60 organizations including Adyen, American Express, Ant International, Coinbase, Etsy, Forter, Intuit, JCB, Mastercard, Mysten Labs, PayPal, Revolut, Salesforce, ServiceNow, UnionPay International, Worldpay, and more. These partners span payment processors, financial institutions, technology companies, and e-commerce platforms, demonstrating broad industry support for building a secure, interoperable agent payment ecosystem.

Question: What is the future roadmap for the AP2 Protocol?

Answer: AP2 follows a phased development approach: V0.1 focuses on core architecture and most common use cases, supporting 'pull' payment methods, human-present scenarios, and user/merchant-initiated upgrade challenges; V1.x will expand protocol capabilities including full 'push' payment support, human-absent scenarios, and MCP-based implementations; long-term vision includes native support for complex multi-merchant transaction topologies and real-time negotiation between buyer and seller agents. The protocol will continue evolving through an open, collaborative process.