Table of Contents
Imagine this: You’re gearing up for a weekend trip and are up to your ears with work, but your favorite pair of sneakers is about to fall apart. Instead of spending hours scrolling through options, you simply tell your personal AI agent, “Buy me some new sneakers.” The agent begins browsing the web. It searches retailers, compares prices, and finally adds the perfect pair to the cart.
Now that it’s time to check out and pay, we’re faced with several challenges:
How does your agent prove you authorized this purchase, and it’s not hallucinating or misunderstanding your request?
How can the merchant know the agent is acting on your behalf and isn’t some fraudster?
If something unexpected happens, who is accountable?
This is why Google developed the Agent Payments Protocol (AP2), an open standard with backing from more than 60 organizations spanning ecommerce, payment processing, and more. AP2 addresses the difficult trust questions that arise when AI agents take on commercial transactions:
Authorization: Did the agent actually have permission to do this?
Authenticity: Does this action reflect the user’s true intent?
Accountability: Who’s liable if something goes wrong?
Just as the Model Context Protocol (MCP) standardized how AI agents access tools and data, AP2 standardizes how agents handle payments. In this post, we’ll explore why traditional payment structures fall short with autonomous agents, how AP2 addresses this problem through secure “mandates,” and what this new avenue for online commerce means for the future of AI.
Why traditional payment processes don’t handle AI agents securely
Every payment system built over the past few decades has assumed one thing: There’s a real, live human directly clicking the “Buy” button. When a semi-autonomous agent takes that action instead, the entire trust model falls apart.
Current online payment systems are designed around human presence. Authentication happens when a user goes to a site or accesses an app. They see exactly what they’re buying, confirming their intent at the moment of purchase. These assumptions no longer hold up, however, when AI agents act on behalf of users.
The gap between agentic processes and traditional payment models raises three core challenges:
Authorization is whether an agent really had a human’s permission to make a specific purchase. Traditional authorization in commerce assumes real-time human presence, but an agent might execute a transaction long after a user said “Buy scented candles when they go on sale.” The merchant needs verifiable proof that the user really delegated this task to their agent.
Authenticity determines if the request represents a user’s true intent, and not a misunderstanding or hallucination. AI agents can misinterpret details, simply make up plausible (but hallucinatory) filler, or make logical errors. Without a mechanism in place to validate the underlying intent, merchants don’t have a reliable way to distinguish between legitimate purchases stemming from reality and an AI misfire.
Accountability decides who is responsible for payment if an agent makes a mistake. Should the user pay for an item they don’t actually want because the AI agent misunderstood? Would the merchant who fulfilled it be responsible? Or perhaps the developer who built the agent, or the platform that hosts it? Current systems simply don’t have clear answers.
Meanwhile, without a standardized protocol, we’re facing the same fragmentation issues that plagued AI development before MCP: Every AI platform needs proprietary integrations with every merchant and payment provider, an NxM complexity headache.
The NxM problem here, though, invites another variable due to its consumer-facing orientation: user and merchant trust. Users aren’t going to authorize their agents to spend a cent through unfamiliar, niche integrations. Similarly, merchants won’t accept payments through unpopular, unproven methods they can’t validate. And payment networks won’t process transactions if they can’t understand how agent involvement impacts risk.
In short, the entire agentic commerce ecosystem needs a common foundation to get past the starting block. And that’s exactly what AP2 has to offer.
How AP2 secures agentic commercial transactions
AP2’s solution centers around “mandates”: tamper-evident, cryptographically-signed digital contracts that serve as verifiable proof of user intent. Rather than relying on inferred actions or probabilistic AI outputs (which are both prone to uncertainty and hallucination), mandates provide absolute, deterministic evidence of what a user authorized.
Mandates are based on the W3C Verifiable Credentials standard, which offers them proven portability, interoperability, and resilience. Each mandate is made tamper-evident by cryptographic signatures: If any modification occurs, it invalidates the entire credential.
Two main types of agentic commercial transactions
Each mandate addresses one of the two primary ways a user can shop with an agent: real-time purchases (human-present, or HP) and delegated tasks (human-not-present. or HNP).
Real-time purchases happen while you’re interacting with the agent. If you ask your agent to “buy me a new pair of sunglasses” and it executes while you’re still there, that’s a real-time, human-present (HP) transaction.
Delegated tasks happen without your presence. If you say to your agent, “Buy this dress when it’s on sale for under $100,” that is the initial step in a delegated, human-not-present (HNP) transaction.
Three AP2 mandates
AP2 defines three types of mandates, each serving a specific role in one of these two transaction types:
The Intent Mandate is created when the user first makes a request. For HP scenarios, the Intent Mandate creates the auditable context for the entire interaction.
For HNP scenarios, the Intent Mandate provides the agent with the authority to act within predefined boundaries. These are presented as an upfront agreement detailing the shopping intent and conditions (what you’re looking for, price limits, timing constraints, etc.).
The Cart Mandate captures the user’s final, explicit authorization for a specific cart. This locks in the exact items and price, creating an immutable record going forward.
In HP scenarios, the user reviews what the agent found and approves the cart. The user’s cryptographic signature on the Cart Mandate provides non-repudiable proof of their approval. This ensures that what the user sees is what they’re paying for.
In HNP scenarios, the Intent Mandate allows the agent to create a Cart Mandate once the exact parameters have been met.
The Payment Mandate is a minimal credential appended to the authorization and derived from the Cart or Intent Mandate. It provides issuers and payment networks with visibility into agent presence and operation mode (human-present or human-not-present) without altering existing authorization flows.
This complete sequence (from initial intent to final payment) creates an audit trail that answers all three critical questions above: authorization (the signed Intent Mandate), authenticity (the Cart Mandate’s exact parameters), and accountability (combining all three mandates).
The trust model today is guaranteed by signed mandates and hand-picked allowlists of trusted participants. The limited initial proliferation is designed for immediate deployment among specific, trusted parties. However, the next stage will see AP2 grow to incorporate more trust modalities that onboard new participants, using open internet standards like HTTPS, DNS ownership, and mutual TLS.
Understanding AP2 architecture
AP2 uses a role-based model that separates responsibilities and confines sensitive data to appropriate entities. Roles are core AP2 elements that include:
User: The human who initiates intent.
Agent: The AI tool, application, or system that executes tasks on behalf of the user.
Credential provider: The entity that secures payment methods and manages authentication.
Merchant endpoint/processor: The destination for mandates that executes settlement.
Issuer/network: The entity that authorizes transactions using standard risk models supplemented by mandate context.
Separating these roles ensures PCI-compliant data handling. Payment credentials stay with credential providers, never unnecessarily exposed to shopping agents or merchants. Each participant has a clearly defined role, making accountability straightforward.
AP2 is also payment-agnostic, meaning that it supports:
Traditional payment methods: Credit and debit cards, real-time bank transfers like UPI and PIX
Digital currencies: Stablecoins and cryptocurrencies through the x402 extension
Why is this such a big deal? While the newer x402 extension provides production-ready, agent-based crypto payments, AP2 integrates with existing payment infrastructure without requiring changes to current risk and fraud systems.
Most payment processors, who traditionally shy away even from stablecoins, wouldn’t be able to adopt x402—but they can embrace AP2 because it’s able to conform with their compliance and risk needs. Subsequently, consumers don’t have to be avid cryptocurrency enthusiasts to start shopping with agents using AP2.
AP2 in the larger AI protocol landscape
Despite its distinctive architecture, AP2 doesn’t exist in a vacuum. It’s designed to work as an extension of other protocols built for agent enablement:
Agent2Agent (A2A): AP2 can operate as an extension of the A2A protocol, allowing multi-agent collaboration while offering commercial functionality.
Model Context Protocol (MCP): AP2 may also be used as an extension of MCP, which gives agents structured access to tools, APIs, and data sources.
Integration with both of these protocols offers agents essential API access (e.g., querying airlines for flight prices or Amazon for top deals), insights into Intent Mandate thresholds (e.g., calendar APIs for timing restocks, weather APIs for scheduling a conditional winter coat purchase), and multi-agent workflows (e.g., one agent handles airline ticketing while another takes on hotel reservations).
Of course, AP2 isn’t the only way to pay using AI. Other protocols, like Stripe and OpenAI’s Agentic Commerce Protocol (ACP) or Coinbase’s Payments MCP, offer direct and user-to-LLM-based alternatives. Where AP2 appears to stand out is with its payment agnosticism, no-fuss integration with existing frameworks, and broader support from commerce leaders.
However, ACP may have a distinct advantage over AP2 because of its immediate integration with ChatGPT, the world’s most popular consumer AI. And, in a choice between which convenience-oriented innovation to pay with, most casual users are more likely to go with the option closer at hand.
Both are still very recent developments, and both are open-source projects, so time will ultimately tell which earns greater public adoption.
AP2 use cases
AP2 opens up several types of autonomous and semi-autonomous transactions that traditional payment systems can’t handle as safely (or with the same natural language interaction):
Condition-based purchases
Tell an agent to “grab that set of golf clubs the second it drops below MSRP,” and it will monitor pricing until your threshold triggers a Cart Mandate. Think Ebay listings where customers battle it out with bids, but now carried out by agents. Conditions can be more complex, however, ranging from simple price parameters to expressing multiple preferences: “Buy a blue tie from a top brand, and I’m willing to pay up to 30% more for a silk one.” This eliminates the need to check countless listings or miss out on disappearing inventory. The Intent Mandate captures your preferences (“blue tie,” “top brand,” “up to 30% more if silk”), the Cart Mandate locks in the exact item when found, and you get an auditable path showing exactly what was purchased and why.
Multi-vendor coordination
Planning a trip can now be like having a personal travel agent. Give your AI a $1000 budget for flights and lodging, and it compares rates across airlines and hotels to find the best package deal within your limit. As before, the Intent Mandate sets out the parameters (where you’re going, how long, the budget, preferred hotel chains or airlines), and the Cart Mandate confirms you’re getting exactly what you want. You’ll agree to the exact conditions of the Intent Mandate before the agent gets to work. A process like this can take multiple steps, and without AP2, it would require you to manually review and approve each transaction separately. With AP2, the agent can execute coordinated bookings once you approve the overall plan, significantly reducing the (human-spent) time from hours of endless scrolling to seconds of approval.
Recurring purchases and business operations
Enterprises can automate software license scaling based on the needed seat count, streamline vendor payments with pre-approved spending rules, and enable direct agent-to-agent procurement between businesses. Similarly, for routine needs, agents can handle restocking or resubscribing automatically based on thresholds. But instead of buying more SaaS seats, you set parameters like “Keep me stocked up on cat food, under $30, earliest delivery, and avoid third-party sellers.” The agent runs periodic checks across retailers, evaluates prices, and when you’re running low, it automatically reorders within your defined limits. In both cases, the agent looks at context (how much time has passed since your last cat food restock, or how many employees are using certain software) and automatically purchases what’s needed when a threshold is reached. Again, and in both cases, the audit trails are all documented through signed mandates.
AP2 implementation considerations
AP2 was released in September 2025, which means it’s still early days for the open protocol. The specification is public, and reference implementations exist—but actual consumer-facing products using AP2 haven’t launched (yet). This creates both opportunities and challenges for different stakeholders.
For developers
Building AP2-compatible agents means implementing MCP and/or A2A, since it’s an extension of those protocols. Developers already using those protocols can easily add the payment layer. You’ll need to ensure agents properly generate signed Intent, Cart, and Payment Mandates using the AP2 library and following the W3C Verifiable Credentials format. You’ll also need to implement logic to handle both human-present and human-not-present modes, and exchange mandates with merchants and payment processors via standard messaging.
Here’s the good news: Securing MCP is fast, simple, and effective with Descope’s MCP Auth SDKs & APIs.
For merchants
The primary shift is understanding the mandate-based authorization model. Merchants receive Cart Mandates that contain cryptographically-signed proof of what the user approved, which can serve as dispute-grade evidence if issues arise. The mandate validation is handled through the mandates’ built-in signatures, not custom infrastructure. However, there is one important operational change you can make: making product catalogs machine-readable (with structured data on specifications, pricing, availability and policies) to help agents shop effectively.
For payment providers
The infrastructure work needed for AP2 adoption involves embedding mandate information into existing payment authorization messages. The Payment Mandates gets appended to standard transaction messages (e.g., ISO 8583 for card networks). Risk frameworks also need to ingest this new mandate metadata and incorporate it into existing fraud detection models, ensuring compliance with all relevant regulations and best practices (PCI, GDPR, KYC, etc.) AP2’s design intentionally avoids requiring changes to core payment systems, instead supplementing current flows with additional context.
For consumers
The potential for AP2 is sky-high, but adoption will take some time. As more merchants and platforms implement support, the user experience will gradually be refined. Understanding how mandates work (at least at a high level) can help you feel more confident when signing an Intent Mandate for purchases. But more importantly, knowing how your agent does its job can help you advocate for yourself if something unexpected happens.
What’s next for AP2
The path forward for AP2 relies greatly on ecosystem-wide adoption, and with a tiny handful of similar protocols in the mix, it’s unclear when (or if) the tipping point will arrive. However, the protocol’s value will grow as it (and the agentic landscape) matures, eliminating fragmentation and resolving many-to-many integration challenges—just like MCP did for tool calling before it.
Perhaps in the near future, we’ll all be saying, “Just buy me some new sneakers” to an agent and getting exactly what we want with minimal hassle: the right size, color, and brand already known by our helpful AI colleagues. And with AP2, we can also be sure our sneaker shopping is secure and accountable—but, thankfully, a lot less time-consuming.
For more educational content on agentic protocols, subscribe to the Descope blog or follow us on LinkedIn, X, and Bluesky.
