Agentic Payments: How AP2, x402, and ACP Let AI Agents Transact

An AI agent that can book your flight, compare five insurance quotes, or restock your kitchen when the coffee runs low is not very useful if it has to hand control back to a human every time money needs to change hands. That handoff — "click here to confirm your $340 purchase" — has been the quiet ceiling on what autonomous agents can actually do. Agentic payments protocols exist to remove that ceiling, and 2026 is the year several competing standards moved from whitepaper to production traffic.

This piece explains what agentic payments are, how the three protocols currently jockeying for position — Google's Agent Payments Protocol (AP2), Coinbase's x402, and OpenAI's Agentic Commerce Protocol (ACP) — actually work, and what the differences mean for anyone building or buying into this stack.

What "agentic payments" actually means

Agentic payments describes a transaction where an AI agent, acting on a human's or a business's behalf, initiates and completes a purchase without a person clicking "confirm" at the point of sale. This is a narrower claim than it sounds. Nobody serious is proposing that agents get unlimited, unsupervised spending power. The actual engineering problem is much more specific: how do you cryptographically prove, after the fact and to every party in the chain (the merchant, the card network, the bank, a regulator, a fraud team), that a human genuinely authorized an agent to spend up to a certain amount, on certain categories, under certain conditions — and that the agent stayed inside those bounds?

Traditional payment rails were never designed for this. Card-not-present authorization assumes a human is present at checkout, even if only to type in a CVV or approve a push notification. Agentic payments protocols insert a new authorization layer beneath the existing rails (or, in some cases, run in parallel to them) that captures consent once, up front, and then lets the agent act repeatedly within that consent envelope — with cryptographic receipts proving what happened at every step.

Three components tend to recur across all the serious proposals:

• A mandate or intent object — a signed, machine-readable statement of what the human authorized (e.g., "book the cheapest round-trip flight to Chicago under $450, departing after the 14th").
• An agent identity — a verifiable credential that says which agent, running on whose behalf, is making the request, distinct from the human's own identity.
• A settlement path — the actual rail the money moves on, which might be a card network, a bank transfer, a stablecoin, or something else entirely.

How AP2, x402, and ACP differ

The three protocols solve overlapping problems but come from different corners of the industry, which shows up in their design choices.

AP2 (Agent Payments Protocol), from Google, is the most rail-agnostic of the three. It defines a set of "mandates" — Intent Mandates, Cart Mandates, and Payment Mandates — as verifiable credentials that get passed between the user's agent, a merchant's agent, and the payment processor. The point of AP2 is to sit on top of whatever payment rail already exists (cards, bank transfers, real-time payments, crypto) rather than replace it, giving the network effect of existing infrastructure while adding an auditable consent trail. Its launch drew a notably wide coalition — more than 60 partners spanning payment networks, banks, and fintechs signed on at launch, signaling that incumbents wanted a seat at the table rather than being disrupted from outside.

x402, built by Coinbase around the long-dormant HTTP 402 "Payment Required" status code, takes almost the opposite approach: it is a native, stablecoin-first micropayment protocol designed for machine-to-machine transactions on the open web. An API or piece of content can respond to a request with a 402 status and a price; the requesting agent's wallet pays in a stablecoin, and access is granted, all within a single HTTP round trip. It's built for high-frequency, low-value transactions — an agent paying a few cents per API call or per web page it scrapes — where card-network interchange fees would make no economic sense. Within months of release, x402 reportedly processed roughly 165 million agent-driven transactions, evidence that the "pay-per-call" model found real usage among developers building agent tooling rather than staying a theoretical demo.

ACP (Agentic Commerce Protocol), developed by OpenAI with Stripe, is the most commerce-specific of the three: it's aimed squarely at letting a conversational agent complete a retail checkout — think an agent inside a chat interface buying a product from a merchant's catalog — using existing card rails and merchant-of-record relationships rather than inventing a new settlement layer. It leans on Stripe's existing infrastructure for the actual money movement and focuses its novelty on the checkout handoff: structured product data, cart construction, and a standardized way for a merchant to confirm order completion back to the agent.

None of these fully subsumes the others, which is itself informative: agentic payments isn't one problem, it's at least three — proving consent, moving small amounts of money efficiently between machines, and completing a recognizable retail checkout. Expect further consolidation, but not a single winner-take-all outcome soon.

Why this matters right now

The signal that agentic payments moved past the demo stage is the combination of Google's AP2 launch bringing in more than 60 partners from day one and Coinbase's x402 quietly clearing roughly 165 million transactions within months of release. Those are two very different kinds of validation. AP2's partner count shows that banks, card networks, and payment processors — institutions that move slowly and hate protocol risk — decided it was safer to help define the standard than to wait and be forced onto someone else's. x402's transaction volume shows that developers, without needing anyone's permission, started routing real (if small) money through the protocol because it solved an immediate problem: paying for API access and agent-to-agent services without setting up merchant accounts or negotiating contracts.

Put together, these two data points describe a market forming from both ends at once — top-down standardization from the biggest platform players, and bottom-up adoption from builders who needed a working mechanism today. That's usually the pattern that precedes a protocol becoming genuine infrastructure rather than a proof of concept.

What this changes for businesses and builders

For a business, the near-term question is not "should we let an AI agent spend our money," but "which of our transactions are already agent-adjacent, and what does authorization for them look like." A few practical implications follow directly from how these protocols work:

1. Consent needs to be structured, not implicit. A mandate that says "book a flight under $450" is enforceable; a vague instruction like "handle my travel" is not. Businesses deploying purchasing agents need to define spend policies as machine-readable rules, not just internal guidelines.
2. Merchants need agent-readable storefronts. ACP-style checkout depends on structured product data (price, availability, variants) that an agent can parse reliably. Sites built purely for human eyeballs — pricing buried in a JavaScript-rendered comparison table, for instance — will be effectively invisible to agentic buyers.
3. Micropayment economics change what's worth metering. x402 makes it viable to charge fractions of a cent per API call. That reopens business models — pay-per-query data feeds, pay-per-page content access — that flat subscription pricing had made impractical.
4. Reconciliation and audit trails become a product requirement, not an afterthought. Every one of these protocols generates a cryptographic record of what was authorized and what happened. Finance and compliance teams should expect to ingest and query these records the same way they do card statements today.
5. Identity verification for agents is a new attack surface. An agent credential that gets stolen or spoofed is functionally a stolen payment method, except the abuse can happen at machine speed across thousands of micro-transactions before a human notices a pattern.

Where the risk concentrates

The riskiest failure mode isn't a single large fraudulent transaction — those still get caught by existing fraud detection, since the dollar amounts trip the same thresholds they always did. The riskier pattern is drift: an agent operating correctly within its mandate for a long stretch, then a bug, a prompt injection, or a compromised upstream data source causes it to misinterpret its authorization and make many small, individually plausible purchases that only look wrong in aggregate. Protocols that support granular mandates (spend caps per category, per merchant, per time window) mitigate this; protocols that only support coarse authorization do not.

This is why the mandate design in AP2 matters more than it might first appear. An Intent Mandate that just says "handle procurement for the office" leaves an enormous amount of room for an agent — or an attacker who has compromised the agent's context — to justify almost any purchase as within scope. A Cart Mandate that itemizes exactly what's being bought, at what price, from which merchant, closes off that ambiguity at the moment of authorization rather than trying to catch the problem after the money has already moved. The general lesson for anyone deploying purchasing agents: the narrower and more specific the authorization, the smaller the blast radius when something goes wrong upstream in the agent's reasoning.

How settlement actually happens under the hood

It's worth walking through what happens end to end, because the abstraction of "the agent pays" hides a fair amount of machinery. In an AP2-style flow, a user's agent first collects an Intent Mandate from the human — typically through a normal conversational interface, not a special payments UI. When the agent finds something to buy, it constructs a Cart Mandate describing the specific line items and price, and that gets cryptographically signed as consistent with the original intent. A Payment Mandate then authorizes the actual funds movement, which gets handed to whatever processor or bank rail is already in place for that merchant. The result is a chain of three signed, auditable objects that a human, a bank's fraud team, or a regulator can inspect after the fact to reconstruct exactly what was asked for, what was found, and what was paid — without any of them needing to have been present at the moment of purchase.

x402's flow is deliberately much shorter, because it's solving a narrower problem. A request hits an endpoint; the server replies with HTTP 402 and a price; the requesting agent's wallet signs and broadcasts a stablecoin payment; the server verifies settlement and returns the resource. There's no multi-party mandate chain because the transaction is typically machine-to-machine and low-stakes enough that a simpler "pay to unlock" pattern is sufficient — closer to how a vending machine works than how a bank wire works.

ACP sits in between. The agent constructs a cart from a merchant's structured catalog data, and checkout is completed using the buyer's existing stored payment credentials, processed through Stripe's infrastructure. The novelty isn't a new settlement mechanism at all — it's a standardized way for the agent and merchant to agree on cart contents and confirm completion, so the conversational interface can tell the user "your order is confirmed" with the same certainty a human clicking "buy now" would have.

Real limitations and open questions

It's worth being clear-eyed about what isn't solved yet.

• Regulatory clarity is thin. Card network rules, KYC/AML obligations, and consumer protection law were written assuming a human initiates each transaction. Whether an agent's mandate satisfies "authorized user" requirements under existing card agreements, and who bears liability when an agent makes an unauthorized purchase, are still being worked out case by case rather than through settled precedent.
• Interoperability is not guaranteed. A merchant that only implements ACP can't accept an x402-native agent payment without a bridge. Right now, businesses building on one protocol are making a bet on which standard (or standards) win enough adoption to matter, similar to the early days of competing mobile wallet standards.
• Dispute resolution is underdeveloped. Chargebacks exist because human-initiated card transactions have decades of case law and network rules behind them. What a "chargeback" looks like when the disputed party is an autonomous agent acting on a mandate — was the mandate too broad, did the agent misinterpret it, was the merchant's product data wrong — doesn't yet have a standard process.
• Stablecoin volatility and custody risk apply to x402-style rails. Even with dollar-pegged stablecoins, wallet security, key management, and on/off-ramp friction remain real operational burdens for businesses not already comfortable with crypto infrastructure.
• Trust in agent judgment is still unproven at scale. Mandates constrain what an agent can spend, but not necessarily whether it's spending well — buying the objectively best option versus one that satisfies the letter of its instructions. That's a quality problem no payment protocol can fix on its own.

What to watch next

The next twelve to eighteen months will likely settle a few open questions that are currently just competitive positioning:

• Whether card networks formally endorse one mandate format. If Visa or Mastercard designates AP2-style mandates (or a competitor) as a recognized authorization method within their own rules, that's the moment agentic payments stops being an add-on and becomes part of the core rail.
• Whether merchants converge on ACP, build their own AP2 integration, or support both. Retailers don't want to maintain three separate checkout integrations for agent traffic; expect consolidation pressure or middleware vendors who abstract the difference away.
• How regulators respond to the first high-profile agent payment dispute. A widely reported case of an agent overspending or being manipulated via prompt injection into an unauthorized purchase would likely accelerate specific rulemaking faster than any amount of industry self-regulation.
• Whether x402-style micropayment volume keeps compounding or plateaus. The early transaction counts are a strong signal of developer interest, but the real test is whether machine-to-machine payment volume becomes a durable, recurring pattern in production systems rather than a burst tied to novelty and experimentation.

FAQ

What is an agentic payment protocol?

It's a technical standard that lets an AI agent initiate and complete a payment on a human's or business's behalf, using a cryptographically verifiable record of what was authorized. It adds a consent and identity layer on top of (or alongside) existing payment rails so every party in the transaction can confirm the agent stayed within its mandate.

What's the difference between AP2, x402, and ACP?

AP2 (Google) is a rail-agnostic mandate framework for proving consent across any payment method. x402 (Coinbase) is a stablecoin-based micropayment protocol built around the HTTP 402 status code, aimed at machine-to-machine transactions. ACP (OpenAI, with Stripe) focuses specifically on conversational checkout, letting a chat-based agent complete a retail purchase over existing card rails.

Can AI agents already make real purchases today?

Yes, in limited and increasingly common contexts — API metering through x402, chat-based checkout through ACP-integrated merchants, and mandate-based purchasing pilots using AP2. Broad, unrestricted agent spending across arbitrary merchants is not yet standard, but the underlying infrastructure to support it is in active production use.

Is agentic payment the same as giving an AI agent a credit card?

Not exactly. Giving an agent raw card credentials with no constraints would be reckless. These protocols instead issue scoped, auditable authorization — a mandate defining exactly what the agent can spend, on what, and under what conditions — which is a meaningfully different and more controllable arrangement than handing over a card number.

How do businesses protect against fraud from AI agent transactions?

By keeping mandates narrow (specific merchants, categories, and dollar caps rather than open-ended authorization), monitoring for aggregate spending patterns rather than only individual transaction size, and treating agent credentials with the same security rigor as API keys or payment credentials, since a compromised agent identity can transact at machine speed.

Will these protocols replace credit cards?

Not directly. AP2 and ACP are largely designed to work with existing card rails rather than replace them, while x402 offers an alternative rail better suited to very small, high-frequency payments where card interchange fees don't make sense. The more likely outcome is a layered system where different protocols handle different transaction types.

Which protocol should a business adopt first?

It depends on the use case: a retailer focused on conversational commerce should look at ACP, a company exposing metered APIs or data to other agents is a natural fit for x402, and a business that needs cross-platform, auditable purchasing authorization at any transaction size should evaluate AP2. Many businesses will end up supporting more than one as the market consolidates.

Teams evaluating where agentic payments fit into their own product or operations can get hands-on help scoping an implementation from Woyce Technologies.