Agentic Commerce Payments

Agentic payments are the infrastructure that lets AI agents make purchases and other transactions on behalf of a person. The systems have to establish what an agent is allowed to spend, authenticate the agent, enforce spending limits, and determine who is responsible when a transaction goes wrong.

It splits into two separate questions, and each proposed approach answers them on its own terms. Who authorized the agent to spend. Who is liable when the purchase goes wrong. The rail itself is mature; the proposed approaches diverge on the first question and land closer to the same answer on the second.

Authorization: how does an agent prove it can spend?

When a person pays, the authorization is implicit... they are standing at the checkout. When an agent pays on someone's behalf, the system has to prove the agent was permitted to spend, and within what limits.

Two authorization models are emerging, and they answer that question in opposite ways. On the card rails, the credential is a tokenized, spend-limited payment method issued to the agent, never a raw card number. On the stablecoin side, the model inverts. In x402, the agent's wallet signature is itself the credential, so there is no stored card and no processor account to maintain. Both are trying to prove the same thing, that this agent was allowed to spend this much, through very different mechanics.

Tokenization is what makes delegating spend to software safe. A payment token is a surrogate for the real card number, scoped so it can be bound to one merchant, capped at an amount, limited in time, and revoked. The real card number never reaches the agent, so if the agent is compromised, the loss is capped at the token's scope rather than the whole account. Those controls sit at the execution layer, independent of the merchant, which is why the payments layer runs at low fraud even when the buyer is software.

Underneath either model sits an identity question: is this even a legitimate agent, and can it prove who it acts for? Proving a payment was authorized leans on the same verifiable agent identity that decides who gets through the door in the first place, which is the Know Your Agent (KYA) problem covered on the Readiness guide.

Liability: who carries the loss when a purchase goes wrong?

The second question is who carries the loss when an agent buys the wrong thing, buys fraudulently, or a chargeback lands. This is the merchant-of-record question. Across the payment approaches proposed so far, the merchant stays the merchant of record, so the merchant absorbs the cost even though the agent made the decision to buy.

No regulation defines whether a purchase an agent makes on its own counts as an "authorized transaction," and chargeback rights depend on that. The open question is what the shopper authorized: this specific purchase, or the general act of delegating shopping to an agent. If an agent buys the wrong item, whether that is a return, a chargeback, or the merchant's loss is not settled.

The emerging answer is a signed record of intent that travels with the transaction and shows the cardholder authorized this specific purchase. Google's AP2 calls it a mandate, Mastercard calls it Verifiable Intent, American Express calls it authenticated purchase intent. It is the same proof the authorization layer produces, reused to settle liability. The card issuers and networks are building it; the commerce protocols mostly leave liability alone. In April 2026, American Express went further and agreed to cover the cost directly, refunding wrong-item and unauthorized purchases made by registered agents that send it authenticated intent.

Agentic payment approaches

The named approaches diverge mostly on the authorization mechanism and converge on the same answer for liability. Compared side by side:

Each is described more fully below.

AP2 (Agent Payments Protocol). Google's payment-layer standard, built around mandates and verifiable credentials for agent-authorized payments.

x402. A payments approach that uses stablecoins and on-chain settlement to let agents pay programmatically, reviving the dormant HTTP 402 "Payment Required" status.

MPP (Machine Payments Protocol). Anthropic's open standard for machine-to-machine payments over HTTP 402, with Stripe and Tempo Labs as co-maintainers of SDKs. Broader than x402 in method: MPP supports stablecoins, Bitcoin Lightning, card networks, and others as payment methods, and covers one-time, metered, and recurring intents over HTTP headers, JSON-RPC, or WebSocket.

ACP payment handoff. The Agentic Commerce Protocol (OpenAI and Stripe) hands payment to processing partners, keeping the commerce flow and the payment flow separate.

The card networks. Visa Intelligent Commerce and Mastercard Agent Pay are the networks' own frameworks for authorizing and settling agent-initiated payments over existing rails.

What's settled, what's moving

Settled. The card rails themselves are the mature part. Tokenization, spend controls, and merchant-of-record mechanics are decades of existing infrastructure that agent payments largely reuse rather than reinvent. A tokenized, spend-limited credential is a known quantity, and the card networks are extending frameworks they already operate.

Moving. The parts still being decided are agent identity (whether a verifiable credential like KYA becomes standard, and on whose spec), the machine-payment protocol path (whether HTTP 402 approaches like x402 and MPP move past early adoption), and liability allocation when the buyer is software (which is more contested than the mechanics of moving the money).

Further reading

Related guides:

• Agentic Commerce Protocols ... the commerce layer that sits above payments (UCP, ACP, MCP, WebMCP).