Agent Payments Protocol (AP2)

Every protocol we have examined so far in this series - MCP, A2A, and ACP - addresses how agents communicate. How they discover tools. How they delegate tasks. How they exchange content across organisational boundaries. These are essential capabilities, but they all share a conspicuous blind spot: none of them address what happens when an agent needs to spend money.

This is not a minor gap. It is the gap. The entire promise of agentic commerce - agents that can research, compare, negotiate, and purchase on behalf of humans - depends on solving a problem that no existing payment infrastructure was designed to handle: how do you authorise a financial transaction when the entity initiating it is not a person?

Today's payment systems are built on a foundational assumption: a human is clicking "buy" on a trusted website. Authentication, authorisation, fraud detection, liability assignment - every layer of the payments stack presupposes direct human involvement. When an autonomous agent initiates a purchase, this assumption collapses. The card networks do not know whether the agent is acting on genuine instructions or hallucinating a purchase. The merchant cannot verify that the agent has authority to spend. The issuing bank has no framework for assessing the risk of a transaction initiated by software rather than a person. The implications for agentic banking are profound, and the challenge of agentic KYC sits at the heart of this transformation.

In September 2025, Google announced the Agent Payments Protocol (AP2) - an open protocol designed to solve this problem. Backed by PayPal, Visa, Mastercard, American Express, Stripe, Shopify, and dozens of other ecosystem participants, AP2 provides a common language for secure, compliant transactions between AI agents and merchants. It is, in effect, the financial layer that the agentic communication protocols were missing. Our analysis of AI agent payments design examines the trust patterns that make this infrastructure viable.

For practitioners of Agentic Experience Design, AP2 is not merely a payments specification. It is the most concrete expression yet of trust architecture applied to real-world commerce. It operationalises concepts that AXD has been developing since its inception - intent architecture, delegation design, trust calibration, and failure architecture - in a protocol that will govern how billions of pounds move through autonomous systems.

The AP2 specification opens with a clear statement of the problem: "Today's payment systems assume a human is directly clicking 'buy' on a trusted website. When an autonomous agent initiates a payment, this core assumption is broken." This is not hyperbole. It is a precise description of a structural vulnerability that affects every participant in the payments ecosystem.

The trust gap manifests in three critical questions that current systems cannot answer. First, authorisation: what verifiable proof demonstrates that the user granted the agent specific authority to make this particular purchase? A user might tell their agent to "find me a good deal on running shoes under 100 pounds," but the current payments infrastructure has no mechanism to verify that the agent's subsequent purchase of a 95-pound pair of trainers from an unfamiliar merchant actually reflects that instruction.

Second, authenticity of intent: how can a merchant or payment processor be certain that the agent's request accurately reflects the human user's true intent? Large language models hallucinate. They misinterpret instructions. They optimise for metrics that may not align with what the user actually wanted. When the consequence of misinterpretation is a financial transaction, the stakes are categorically different from a chatbot giving a wrong answer.

Third, accountability: if a fraudulent or erroneous transaction occurs, who is accountable? The user who delegated the task? The developer of the shopping agent? The merchant who accepted the order? The payment network that processed it? Current liability frameworks have no answer because they were never designed to accommodate non-human transaction initiators.

Without a protocol to address these questions, the AP2 specification warns, the industry faces "a patchwork of proprietary, closed-loop solutions" - large retailers building bespoke integrations, payment providers creating siloed ecosystems, and small merchants locked out entirely. This fragmentation would be devastating for users (inconsistent experiences), merchants (high integration costs), and the payments ecosystem (inability to assess fraud consistently). AP2 exists to prevent this outcome by providing a common, open standard.

AP2 solves the trust gap through a role-based architecture that separates concerns with surgical precision. Rather than treating an agent-initiated transaction as a single opaque event, the protocol decomposes it into distinct roles, each with defined responsibilities, capabilities, and trust boundaries. This separation is not merely organisational - it is the mechanism through which accountability is engineered into every transaction.

The architecture defines five primary actors. The User is the human principal who delegates authority and retains ultimate control. The User Agent is the AI agent acting on behalf of the user - the shopping agent, the procurement bot, the personal assistant that initiates the purchase. The Merchant Agent is the AI agent representing the seller, handling product discovery, pricing, and order fulfilment. The Credential Provider issues and manages the cryptographic credentials that anchor trust - typically a payment processor or digital wallet provider. And the Payment Network and Issuer process the actual financial transaction, applying their existing fraud detection and risk assessment capabilities.

What makes this architecture significant from an AXD perspective is how it maps directly to the multi-agent orchestration visibility model. Each actor has a defined role, a bounded scope of authority, and a verifiable identity. The user agent cannot impersonate the credential provider. The merchant agent cannot forge the user's authorisation. The payment network receives explicit signals about agent involvement that it can use to calibrate risk. Every boundary between actors is a trust boundary, and every trust boundary is enforced cryptographically.

The most important innovation in AP2 is not its architecture but its trust mechanism: Verifiable Digital Credentials (VDCs). These are tamper-evident, cryptographically signed digital objects that serve as the building blocks of every transaction. They are the data payloads that agents create and exchange, and they are what transforms an agent's claim of authority into provable, auditable fact.

AP2 defines three primary types of VDC, each serving a distinct function in the trust chain. The Intent Mandate captures the conditions under which an agent can make a purchase on behalf of the user, particularly in scenarios where the human is not actively present. It specifies spending limits, product categories, merchant restrictions, and time constraints. When a user tells their agent "buy me coffee beans every month, spending no more than 25 pounds per order, only from certified organic suppliers," the Intent Mandate is the cryptographic encoding of that instruction. It provides the agent with bounded authority - not a blank cheque, but a precisely scoped delegation.

The Cart Mandate captures the user's final, explicit authorisation for a specific cart in scenarios where the human is present and reviewing the purchase. It includes the exact items, quantities, and price. The user's cryptographic signature on this mandate provides non-repudiable proof of their intent - not inferred intent, not assumed intent, but mathematically verifiable intent. This is the AP2 specification's answer to the hallucination problem: if the agent misinterpreted the user's request, the Cart Mandate will not match the user's actual authorisation, and the transaction will fail.

The Payment Mandate is a separate VDC shared with the payment network and issuer. It is designed to signal AI agent involvement and user presence (human-present or human-not-present) to help the payments ecosystem assess transaction context. This is critical because it allows card networks and issuers to develop agent-specific risk models rather than treating agent-initiated transactions as anomalous human behaviour - which is what happens today, often resulting in false fraud flags and declined transactions.

From an AXD perspective, the VDC framework is the most sophisticated implementation of trust architecture yet deployed in a production protocol. Each mandate type maps directly to a layer of the trust model: the Intent Mandate operationalises delegation design (spending authority and scope), the Cart Mandate operationalises trust calibration (verifiable intent), and the Payment Mandate operationalises the explainability standard (decision rationale for regulators and risk assessors).

AP2's core insight is that trust in agent payments cannot be inferred from behaviour. It must be engineered into the transaction through cryptographic proof of human intent.

AP2 distinguishes between two fundamental transaction types, and this distinction is one of the protocol's most important design decisions. In a human-present transaction, the user is actively involved in the purchase flow. The agent has done the research, compared options, and assembled a cart, but the user reviews and explicitly approves the final purchase before any money moves.

The flow works as follows. The user instructs their agent to find a product. The user agent communicates with one or more merchant agents via A2A, discovering products, comparing prices, and negotiating terms. When the agent has assembled a recommended cart, it presents the selection to the user for review. The user examines the items, prices, and merchant details, then authorises the purchase by signing a Cart Mandate - a cryptographic attestation that says "I, the human, approve this specific cart at this specific price from this specific merchant."

The signed Cart Mandate is then passed to the credential provider, which issues a Payment Mandate to the payment network. The Payment Mandate includes signals indicating that this is an agent-facilitated but human-authorised transaction, allowing the issuer to apply appropriate risk scoring. The transaction proceeds through the standard payment rails, but with an additional layer of cryptographic provenance that current payment systems lack entirely.

In AXD terms, the human-present flow maps to the lower end of the autonomy gradient - the agent has significant autonomy in research and recommendation, but the human retains direct control over the financial commitment. The interrupt pattern library governs the moment of transition: the agent must present its recommendation in a way that enables genuine informed consent, not merely a rubber-stamp approval of a decision already made.

The more transformative - and more challenging - transaction type is the human-not-present flow. This is where the agent acts autonomously, making purchasing decisions and executing transactions without real-time human oversight. It is the scenario that most fully realises the promise of agentic commerce, and the one that demands the most rigorous trust engineering.

In this flow, the user has previously defined an Intent Mandate - a cryptographically signed set of constraints that bound the agent's purchasing authority. The mandate might specify: spend no more than 50 pounds per transaction, no more than 200 pounds per month, only from merchants with a verified trust score above a threshold, only for products in specified categories, and only during specified time windows. The agent operates within these constraints autonomously, making purchases when conditions are met without requiring human approval for each transaction.

This is where AP2's design becomes genuinely novel. The Intent Mandate is not a simple spending limit - it is a structured delegation instrument that encodes the user's preferences, constraints, and risk tolerance into a machine-readable, cryptographically verifiable format. Every transaction the agent initiates is checked against the mandate. If the agent attempts to exceed the mandate's constraints - buying from an unauthorised merchant, exceeding a spending limit, purchasing outside approved categories - the transaction is rejected at the protocol level, before any money moves.

The human-not-present flow maps to the upper end of the autonomy gradient. It is the design space where AXD's frameworks are most critical. The delegation design framework governs how the Intent Mandate is constructed - what constraints are available, how they are presented to the user, and how the user understands the scope of authority they are granting. The consent horizon determines how far into the future the mandate extends. And the absent-state audit governs how the user reviews and reconciles transactions that occurred while they were not present.

The Intent Mandate is not a blank cheque. It is a precisely scoped delegation instrument - the cryptographic encoding of "I trust you to act within these boundaries, and I can verify that you did."

One of the most consequential aspects of AP2 is its approach to dispute resolution. In traditional e-commerce, chargebacks and disputes follow well-established procedures: the cardholder claims they did not authorise a transaction, the merchant provides evidence of delivery, and the card network adjudicates. But when an agent initiates a transaction, the existing dispute framework breaks down. Did the user authorise it? The agent says yes. The user says they did not mean that specific purchase. Who is right?

AP2 resolves this ambiguity through its cryptographic audit trail. Every transaction produces a chain of VDCs that documents exactly what was authorised, by whom, under what constraints, and at what time. If a user disputes a human-present transaction, the Cart Mandate provides their cryptographic signature on the exact cart they approved - there is no ambiguity about what they authorised. If a user disputes a human-not-present transaction, the Intent Mandate documents the constraints the agent was operating under, and the transaction record shows whether the agent stayed within those constraints.

This creates a new category of dispute that current systems do not handle: the "within-mandate but unwanted" transaction. The user set a mandate allowing their agent to buy coffee beans monthly for up to 25 pounds. The agent bought a 24-pound bag of beans the user did not like. The mandate was honoured, but the user is unhappy. AP2's framework makes it clear that this is not a fraud dispute - it is a preference dispute, and the accountability lies with the mandate's design, not the agent's execution.

This distinction maps directly to AXD's failure architecture blueprint. Protocol failures (agent exceeded mandate) are categorically different from preference failures (agent stayed within mandate but chose poorly). Each requires a different recovery pattern, a different user interface, and a different accountability model. Designers must build experiences that help users understand which type of failure occurred and what recourse is available for each.

AP2 is remarkable not only for what it solves but for how closely its design aligns with the frameworks that AXD has been developing. This alignment is not coincidental - both AP2 and AXD are responses to the same fundamental challenge: engineering trust into systems where autonomous agents act on behalf of humans. The difference is that AXD approaches this challenge from the design perspective, while AP2 approaches it from the protocol perspective. Together, they form a complete picture.

Mandate design is the new checkout design. The most important interface in AP2-enabled commerce is not the product page or the cart - it is the mandate creation screen. The AXD Institute's analysis of the agent checkout examines how this shift from human-facing checkout to agent-mediated transaction is redesigning the entire purchase flow. When a user defines an Intent Mandate, they are making a complex delegation decision: how much authority to grant, under what constraints, for how long, and with what recourse if something goes wrong. This interface must make the implications of each constraint legible to non-technical users. "Spend up to 50 pounds per transaction" is clear. "Only from merchants with AP2 compliance level 3 or above" is not. Designers must translate protocol-level constraints into human-readable, human-modifiable terms.

Transaction review must reflect the trust model. In human-present flows, the Cart Mandate signing moment is the critical trust point. The interface must present the cart in a way that enables genuine review - not a wall of text that users scroll past, but a clear, scannable summary that highlights what the agent chose, why it chose it, and what alternatives were considered. The signing action itself must feel consequential. This is not "add to cart" - it is "I cryptographically attest that I authorise this purchase."

Absent-state reconciliation becomes a first-class design problem. For human-not-present transactions, the user will return to find that their agent has made purchases on their behalf. The reconciliation interface must show not just what was bought, but whether each purchase was within the mandate's constraints, how much of the mandate's budget has been consumed, and whether any transactions triggered step-up challenges or were declined. This is the absent-state audit in its most concrete form.

Dispute interfaces must distinguish failure types. As discussed in the dispute resolution section, AP2 creates a new taxonomy of transaction failures. Designers must build interfaces that help users understand whether a disputed transaction was a protocol failure (agent exceeded mandate), a preference failure (agent stayed within mandate but chose poorly), or a fraud event (mandate was forged or compromised). Each type requires different information, different actions, and different emotional framing.

Trust indicators must be protocol-aware. When a user's agent presents a recommended purchase, the interface should communicate the trust signals available through AP2: Is the merchant AP2-compliant? Has the credential provider verified the merchant's identity? What is the merchant's transaction history? These signals exist at the protocol level, but they only become useful when designers surface them in contextually appropriate ways. A green checkmark next to a merchant name means nothing unless the user understands what it represents.

AP2 represents a paradigm shift in how trust is engineered into financial transactions. For decades, trust in payments was a human problem - solved by signatures, PINs, biometrics, and the implicit assumption that a person was present at the point of sale. AP2 transforms trust from a human verification problem into a cryptographic infrastructure problem. It does not ask "is this person who they claim to be?" It asks "does this agent have verifiable, bounded authority to act on behalf of a person who has cryptographically attested their intent?"

This is not a minor technical distinction. It is the foundation on which the entire agentic commerce economy will be built. Without AP2 or a protocol like it, autonomous agents cannot participate in the financial system as trusted actors. With it, they can - but only within the constraints that humans have explicitly defined and cryptographically signed.

For practitioners of Agentic Experience Design, AP2 is both validation and challenge. It validates the AXD thesis that trust architecture, delegation design, and intent architecture are not abstract design concepts but structural requirements of any system where agents handle money. And it challenges designers to build interfaces worthy of the protocol's sophistication - interfaces that make cryptographic trust legible, mandate constraints modifiable, and autonomous transactions auditable.

The protocol is young - version 0.1, with a roadmap that extends to push payments, recurring subscriptions, multi-merchant transactions, and real-time agent-to-agent negotiations. As it matures, the design challenges will only intensify. But the foundational principle is clear: in the agentic age, trust is not assumed. It is not inferred. It is engineered, verified, and designed.

In the agentic age, trust in payments is not assumed, not inferred, and not inherited from human presence. It is engineered into the protocol, verified through cryptography, and made legible through design.