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.

Quick answer: AP2 (Google) is a rail-agnostic mandate framework for proving consent on purchases of any size; x402 (Coinbase) is a stablecoin micropayment protocol for machine-to-machine transactions; ACP (OpenAI + Stripe) is built specifically for conversational retail checkout over existing card rails. Pick based on use case — metered APIs fit x402, retail chat commerce fits ACP, cross-platform purchasing authorization fits AP2 — and expect to support more than one as the market consolidates.

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.

That has direct implications for what a business needs to do differently starting now, not once the standards war settles.

Benefits of Agentic Payments Protocols

Agents can finish the job they started

Without a payment layer, an agent can research, compare, and fill a cart, then stall at the confirm button and wait for a person. Protocols that capture consent once and let the agent act inside that envelope remove the stall. The human still decides what is allowed; they just stop being a required click on every individual transaction. For workflows like routine reorders or travel inside a fixed policy, that turns an assistant that recommends into one that actually completes the task, which is where most of the time savings live.

Consent becomes provable after the fact

A signed mandate is a record that a merchant, bank, fraud team, or regulator can inspect later. That is a step up from today's card-not-present world, where proof of authorization often amounts to "the right card number was typed in." With AP2-style mandate chains, a dispute can be resolved by comparing what the human authorized against what the agent bought, line by line. Finance teams get an audit trail they can query rather than a pile of receipts to reverse-engineer.

Tiny payments finally make economic sense

Card interchange has a floor that makes charging a fraction of a cent per request pointless. x402 settles in stablecoins inside a single HTTP round trip, so an API, dataset, or web page can charge per call with no merchant account, contract, or monthly invoice in between. For developers selling tools to other agents, that opens pricing models that subscriptions had squeezed out, and it lets buyers pay only for what they actually use.

Existing rails keep working

AP2 and ACP are deliberately layered on top of the card networks, bank transfers, and processors that businesses already rely on. A merchant does not need to rebuild settlement, change acquirers, or adopt crypto to accept agent-initiated orders through these routes. The novelty sits in the authorization and checkout handoff, which keeps adoption cost closer to an integration project than a payments migration.

Narrow authorization limits the blast radius

Because spend rules are expressed as data (merchant allowlists, category limits, per-period caps), a confused or manipulated agent can only do as much damage as its mandate allows. That is a structural safeguard rather than a hope that the model behaves. It also gives security teams something concrete to review: the mandate is the policy, and it can be versioned and tested like any other configuration.

Agentic Payments Use Cases

Metered API and data access

A developer building an agent that calls third-party tools faces a familiar problem: every provider wants an account, a card on file, and a subscription tier sized for humans. With x402, the provider returns a 402 response and a price, the agent's wallet pays in stablecoin, and the data comes back in the same round trip. The outcome is pay-per-call access with no onboarding friction, which is where much of x402's early transaction volume has come from.

Conversational retail checkout

Shoppers increasingly ask a chat assistant to find a product rather than browsing a storefront. ACP lets that assistant build a cart from the merchant's structured catalog and complete checkout over the buyer's stored card credentials through Stripe. The merchant keeps its merchant-of-record relationship and existing payment setup, and the user gets an order confirmation inside the conversation instead of being bounced to a web checkout to finish the purchase.

Policy-bound travel booking

Travel is a natural fit for mandate-based purchasing because the rules are already written down: fare caps, preferred carriers, departure windows. An AP2 Intent Mandate captures those rules, the agent searches and proposes a specific itinerary as a Cart Mandate, and payment runs over whatever rail the airline or agency already accepts. The traveller approves the intent once; the audit trail shows exactly which fare was booked and why it fit.

Routine business procurement

SaaS seat top-ups, usage-based cloud charges, and recurring supplier reorders involve little judgment but plenty of admin. Teams piloting agentic purchasing start here: a mandate scoped to an allowlist of vendors and a monthly cap, with human confirmation kept on above a threshold. The result is fewer purchase requests sitting in someone's inbox, and a cleaner reconciliation trail than ad-hoc corporate card use.

Paid content access for crawlers and agents

Publishers that block AI crawlers lose a potential revenue source; publishers that allow them get nothing back. The HTTP 402 pattern lets a site quote a price per page and serve content once payment clears. It is still early, but it offers a mechanism for agents to pay for what they read rather than scraping it for free or being shut out entirely.

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.

Getting started: a phased rollout

If you're a builder or operator who wants to move beyond reading about agentic payments, a staged approach keeps the risk proportional to what you've learned.

Step 1: Map your agent-adjacent transactions

List the purchases and charges that already happen with little human judgment: SaaS seat top-ups, API usage, routine supplier reorders, travel within a fixed policy. These are the candidates. Anything that needs negotiation or subjective evaluation stays human-led for now.

Step 2: Write the mandate before the code

For each candidate, define the spend policy as data: merchant allowlist, category, per-transaction cap, per-period cap, and who gets notified. If you can't express the rule this precisely, the agent shouldn't be spending on it yet.

Step 3: Pilot one protocol on one flow

Pick the protocol that matches the transaction shape (see the table above) and run it on a single low-value flow, with human confirmation still enabled. Log every mandate, cart, and receipt so finance can reconcile them against statements. Our guide to AI agent security covers how to scope the credentials an agent holds during a pilot like this.

Step 4: Remove confirmation only where the logs earn it

After a few weeks of clean reconciliation, drop the confirmation step for the lowest-risk tier and keep it for everything else. Expanding autonomy should be a decision backed by data, not a default.

Common Agentic Payments Mistakes

Writing broad mandates to save setup time

"Handle office procurement" feels efficient to configure and is a gift to anyone who compromises the agent's context. Broad intent gives the agent room to justify almost any purchase as in scope, and it gives a dispute process nothing precise to check against. The few extra minutes spent listing merchants, categories, and caps are the cheapest security control in the whole stack.

Watching only for large transactions

Existing fraud tooling is tuned to flag big, unusual charges. Agent failures tend to look different: a long run of small, plausible purchases that only stand out when you add them up. Teams that rely solely on per-transaction thresholds miss this drift until the monthly statement arrives. Aggregate monitoring per mandate, merchant, and time window has to be added deliberately.

Treating agent credentials like a convenience token

An agent's wallet key or payment credential is a payment method that can be used at machine speed. Storing it in a prompt, a shared config file, or a long-lived environment variable without rotation puts real money one leak away from loss. These credentials need the same handling as production API keys or card data: scoped, rotated, and revocable in minutes.

Betting everything on one protocol

The market is still settling, and a merchant that only speaks ACP cannot accept an x402-native agent payment without a bridge. Hard-wiring one protocol deep into checkout code makes it expensive to add a second later. Keeping the protocol behind an internal interface costs little now and keeps options open as standards consolidate.

Removing human confirmation on a schedule

Some teams plan to drop the confirmation step after a fixed pilot period regardless of what the logs show. Autonomy should expand only when reconciliation has been clean and the failure modes are understood, and only for the lowest-risk tier first. A calendar date is not evidence that the agent is spending well.

Agentic Payments Best Practices

• Express every spend policy as a machine-readable mandate. Include a merchant allowlist, category, per-transaction cap, per-period cap, and a named owner who is notified. If a rule cannot be written that precisely, keep a human in the loop for it.
• Prefer itemized authorization at the point of purchase. Use Cart Mandate-style approval that names the exact items, price, and merchant, so ambiguity is closed before money moves rather than investigated afterwards.
• Match the protocol to the transaction shape. Use x402 for metered machine-to-machine calls, ACP for conversational retail checkout, and AP2 where you need portable, auditable consent across rails and transaction sizes.
• Isolate and rotate agent credentials. Give each agent its own identity and wallet or payment credential, scope it to the mandate, and make revocation a one-step operation that has been tested before you need it.
• Feed receipts into finance systems from day one. Mandates, carts, and settlement receipts should land somewhere finance can query alongside card statements, so reconciliation is routine instead of a forensic exercise.
• Monitor aggregates, not just individual charges. Alert on spend velocity, repeated small purchases, and new merchants per mandate, which is where drift and prompt-injection abuse tend to show up first.
• Test the agent against manipulation before it can pay. Feed it poisoned product data and injected instructions in a sandbox and confirm the mandate holds. A payment protocol constrains spending; it does not stop an agent from being talked into a bad but technically allowed purchase.
• Abstract the protocol layer. Wrap whichever protocol you start with behind an internal payments interface so adding a second standard, or swapping one, does not mean rewriting checkout.
• Publish agent-readable product data if you sell. Expose price, availability, and variants in structured form rather than burying them in client-rendered widgets, so agent buyers can parse your catalog reliably and quote the right numbers back to their users.

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.

For the identity layer these mandates depend on, see our explainer on non-human identity. Teams evaluating where agentic payments fit into their own product or operations can get hands-on help scoping an implementation from Woyce Technologies.

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. In practice, most live deployments today keep a human approval step for anything above a small threshold.

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.

Do small businesses need to care about agentic payments yet?

Most small businesses don't need to build anything today, but they should make sure their storefront exposes clean, structured product data and that their payment processor has a stated plan for agent-initiated transactions. If you sell through Stripe or a major commerce platform, ACP-style support is likely to arrive as a configuration option rather than a custom build. The more useful step now is writing down which purchases you would ever let an agent make on your behalf, and with what limits.

Key Takeaways

If you're scoping agentic payments today, prioritize these three moves:

1. Match the protocol to the transaction shape. Metered APIs and machine-to-machine calls fit x402; conversational retail checkout fits ACP; cross-platform authorization at any size fits AP2.
2. Write spend policy as machine-readable mandates, not internal guidelines. "Book a flight under $450" is enforceable; "handle my travel" isn't — narrow, itemized mandates also shrink the blast radius if an agent's reasoning goes wrong upstream.
3. Monitor for drift, not just large transactions. Existing fraud detection already catches big anomalous charges; the real risk is many small, individually plausible purchases that only look wrong in aggregate.

Conclusion

The bottleneck for useful AI agents has rarely been reasoning; it has been the moment money needs to move and a human has to step back in. AP2, x402, and ACP each attack a different slice of that problem: proving consent across any rail, paying for machine-to-machine services in fractions of a cent, and completing a familiar retail checkout from inside a conversation. They overlap, but none replaces the others, so most serious deployments will end up speaking more than one.

What matters more than which protocol wins is how tightly authorization is scoped. Narrow, itemized mandates contain the damage when an agent is confused or manipulated, and audit trails turn agent spending into something finance and compliance teams can actually reconcile. The open issues are real: liability rules, dispute handling, and cross-protocol interoperability are still being worked out, so early adopters should keep humans in the loop above modest thresholds.

The practical next step is small: pick one repetitive, low-value transaction, write its spend policy as a machine-readable mandate, and pilot it with logging switched on. If you want help designing the agent and authorization layer around that pilot, our AI agent development team can work through it with you.