AI Agent Payments in 2026:The Protocols, the Liability Gap, and What to Build

For most of 2024 and 2025, an AI agent's relationship to a purchase ended at a link. It could compare flights, draft a cart, or explain why one hotel beat another on price, but the actual charge required a person to click a button on a checkout page a human built for humans. That boundary moved in the back half of 2025 and through 2026, and it moved because five separate organizations built the infrastructure to cross it at roughly the same time.

Google announced the Agent Payments Protocol (AP2) on September 16, 2025, with more than sixty launch partners spanning card networks, payment processors, and stablecoin infrastructure. Thirteen days later, OpenAI and Stripe released the Agentic Commerce Protocol (ACP) to power in-chat purchasing directly inside ChatGPT. Visa and Mastercard each announced their own agent-facing protocols the same September. And Coinbase's x402 — open-sourced back in May 2025 for a different problem, machine-to-machine micropayments — was formalized under the Linux Foundation in April 2026 with support from more than twenty organizations including several of the same card networks and processors building the consumer-facing protocols.

This guide is written for the operator deciding whether, and how, to let an agent transact on their behalf or on their customers' behalf — not for a payments engineer already deep in any one protocol's spec. It covers what each protocol actually does, how to choose between them, and — because this is the part most vendor material skips — who is actually on the hook when an agent gets a purchase wrong.

Before comparing payment protocols specifically, it helps to place them against the two agent protocols most already sit on top of. The Model Context Protocol (MCP) governs how an agent discovers and calls tools — a database lookup, a search API, a booking system. The Agent2Agent protocol (A2A), which Google announced on April 9, 2025 and donated to the Linux Foundation on June 23, 2025, governs how independently built agents discover each other and coordinate a task across vendor boundaries; it now has more than 150 supporting organizations as of its first anniversary in April 2026.

AP2 is explicit that it is not a replacement for either — Google's own announcement describes it as extending both A2A and MCP specifically to answer a question neither protocol was built to answer: proving that a user actually authorized a specific payment, to a specific party, for a specific amount. That framing matters practically, because it means AP2 adoption is not an alternative to adopting MCP or A2A — a production agent that already speaks either protocol has less integration work ahead of it than one starting from nothing.

If you are earlier in the decision of how your agent should discover and call tools at all, our Model Context Protocol guide covers that foundational layer directly. This article assumes that groundwork exists, or is being built alongside payment capability, and focuses specifically on the payment-authorization layer sitting on top of it.

AP2's central mechanism is the Mandate — a cryptographically signed digital contract, built on verifiable credentials, that stands in for a specific, provable claim about what a user actually authorized. There are three, and they exist specifically so a later dispute has a concrete, signed record to point to at each stage rather than one opaque "the agent bought it" log line.

• Intent Mandate: Captures the user's original request and any constraints they set up front — a price ceiling, a timing window, a category restriction — before the agent does anything. For a delegated, unattended task, this is the document that defines the agent's actual authority.
• Cart Mandate: Generated once the agent has assembled specific items at a specific price. It locks that exact cart as an unchangeable record, so what the user (or a pre-authorized rule) approves is precisely what gets charged — not a total that can drift after approval.
• Payment Mandate: Links the approved Cart Mandate to an actual payment method and completes the chain from stated intent through to the finished charge, closing the non-repudiable audit trail Google's own documentation describes as the protocol's core purpose.

AP2's April 2026 v0.2.0 release added "Human Not Present" payments — transactions completed with no person actively watching at the moment of purchase, governed entirely by the constraints already locked into an Intent Mandate. Google's own example is an agent buying a limited-release ticket the instant it goes on sale, faster than a person could act manually. It is a real, specified capability, not a hypothetical one — which is exactly why the liability section later in this guide matters: a Human-Not-Present purchase is, by design, one where nobody had a last chance to say no in the moment.

In April 2026, Google donated AP2 to the FIDO Alliance — the same standards body behind passkeys — moving its governance from a single-vendor protocol to a community-led one, with Mastercard among the organizations contributing alongside Google to the transition. That governance shift is worth tracking for any operator evaluating AP2's long-term stability: a protocol under neutral standards-body governance carries different vendor-lock-in risk than one a single company can unilaterally redirect.

Where AP2 is built as a payment-network-agnostic authorization layer, the Agentic Commerce Protocol takes a narrower, more checkout-specific approach: it defines a shared interaction model — cart management, a product feed, order status, capability negotiation, delegated payment tokens, and authentication — specifically so a business does not have to build a bespoke integration for every AI shopping agent that might send it a customer.

OpenAI and Stripe released ACP on September 29, 2025 under an Apache 2.0 license, with Stripe and OpenAI as founding maintainers of the public GitHub specification. It uses date-based versioning rather than semantic versioning; its latest stable snapshot as of this writing is dated 2026-04-17, which added cart, feed, orders, authentication, and Model Context Protocol compatibility on top of the initial release. It currently powers ChatGPT's Instant Checkout, where U.S. ChatGPT users can complete purchases from Etsy sellers directly inside the chat, with Shopify's roughly one million merchants rolling in as the next major expansion.

Visa and Mastercard did not wait to see whether AP2 or ACP would become the default agent-payment layer — both moved to give an agent a credential their own network can recognize and authorize directly, at the network level rather than the application layer.

Visa's Trusted Agent Protocol, announced in September 2025, issues a Verified Agent ID that merchants can check against a Visa-operated directory, alongside a separate consent record signed by the consumer's own card issuer — giving a merchant a way to distinguish a legitimate, consumer-authorized agent from a bot attempting to impersonate one. On June 10, 2026, at the Visa Payments Forum, Visa announced a deeper partnership with OpenAI specifically, so that tokenized Visa credentials can power agent-initiated checkout inside ChatGPT and Codex with spending limits enforced before any payment is authorized.

Mastercard launched Agent Pay in 2025, built around Agentic Tokens — credentials that let an agent pay via card, bank link, or stablecoin under explicit credentialing and spend limits. On the same day as Visa's OpenAI announcement — June 10, 2026 — Mastercard launched Agent Pay for Machines, extending the program to high-frequency, low-value, machine-speed payments with more than thirty initial participants including Adyen, Cloudflare, Coinbase, and Stripe — a notable detail, since it means several of the other protocols in this guide are also Agent Pay for Machines participants rather than pure competitors.

For an operator already built on card-network rails, the appeal of either network's own protocol is straightforward: agent-initiated transactions inherit the fraud tooling, dispute infrastructure, and merchant relationships that already exist, rather than requiring a parallel system built around a newer, less battle-tested authorization layer.

x402 solves a different problem than the four protocols above, and conflating it with them is the most common mistake we see operators make. AP2, ACP, and the card networks' own protocols are all built for a consumer-facing purchase — an agent buying something on a person's behalf, with a person's authorization behind it. x402 is built for machine-to-machine commerce with no consumer checkout at all: an agent paying a few cents for an API call, a dataset, or a compute resource, settled instantly and without an account.

Coinbase open-sourced x402 on May 6, 2025, reviving the long-dormant HTTP 402 "Payment Required" status code: when an agent requests a resource that costs money, the server responds with a 402 and payment instructions, the agent signs a stablecoin transaction — typically USDC on the Base network — and retries the request with proof of payment attached. Settlement happens in seconds, at a cost Coinbase describes as a fraction of a cent per transaction, with no subscription or account required on either side.

Coinbase and Cloudflare announced the x402 Foundation on September 23, 2025, and the Linux Foundation formalized it as an open-governance project on April 2, 2026, with more than twenty member organizations including AWS, Cloudflare, Anthropic, Circle, Google, Microsoft, and Visa. Coinbase has reported adoption figures at more than one point in 2026 — roughly 165 million transactions across some 69,000 active agents by late April 2026, and a higher cumulative figure later in the year — and we cite these as Coinbase's own self-reported operational metrics, not as independently audited numbers.

With five protocols occupying overlapping but distinct territory, the comparison that actually matters is not "which is best" but "which layer does each one own."

Translated into an actual decision, most operators should start from where their customers already are, not from which protocol is technically most complete.

Two claims worth scrutinizing before they factor into a build decision — a full red-flags table follows the liability and regulatory sections below, but the two most common ones belong here: a vendor's adoption or transaction-volume figure with no stated measurement date, and a compliance claim ("PCI compliant," "fully protected") with no stated scope. Both patterns recur across every protocol in this guide, not just one.

This is the question every operator building on any of these protocols actually needs answered, and it is the one with the least settled answer. As of September 2026, no government body has established a general rule for who is liable when an AI agent makes an unauthorized, mistaken, or fraud-induced purchase. What exists instead is a set of company-specific commitments, each narrower than its headline suggests.

American Express is the most concrete example. Its Agentic Commerce Experiences (ACE) developer kit, announced in mid-April 2026 alongside a commitment called Agent Purchase Protection, is real and worth understanding precisely — because "Amex protects agent purchases" is not quite what it says. The protection applies specifically to purchases where a registered agent sent Amex an authenticated purchase intent afterthe cardholder had already authorized that specific agent to transact on the network's controlled, credentialed environment. It is not a blanket guarantee against every AI-agent purchase gone wrong — a purchase made outside that authorization chain, or through an unregistered agent, falls outside the stated scope.

Visa's Trusted Agent Protocol and Mastercard's Agentic Tokens both work toward the same underlying goal from the network side: giving a merchant a cryptographically verifiable record of whether a legitimate, consumer-authorized agent was actually behind a given transaction. That record shapes who is likely to prevail in a dispute — a merchant with a verified Trusted Agent Protocol credential on file has a materially stronger position than one without — without itself constituting a liability rule any court or regulator has endorsed.

The practical upshot for an operator: outside of company-specific commitments like Amex's, the general dispute rights that already exist under card-network rules still apply to the underlying charge, but none of those rules were written with an autonomous agent's mandate in mind. Building your own liability and escalation policy in writing, before launch — not discovering your position during the first real customer dispute — is the actual mitigation available today, and it is covered concretely in the blueprint section below.

Getting the precise regulatory status right matters more here than in most technical guides, because "filed," "proposed," and "in force" carry genuinely different obligations — and this specific topic invites conflating them.

The most consequential U.S. federal development is Senator Mark Warner's discussion draft of the Artificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer Act of 2026 — the "AI AGENT Act" — released June 29, 2026. A discussion draft is explicitly a pre-legislative step meant to solicit stakeholder feedback; as of this writing it has not been formally introduced as a bill, let alone passed a committee vote. Its four described components — letting users delegate platform access to a registered agent, interoperability obligations on large platforms, non-waivable fiduciary-style duties on agent providers, and an FTC-administered agent-provider registration framework — describe where federal thinking is heading, not a current legal requirement.

On standards rather than law, NIST's Center for AI Standards and Innovation (CAISI) launched an AI Agent Standards Initiative on February 17, 2026 — the first dedicated federal effort targeting autonomous-agent standards specifically, organized around industry-led standards work, community-led open-source protocol development, and foundational identity and security research. It is not payments-specific; its scope is agent identity, authorization, and security generally. Separately, NIST's existing AI Risk Management Framework already includes general provisions relevant to any autonomous system — MANAGE 2.4 (mechanisms to deactivate a system departing from its intended use) and MANAGE 4.1 (monitoring, override, and incident response) — which is the accurate source for "NIST has relevant guidance," rather than any agent-payment-specific kill-switch rule.

The one binding, currently-in-force standard directly touching this topic is payments-industry self-regulation rather than government rule: the PCI Security Standards Council's AI Principles, covered in full in the next section, which are guidance rather than a certification requirement but which sit on top of PCI DSS itself — a standard merchants handling card data are already contractually bound to.

Every protocol in this guide is, at its core, a way to avoid handing an AI agent a real card number. That is not incidental — it is the specific, stated recommendation from the body that actually governs card-data security.

The PCI Security Standards Council published AI Principles: Securing the Use of AI in Payment Environments in September 2025, stating that AI systems — including agentic ones with a genuine level of autonomy — must be deployed and managed in full compliance with applicable PCI DSS requirements regardless of their autonomous characteristics, and that using AI does not remove or bypass the need to meet any applicable PCI SSC standard for how data is secured in storage, processing, or transmission. Its guidance goes further for agents specifically: they should not operate on or have access to raw card information at all — a non-sensitive token, or a network token, is the correct instrument for an agent to hold.

This is precisely what every protocol covered above already does structurally. AP2's Payment Mandates link an approved cart to a payment method without the agent itself handling a raw PAN. ACP's delegated payment tokens work the same way through Stripe's existing tokenization. Visa's Trusted Agent Protocol and Mastercard's Agentic Tokens are, by name, token-based credentials rather than raw card access. An operator evaluating whether their own build is compliant should be asking a narrower, more specific question than "are we PCI compliant" — namely, whether the agent's own execution context can ever reach a system capable of de-tokenizing back to a real card number, and how that de-tokenization capability is isolated from everything the agent touches.

This is the same architectural discipline — scoping a credential to the narrowest capability an agent actually needs, and isolating anything more sensitive behind a boundary the agent cannot reach — that we cover in full, beyond the payments-specific case, in our AI agent sandboxing and credential scoping guide. A payment credential is simply the highest-stakes instance of a general problem: an agent that reads untrusted content (a merchant listing, an email, a web page) before making a decision is a live prompt-injection surface, a topic we cover directly in our OWASP LLM Top 10 guide — and the mitigation there is the same one that applies here: never let the context that reads untrusted input be the same context that holds an unconstrained payment credential.

Frenchy Digital's own Beyond Points AI build is a concrete, published example of the confirmation-gated posture this guide recommends, in a product that genuinely touches real money and real loyalty balances rather than a hypothetical scenario. Its Claude-based orchestrator delegates to specialized loyalty, transfer, browser, flight-booking, and hotel-booking sub-agents through the Model Context Protocol, and it automates point transfers end to end through a browser-agent bridge — but every irreversible action in the product, named explicitly in the build's own feature list, sits behind an explicit user checkpoint: transfers, bookings, payments, and cancellations never execute without a confirmation gate.

The build's own "problems worth talking about" section is equally instructive for this specific topic: during a vendor de-risking pass, Duffel, Bright Data, Amadeus, Plaid, and Stripe were all removed and re-sourced with a documented capability matrix specifying what each remaining provider can and cannot actually return. That is the same instinct this guide is arguing for at the protocol layer — know precisely what each vendor or protocol integration actually gives you, in writing, rather than assuming broad coverage from a vendor relationship.

Generalizing from that build into a build order for any operator adding agent payment capability:

The order matters for the same reason it did in Beyond Points AI's own build: skipping straight to "Human Not Present" autonomy before you have logged, reviewable evidence that an agent's judgment holds up is the single most common way a payments-agent project turns into an incident rather than a feature. "Logged, reviewable evidence" is not a throwaway phrase — it means the same eval-set, pass-rate, and cost-aware measurement discipline we cover in full in our AI agent evaluation and observability guide, applied specifically to payment-authorization decisions rather than treated as a separate, payments-only concern.

Agentic-payments work scopes the same way the rest of our agent-architecture work does: a discovery phase that maps your actual protocol needs before any code changes, a single-workflow build for a first, well-scoped payment flow, a platform build for operators supporting several rails, and an enterprise band for organizations with real regulatory exposure.

Senior-led delivery runs $150 to $225 per hour, retainers run $2,500 to $9,500 per month, and every engagement carries a 30-day post-launch warranty. Book a discovery call at calendly.com/frenchydigital/discovery-call or call +1 (424) 272-5601, and you receive a written, fixed-price phased proposal within five business days.

A short, consolidated list worth checking against any protocol, vendor, or integration partner pitch in this space, gathered from the specific claims this guide had to verify or refuse above.

This guide is explicit about where its own verification stopped. We could not confirm the specific CFPB advisory on agent-payment liability that circulates in secondary commentary — we are treating that as unconfirmed rather than repeating it, and we would update this section if we later locate the actual document. We did not independently audit any protocol's own reported adoption figures (AP2's launch-partner count, A2A's supporting-organization count, or x402's transaction volume) — these are reported here as the organizations' own published claims, attributed as such, not as figures we verified against underlying transaction data.

We also did not test any protocol's implementation directly — everything here describes what each protocol's own documentation and named press coverage states it does, not our own hands-on integration experience with AP2, ACP, or either card network's protocol specifically. Our own direct build experience cited in this guide, the Beyond Points AI case study, uses MCP-based agent orchestration and confirmation-gated payment actions, but does not itself integrate AP2, ACP, or a card network's agent protocol — it is offered here as an example of the confirmation-gate architecture and vendor-scoping discipline this guide recommends, not as a case study of any specific protocol covered above.

Finally, this is a genuinely fast-moving area — five protocols each shipped meaningful updates within the twelve months before this guide was written, and the liability and regulatory landscape it describes is explicitly unsettled rather than final. A reader making a real build decision should treat every date and status claim here as current as of September 2026, and verify anything regulatory or protocol-version-specific directly before it factors into a compliance timeline.