Agent Payments Protocol (AP2)

The Agent Payments Protocol (AP2) repository is organized into three main components:

• sdk/: The core AP2 SDK. The current primary implementation is in Python, installed via import ap2.
• samples/: Reference implementations of end-to-end scenarios (Merchant, Credentials Provider, Shopping Agent, Payment Processor) across Python, Go, and Android.
• web-client/: A demo UI built with Vite, React, and TypeScript used to exercise the A2A protocol against sample agents.

Agent Payments Protocol (AP2) is an open protocol designed for the Agent Economy to enable secure, reliable, and interoperable agent commerce. It serves as an extension for the Agent2Agent (A2A) protocol and the Universal Commerce Protocol (UCP).

AP2 addresses critical challenges in autonomous agent commerce, including:

• Authorization: Verifying user authority for specific purchases.
• Authenticity: Ensuring agent requests accurately reflect user intent.
• Accountability: Providing a cryptographic audit trail for dispute resolution.

Developers can build agents using any framework (e.g., ADK), equip them with tools (e.g., MCP), and use AP2 to secure payments.

The Python sample repository is organized as follows:

• scenarios/: Runnable end-to-end flows. Each contains a run.sh or run_*.sh script to start all required agents/servers.
• src/roles/: Individual implementations of AP2 roles (e.g., merchant, credentials provider).
• src/common/: Shared utilities including A2A clients, message builders, and server bootstrapping.

The code/samples/go/ directory provides Go-based implementations of AP2 agents. These samples demonstrate how to leverage Go's type safety, performance, and concurrency for building backend agents.

Currently, the available scenario is:

• Human-Present Card Payment (A2A): A complete card payment flow involving Go agents and a Python Shopping Agent. Detailed instructions for this specific scenario can be found in its dedicated README.

The AP2 protocol is built on four core principles to ensure a secure and equitable agent economy:

• Openness and Interoperability: A non-proprietary extension for A2A, MCP, and UCP to foster a competitive environment.
• User Control and Privacy by Design: Ensures granular user control and protects sensitive data (like conversational prompts and PCI data) through Selective Disclosure.
• Verifiable Intent, Not Inferred Action: Transactions are anchored to deterministic, non-repudiable proof of intent rather than probabilistic LLM outputs to prevent errors from agent 'hallucinations'.
• Clear Transaction Accountability: Provides supporting evidence to help payment networks establish clear liability principles.

The Agentic Authorization model in AP2 is designed to constrain the non-deterministic behavior of Agents by providing clear proof of user intent to Verifiers. The process consists of two distinct phases:

1. Mandate Delegation: The User approves specific Mandate Content on a Trusted Surface and delegates the resulting Mandate to the Agent.
2. Action Authorization: When an Agent attempts an action, a Verifier challenges the Agent for proof of authorization. The Agent presents a relevant Mandate, and upon successful verification, the Verifier issues a Receipt to the Agent.

The repository is organized as follows:

• docs/: Specification, flows, FAQ, and MkDocs sources.
• code/sdk/: The AP2 SDK (Python SDK is located at code/sdk/python/ap2/).
• code/samples/: Reference implementations and scenarios.
  • code/samples/python/scenarios/: Python scenarios.
  • code/samples/go/scenarios/: Go scenarios.
  • code/samples/android/scenarios/: Android scenarios.
• code/web-client/: The demo web client (Vite + React).

In the AP2 protocol, Mandates exist in two distinct states to facilitate both human-present and autonomous agent actions:

• Open Mandate: A mandate that has not yet been bound to a specific transaction. It contains constraints on what the closed mandate can contain and is bound to a specific Agent. Open mandates MUST support cryptographic Key Binding (using the cnf claim) to allow agents to perform autonomous actions.
• Closed Mandate: A mandate bound to a specific transaction with a Verifier. This is achieved by the Agent generating a Key Binding JWT (Proof-of-Possession) using the key endorsed in the open Mandate's cnf claim.

Mandates form a cryptographically verifiable chain from the user-approved Open Mandate to the transaction-specific Closed Mandate.

A Payment Mandate is used to authorize payment for a specific checkout. The lifecycle involves the Shopping Agent creating the content, the Trusted Surface rendering it to the User, and the Credential Provider, Network, and Merchant Payment Processor verifying it.

There are two types of Payment Mandates defined by the vct claim:

• Closed Payment Mandate: Use mandate.payment.1.
• Open Payment Mandate: Use mandate.payment.open.1. Open mandates may optionally include any property found in a closed mandate.