AP2 (Agent Payments Protocol) Architecture: How to Diagram Agentic Commerce Systems (2026)

AP2 (Agent Payments Protocol) is an open protocol, originally published by Google with support from over 60 payments and technology partners, that defines how an AI agent can initiate and complete a financial transaction on a user's behalf without ever touching the user's raw banking credentials. As agentic commerce moves from demo to production in 2026 — with Visa Intelligent Commerce, Mastercard Agent Pay, and PayPal all shipping agent checkout integrations — AP2 has become the reference architecture engineering teams reach for when they need to diagram "how does the agent actually pay for anything."

An AP2 architecture diagram makes the trust boundary explicit: which party holds authority at each step, what gets signed, and where a human is still in the loop. This guide covers the AP2 role model, the mandate chain that anchors the protocol, how it composes with MCP and A2A, and prompt templates for generating AP2 architecture diagrams in seconds.

Why agentic commerce needs its own protocol

Before AP2, an agent that wanted to "buy something for you" had two bad options: share your actual card credentials with the agent (a massive security and liability risk), or fall back to a human clicking "confirm" on every single purchase (which defeats the point of automation). Neither scales to an agent doing real procurement, subscription management, or price-monitoring purchases across dozens of merchants. AP2 solves this by separating intent from authorization from execution, and making each handoff a cryptographically verifiable object instead of an implicit trust assumption.

The four roles in an AP2 architecture

Every AP2 diagram should show these four roles as distinct nodes, even when one company operates more than one role in practice:

• User: The human who holds financial authority and delegates a task — "book me a flight under $400" — to their agent, with explicit constraints on what the agent may spend.
• Agent: The AI system (an assistant, a shopping agent, a procurement bot) that plans and negotiates on the user's behalf, but never holds raw payment credentials — it holds signed mandates instead.
• Merchant / merchant agent: The counterparty selling the good or service, which may itself be an agent (an autonomous storefront) rather than a traditional e-commerce checkout flow.
• Credentials provider: The bank, card network, or payment processor that holds the actual financial instrument and verifies the mandate chain before moving money — this is where Visa, Mastercard, or a bank's existing rails plug in.

The mandate chain: intent, cart, and payment

AP2's core primitive is the mandate — a cryptographically signed, verifiable credential that proves a step in the transaction was authorized by the right party. A complete AP2 flow produces three mandates in sequence, and your diagram should show each as a discrete artifact passed between roles, not as an implicit API call:

1. Intent mandate: Signed by the user, this captures what the agent is authorized to do — the task, the spending cap, the merchant category, and any time window. This is the human's delegation of authority.
2. Cart mandate: Signed by the merchant, this locks in the exact items, price, and terms the agent has agreed to — preventing a bait-and-switch where the final charge differs from what was negotiated.
3. Payment mandate: Signed by the user (directly, or via a pre-authorized delegation for low-risk purchases), this authorizes the credentials provider to actually move funds against the cart mandate.

For a human-present purchase, the user signs the payment mandate at checkout time. For a human-not-present purchase — an agent autonomously restocking inventory or renewing a subscription within pre-approved limits — the payment mandate is generated from a standing authorization the user granted up front. Your diagram should label which mode applies, since it changes where the human approval step sits.

How AP2 composes with MCP and A2A

AP2 is a payments-layer protocol, not a replacement for the agent communication protocols already in your stack. In a real diagram, the three typically stack together:

• MCP (Model Context Protocol) connects your agent to tools and data sources — the product catalog, the user's calendar, the inventory API.
• A2A (Agent2Agent Protocol) lets your shopping agent negotiate with a separate merchant agent — discovering capabilities, exchanging offers, and agreeing on a cart.
• AP2 is invoked at the very end of that A2A negotiation to turn an agreed cart into a verifiable, signed payment — the settlement layer underneath the negotiation.

See our A2A protocol architecture guide and MCP architecture diagram guide for the layers that typically sit above AP2 in a full agentic commerce stack.

Prompt templates for AP2 architecture diagrams

Consumer shopping agent with human-present checkout

Autonomous procurement agent with standing authorization

Design principles for agentic commerce diagrams

• Show the mandate chain explicitly: Draw intent, cart, and payment mandates as separate labeled artifacts flowing between roles — not as a single "checkout" arrow. The whole point of AP2 is that each step is independently verifiable.
• Label human-present vs. human-not-present: These two modes have very different risk profiles and different points where a live signature is required — your diagram should make it unambiguous which applies.
• Separate identity from capability: The agent's identity (who it is) is distinct from what it is authorized to spend (the mandate). Never draw a single node that conflates "the agent" with "the agent's spending power."
• Cap and audit trail: Show spending caps as constraints on the intent mandate and show the audit log as a persistent store — regulators and card networks will ask for both in any review of an agentic payments system.

Frequently asked questions about AP2 architecture

What is AP2 (Agent Payments Protocol)?

AP2 is an open protocol for AI agents to make payments on a user's behalf using cryptographically signed mandates instead of shared credentials. It defines a role-based architecture (user, agent, merchant, credentials provider) and a three-mandate chain (intent, cart, payment) that lets every party in a transaction verify what was actually authorized, without the agent ever holding raw card numbers or bank credentials.

How is AP2 different from MCP or A2A?

MCP connects an agent to tools and data sources; A2A lets two agents discover each other and negotiate. AP2 sits underneath both, as the settlement layer that turns an agreed-upon purchase into a verified, authorized payment. A full agentic commerce stack typically uses all three together: MCP for catalog data, A2A for merchant negotiation, and AP2 for the actual transaction.

Does AP2 require a human to approve every purchase?

No. AP2 supports both human-present transactions (the user signs a payment mandate live, e.g., via a WebAuthn prompt) and human-not-present transactions, where the agent operates within a standing intent mandate the user signed in advance, complete with spending caps and merchant restrictions. The protocol is designed so the level of human involvement is an explicit, auditable choice rather than an implicit assumption.

Related guides: A2A protocol architecture, MCP architecture diagrams, AI agent identity & access management, and agentic AI security architecture.