Agent Payments Protocol (AP2)

The Agent Payments Protocol is Google's framework for agent-to-agent commerce, built on Verifiable Digital Credentials (VDCs) for trust establishment. Where VI focuses on human-to-agent delegation and UCP focuses on agent-to-merchant integration, AP2 focuses on the trust problem between agents that have no prior relationship.

Core Concepts

Agent-to-Agent Communication

AP2 is built on Google's A2A (Agent-to-Agent) protocol. Agents communicate through a structured message format, with each agent described by an Agent Card — a machine-readable profile that declares the agent's capabilities, supported protocols, and trust credentials.

Agent Cards serve a similar function to UCP's /.well-known/ucp manifest, but for agents rather than merchants. A shopping agent can discover a merchant's agent, read its Agent Card, verify its credentials, and initiate a commerce interaction — all without prior arrangement or shared infrastructure.

Verifiable Digital Credentials

The trust layer in AP2 is built on VDCs. Rather than relying solely on API keys or OAuth tokens, agents carry verifiable credentials that establish trust claims:

• A merchant agent might carry a credential attesting that it represents a registered business
• A payment agent might carry a credential from a licensed payment processor
• A shopping agent might carry a credential binding it to a verified user

VDCs allow agents to establish trust without a pre-existing relationship. If two agents have never interacted before, they can still verify each other's credentials through their respective credential providers — similar to how two strangers can verify each other's passports through their issuing governments.

Credential Provider Architecture

Credential providers are the trust anchors in AP2. They issue VDCs to agents and provide verification endpoints for other agents to confirm those credentials. The credential provider model is extensible — different providers can issue different types of credentials, and agents can carry credentials from multiple providers.

The Commerce Flow

AP2 structures the purchase interaction through an Intent/Cart Mandate model:

1. Discovery: Shopping agent discovers merchant agent via Agent Card
2. Trust establishment: Agents exchange and verify VDCs
3. Intent creation: Shopping agent creates a purchase intent describing what the user wants
4. Merchant response: Merchant agent responds with available options, pricing, and terms
5. Cart Mandate: User confirms the purchase (via the shopping agent), creating a mandate
6. Payment processing: Payment service provider handles the payment rail
7. Fulfillment: Merchant agent manages delivery and status updates

The Intent/Cart Mandate model separates browsing intent from purchase commitment. The shopping agent can explore options and negotiate without committing, and the mandate represents the user's confirmed decision.

Authentication

AP2 uses OAuth2 for agent identity at the transport layer. Agents authenticate to each other via OAuth2 tokens, providing a baseline identity assertion for API access.

The VDC layer sits above OAuth2, providing richer trust assertions. OAuth2 tells you "this API call is from agent X." VDCs tell you "agent X holds credentials Y and Z, issued by providers A and B." The combination provides both access control (OAuth2) and trust establishment (VDCs).

Identity Model

AP2's identity model is the most layered of the four protocols.

What it covers:

• Agent identity: OAuth2 provides authenticated agent identity for each interaction
• Trust claims: VDCs allow agents to carry verifiable assertions about their roles, affiliations, and authorizations
• Credential provenance: Each VDC traces back to a credential provider, creating an auditable trust chain

What it does not cover:

• Human identity: AP2 does not define how a human's identity binds to the shopping agent. It assumes this binding exists but does not specify how it is established or verified.
• Entity authority: If a merchant agent carries a VDC asserting it represents a business, the VDC confirms the credential provider made that assertion. It does not verify the business's internal authorization structure — who can bind the business, to what limits, under what governance.
• Persistent cross-protocol identity: An agent's AP2 identity (OAuth2 + VDCs) does not compose with VI's SD-JWT chain or UCP's DNS-based identity. An agent operating across all three protocols has three separate identity contexts.

What AP2 Handles Well

AP2's strongest contribution is trust establishment between previously unknown agents. The VDC model is genuinely useful — it allows agents to verify each other's claims through trusted third parties, without requiring a centralized registry or prior bilateral agreement.

The Agent Card discovery mechanism is well-designed for an open ecosystem. Agents can find each other, assess each other's capabilities and trust posture, and decide whether to transact — all through machine-readable, verifiable metadata.

The separation of OAuth2 (transport security) from VDCs (trust claims) is architecturally sound. It allows the trust layer to evolve independently of the authentication layer.

What AP2 Defers

AP2's own specification acknowledges its primary gap.

Disputes: AP2's position is explicit: "Disputes follow existing regulations; innovate only where necessary." This means disputes in AP2-mediated transactions fall back to whatever mechanisms exist outside the protocol — credit card chargebacks, consumer protection laws, direct negotiation between parties. AP2 does not define a dispute initiation mechanism, an evidence submission process, or a resolution framework.

The "follow existing regulations" approach is pragmatic for launch but creates a structural problem as agent autonomy increases. Existing dispute mechanisms assume human parties who can write emails, call customer service, and navigate complaint portals. When both sides of a transaction are agents, "existing regulations" may not map cleanly to the interaction.

Persistent identity: An agent's AP2 identity is scoped to its OAuth2 tokens and VDCs. There is no mechanism for an agent to accumulate a reputation across transactions, to carry a dispute history, or to build a trust record that persists beyond individual credential lifetimes.

Agreement lifecycle: Like the other protocols, AP2 handles the purchase moment. The Cart Mandate represents a confirmed purchase intent, not an ongoing obligation. Multi-year contracts, service level agreements, and subscription arrangements are outside AP2's scope.

Jurisdictional framework: AP2 is jurisdiction-agnostic. VDCs can carry claims about jurisdictional registration ("this merchant is registered in the State of Delaware"), but AP2 itself does not define how jurisdictional conflicts are resolved or which law governs a given transaction.