AP2 (Agent Payments Protocol) Architecture Diagram: The Complete Guide (2026)

The Agent Payments Protocol (AP2) is an open protocol Google announced on September 16, 2025, in collaboration with more than 60 payments and technology partners — including Mastercard, PayPal, American Express, Coinbase, Adyen, Worldpay, JCB, UnionPay International, Salesforce, ServiceNow, and Etsy. AP2 answers a problem that MCP and A2A were never designed to solve: once an AI agent can call tools (MCP) and delegate work to other agents (A2A), how does a merchant or a card network know that a purchase an agent is about to make was actually authorized by the human who owns the money? AP2 closes that gap with a chain of cryptographically signed Mandates that act as a verifiable, tamper-evident permission slip from the user to the agent.

AP2 is explicitly built as an extension to A2A and MCP rather than a replacement for either — it reuses their agent-discovery and tool-calling machinery and adds a payment-specific trust layer on top. As agentic commerce moves from demos to production in 2026, clear architecture diagrams that show exactly where a Mandate is signed, who signs it, and which party verifies it before money moves have become essential for fraud review, PCI scoping conversations, and engineering handoffs between AI teams and payments teams. This guide breaks down the AP2 roles and Mandate types, and gives you prompt templates for diagramming your own AP2-based checkout flow.

How AP2 stacks on top of A2A and MCP

The core components of an AP2 architecture

User (the human principal)

The user is the source of authority in every AP2 flow. Everything else in the protocol exists to prove, cryptographically, that a given purchase traces back to a decision this specific person made — either in real time (approving a cart directly) or in advance (signing an Intent Mandate with conditions an agent can later act on without the user being present). In a diagram, the user should be drawn as the signer of Mandates, not just as a generic actor at the edge of the system.

Shopping Agent

The Shopping Agent is the AI agent acting on the user's behalf — it handles discovery (searching for products or services), curation (narrowing options against the user's stated criteria), and assembling a cart. The Shopping Agent may itself be built as an A2A agent, and it typically uses MCP to call tools such as product search or price comparison. Once it has a candidate purchase, it is responsible for generating or requesting the Cart Mandate and presenting it back to the user (or checking it against a previously-signed Intent Mandate) before payment proceeds.

Merchant Endpoint

The Merchant Endpoint receives the agent's request, validates the Cart Mandate against its own catalog and pricing, and fulfills the order once payment is authorized. Because AP2 is payment-agnostic and merchant-agnostic, the same Shopping Agent can transact with any AP2-compliant merchant without custom integration work — the Merchant Endpoint is the counterpart role to a merchant's existing checkout API, extended to understand signed Mandates instead of only a browser-driven checkout session.

Credentials Provider / Payment Processor

This role issues and manages the user's verifiable credentials (the cryptographic keys and identity material used to sign Mandates) and executes the actual movement of funds once a Payment Mandate is presented — over whatever rail is appropriate: a card network, a real-time bank transfer, or a stablecoin/crypto rail via the x402 extension. Keeping this role distinct from the Shopping Agent is deliberate: the agent that decides what to buy should not be the same party that holds raw payment credentials.

Mandates: Intent, Cart, and Payment

Mandates are the heart of AP2 — tamper-evident, cryptographically signed digital contracts that create a non-repudiable audit trail from the user's original intent all the way through to the completed payment.

• Intent Mandate: Signed by the user up front. Captures what the user wants and the rules of engagement — for a real-time purchase it can be as simple as "I want to buy this," and for a delegated task it encodes conditions such as a price ceiling, a time window, or specific criteria the agent must satisfy before it can act without the user present.
• Cart Mandate: Created once the Shopping Agent has assembled a specific set of items at a specific price. In a human-present flow, the user signs the Cart Mandate directly as their approval of that exact purchase. In a delegated flow, the agent can generate and sign the Cart Mandate on the user's behalf, but only when the cart precisely satisfies the conditions already locked into the Intent Mandate.
• Payment Mandate: Links the approved Cart Mandate to a specific payment method and authorizes the Credentials Provider / Payment Processor to move funds. This is the artifact that ultimately answers the question a card network or bank needs answered: is this specific charge backed by a verifiable chain of user authorization?

Together, the three Mandates let a merchant or payment network verify three separate questions independently: was the user's original intent genuine, does the cart match what was authorized, and is the payment method valid for this specific cart — without any single party needing to see everything at once.

Common AP2 patterns

Human-present real-time purchase

The user asks the Shopping Agent to find and buy something right now. The agent searches, curates a cart, and presents it to the user for explicit approval. The user's signature on the Cart Mandate is the authorization event; the Payment Mandate is generated immediately afterward and sent to the Credentials Provider to execute. This is the simplest AP2 flow to diagram: Intent → Cart (user-signed) → Payment, all within a single session.

Human-not-present delegated task (agentic commerce)

The user signs a detailed Intent Mandate up front — for example, "rebook this flight if it's cancelled, as long as the new fare is under $400 and departs the same day" — and walks away. Later, the Shopping Agent (or a monitoring process behind it) detects that the conditions are met, assembles a Cart Mandate that satisfies the pre-signed conditions, and the agent itself signs the Cart Mandate on the user's behalf. Diagrams for this pattern should show the time gap between Intent Mandate signing and Cart Mandate generation, and make clear that the agent's signing authority is strictly bounded by the conditions in the original Intent Mandate.

Crypto / stablecoin rail via the x402 extension

For digital-currency payments, AP2 partners with Coinbase, MetaMask, and the Ethereum Foundation on an extension (built on the A2A x402 pattern) that lets a Payment Mandate settle over a stablecoin or crypto rail instead of a card network or bank transfer. The Mandate chain (Intent → Cart → Payment) stays the same; only the rail the Credentials Provider uses to execute the Payment Mandate changes. Show this in a diagram as a swappable settlement rail behind the Credentials Provider, not as a different protocol.

AP2 roles and mandates at a glance

Prompt templates for AP2 architecture diagrams

Human-present real-time purchase flow

Delegated, human-not-present agentic commerce task

Multi-agent booking with a stablecoin settlement rail

What a good AP2 diagram must show

• The four roles as distinct boxes: User, Shopping Agent, Merchant Endpoint, and Credentials Provider / Payment Processor — never merged into a single "agent" blob
• Each Mandate as a labeled artifact: Intent, Cart, and Payment Mandates drawn as distinct signed objects flowing through the diagram, not implied arrows
• Who signs each Mandate: Clearly mark whether the User or the Shopping Agent is the signer for the Cart Mandate in a given flow
• Human-present vs. human-not-present: If the flow is delegated, show the time gap between Intent Mandate signing and later autonomous execution
• Underlying A2A/MCP layer: Where the Shopping Agent uses A2A to delegate to specialist agents or MCP to call tools, distinguished visually from the Mandate flow
• The settlement rail: Card network, real-time bank transfer, or stablecoin/crypto rail (x402), labeled on the arrow from the Credentials Provider
• Trust boundaries: The Shopping Agent and the Credentials Provider should sit in separate trust zones — the agent should never hold raw payment credentials directly

AP2 architecture FAQ

What is AP2?

AP2 (Agent Payments Protocol) is an open, payment-agnostic protocol that Google announced in September 2025 with 60+ partners, including Mastercard, PayPal, American Express, and Coinbase. It lets an AI agent make a purchase on a user's behalf while giving merchants and payment providers a cryptographically verifiable, non-repudiable proof that the user actually authorized that specific transaction — via a chain of signed Mandates rather than trusting the agent's say-so.

How does AP2 relate to MCP and A2A?

AP2 is built as an extension on top of both protocols rather than a competing standard. MCP standardizes how an agent calls tools (like product search or an inventory API); A2A standardizes how one agent delegates a task to another agent (like a Shopping Agent delegating to a Flight Agent). AP2 adds a payment-specific trust layer on top of both: it defines the Mandates and roles needed to prove that any purchase an AP2-compliant agent makes traces back to explicit, verifiable user authorization.

How do I diagram Mandates in an AP2 flow?

Draw each Mandate (Intent, Cart, Payment) as its own labeled artifact — not just an arrow — passed between roles, and annotate who signed it (the User or the Shopping Agent acting within pre-authorized conditions). Showing the three Mandates as a left-to-right chain (Intent → Cart → Payment) makes the audit trail obvious at a glance, and is the clearest way to distinguish a human-present approval flow from a fully delegated one where the agent signs on the user's behalf.

Does AP2 require crypto or stablecoins?

No. AP2's core Mandate chain is payment-rail-agnostic and works with today's card-based payments and real-time bank transfers. The x402 extension, built with Coinbase, MetaMask, and the Ethereum Foundation, adds support for stablecoin and cryptocurrency settlement as one additional rail behind the Credentials Provider — it is optional, not a requirement of the base protocol.

Who are the main AP2 partners?

Google launched AP2 with more than 60 organizations spanning payment networks (Mastercard, American Express, JCB, UnionPay International), payment processors (PayPal, Adyen, Worldpay), crypto/web3 companies (Coinbase, MetaMask, the Ethereum Foundation), and commerce and enterprise platforms (Salesforce, ServiceNow, Etsy). The exact list continues to grow as more organizations adopt the open specification.

Related guides: A2A protocol architecture diagrams, MCP architecture diagram, securing agentic AI systems, and fintech architecture diagrams.