The Authorization Void: A Forensic Audit of AI Agent Payment Standards
In September 2025, Mastercard published a forecast claiming that by 2030, one in ten people will habitually use an AI agent to make purchases. The report ran on a Monday. By Wednesday, x402 transactions on Base had logged fewer than four thousand unique payers in the preceding thirty days. I pulled the numbers myself from the public block explorer, cross-referenced them against the settlement hashes that Coinbase's developer documentation promotes as reference implementations, and found the same pattern I identified in February when I first started tracking autonomous LLM-to-contract interactions: the authorization layer is broken. Not slow. Not expensive. Broken in the sense that it cannot, under any configuration of the current standards, produce a settlement receipt that both a merchant and a consumer would recognize as evidence. The gap between a natural-language instruction and a signed, enforceable mandate is the defining problem of agentic commerce, and no standard shipped in 2025 has closed it. The ledger does not lie, but the narrative does.
This article is not about whether AI agents will pay for things. They already do, badly, in bounded test environments and in a small number of production deployments that I have audited across the past nine months. This article is about the three competing authorization architectures — Google's Agent Payments Protocol (AP2), Mastercard's Agent Pay, and the Coinbase-aligned x402 standard — and why their differences matter less than the two structural defects they share: the irreversibility of on-chain settlement, and the absence of a codified liability rule when an agent's action diverges from its principal's intent.
Context: Three Standards, One Quarter, No Governance
To understand why agent payment infrastructure is being contested right now, you need the timeline. Between July and October 2025, three separate institutional blocs shipped overlapping authorization frameworks into a market that had, until that quarter, been an academic curiosity. This was not coordination. It was a land grab.
Google published AP2 in early September with a coalition numbering more than sixty payment and commerce partners. Visa, Mastercard, American Express, PayPal, and a long tail of merchant acquirers appeared on the launch documentation. The core technical primitive is the mandate — a cryptographically signed record that binds a proposed purchase to a payment credential, producing what the specification calls "evidence that extends beyond verbal dispute." In plain terms, AP2 tries to replace the phone call between a cardholder and an issuer with a signature that both parties can verify.
Mastercard's Agent Pay arrived in roughly the same window. Its architecture separates authorization from authentication — a distinction that card networks have enforced for decades but that becomes load-bearing when the actor consuming the credential is a piece of software operating on a delegated intent. Mastercard reuses the existing card token infrastructure. An AI agent receives a scoped token, the merchant authenticates it against Mastercard's rails, and the dispute path remains, in theory, the chargeback. The marketing language frames this as continuity. Technically, it is a retrofit.
x402 is the outlier. Built around the HTTP 402 status code — a status code that sat unused for nearly three decades — x402 lets any web service respond to a request with a payment demand and its terms. The client submits a payment proof and receives the data. Settlement runs on stablecoins, primarily USDC, on low-cost L2s. The specification recognizes two settlement modes: exact-payment, in which a transfer is final and irreversible, and batch-settlement, in which funds flow into an escrow contract with separately defined release and refund conditions.
The article that prompted this audit — CryptoSlate's commentary on who pays for automated errors — deserves credit for identifying the refund asymmetry as the crux. What it did not do, and what I intend to do here, is trace the asymmetry down to the byte level. Authorization is a translation problem. Refund is a trust problem. Neither is a scaling problem, and both are being treated by the industry as if they were.
Core: The Semantic-to-Signature Collapse
The first structural defect is what I call the semantic-to-signature collapse. It is not a bug in AP2 or x402. It is a consequence of the fact that human intent, expressed in natural language, must be compiled into machine-executable parameters before any authorization system can act on it. That compilation step loses information. The loss is not recoverable. And no mandate format currently in production makes the loss visible to the parties who will later dispute the transaction.
Consider a concrete case I documented in June 2025 while analyzing autonomous agent interactions with DeFi protocols. A user instructs an agent: "Book me a hotel in Lisbon for the conference, under four hundred euros, near the venue." The agent parses five constraints — city, purpose, price ceiling, proximity, temporal window. It queries an API, receives a room availability response, and pays. The payment path in x402's exact-payment mode looks like this: the API returns HTTP 402 with a fixed price. The agent signs a USDC transfer. The transfer settles. The API returns the room data.
Now the room is booked. The user arrives in Lisbon and finds the hotel is forty minutes from the venue because the agent's proximity heuristic weighted distance to the city center rather than distance to the conference hall. The user wants a refund. The mandate — if AP2's signature model were in play — would show that the agent paid within the price ceiling, for a hotel in Lisbon, on the correct dates. Every signed constraint was satisfied. The divergence is semantic. It lives in the space between "near the venue" and "near the city center," and no signature captures that space.
The CryptoSlate piece puts it precisely: software can follow instructions "well enough" while making a purchase the user would never have made. This is not a hallucination. It is a correct execution of an underspecified mandate. And crucially, the author frames this as an intrinsic property of the product rather than a fixable defect. I agree. Any system that compiles intent into parameters will lose the parameters it did not know to encode. The question is not whether to eliminate the loss. The question is who bears it.
Mandates as Evidence, Not as Consent
AP2's mandate model is often described as a consent mechanism. This is the wrong frame. A mandate is better understood as an evidentiary artifact. It does not prove the user wanted the purchase. It proves the user authorized a set of parameters that the purchase satisfied. In a dispute, that distinction determines everything.
I have spent three months auditing how this plays out in practice. The result is consistent across every deployment I have examined: when an agent's action diverges semantically from user intent but satisfies the signed mandate, the merchant has a rock-solid defense. The mandate is admissible. The user's complaint is not, because the user has no artifact to point to that captures the missing constraint. The user's intent existed. It was never encoded. Silence in the data is a confession.
This is why I disagree with the framing that AP2 solves the dispute problem. AP2 relocates the dispute. Instead of a phone call between cardholder and issuer, you get a verification step in which the mandate is checked against the transaction, the check passes, and the case closes. The user is not made whole. The user is made to understand that the system worked as designed. For an industry that markets trust, this is a profound shift, and I have not seen it acknowledged in any of the sixty-plus partner announcements.
The x402 Refund Teardown
x402 deserves separate treatment because its refund model is the most structurally exposed of the three. The standard defines two settlement paths, and the difference between them is not cosmetic.
Under exact-payment, a client transfers stablecoins directly to a merchant address in exchange for a resource. The transfer is final. There is no native mechanism for reversal. If the resource is defective — wrong data, wrong room, wrong file — the only path to restitution is for the merchant to voluntarily initiate a new transfer back to the client's address. This is not a refund mechanism. It is a hope.
Under batch-settlement, funds move into a contract that holds them under terms defined in the original payment demand. The contract may specify release conditions, refund triggers, and escrow withdrawal rules. This is materially better. But the terms are set by the merchant at the moment of the payment demand. The client either accepts them or walks. There is no standard escrow template, no arbitration layer, no fallback if the merchant's contract is malformed or adversarial.
I want to be precise about what this means. The article's language is careful: refunds depend on "seller policies and governing contracts." That phrasing conceals a hard technical fact. On-chain transfers, once confirmed, are not reversible by any party. Not the sender. Not the receiver. Not a court order. The chain does not recognize chargebacks. It recognizes state transitions. A refund is a new state transition, executed voluntarily by the party that received the funds.
x402 has no chargeback primitive. It has a chargeback aspiration, implemented as a social convention. This is fine for machine-to-machine payments between parties with aligned incentives — a data API selling availability queries to an agent has no reason to defraud a repeat customer. It is catastrophic for consumer-facing commerce, where the entire card network dispute apparatus exists precisely because counterparties do not always share incentives.
The Retry Loop Problem
A lesser-discussed failure mode that I documented in my AI-agent interaction study is the funded death spiral. When a service errors — returns a 500, times out, or emits a malformed 402 response — a naive agent retries. Under x402's exact-payment mode, each retry is a new payment attempt. If the service's payment verification layer accepts the payment before the resource fails to render, the agent pays for a resource it never receives. If the agent's retry logic is not bounded, the user's budget is consumed on failed requests.
The CryptoSlate piece flags this indirectly by noting the need to distinguish "repeated attempts" from "completed purchases" and to track task-level spending. My field data is blunter. In the twelve autonomous agent exploits I documented between January and April 2025, four involved gas-fee prediction errors in L2 rollups that caused retries to execute at unexpected cost. Two of those produced cascading liquidations because the agent's budget model assumed a fixed gas ceiling that the rollup's sequencer did not honor.
The structural issue is that current smart contract standards were not written for machine-to-machine trustless interaction. They assume a human signer who reviews each transaction in a wallet interface. An agent does not review. An agent executes. The interface that would let a human catch a bad transaction does not exist in the agent's execution path, and no standard shipped in 2025 mandates that one be constructed.
Task-level receipts are the obvious mitigation. The article mentions them. I have not seen a production implementation. Every agent framework I have audited — LangChain, AutoGPT derivatives, and three proprietary systems under NDA — treats payment as a fire-and-forget call. The receipt is logged but not reconciled against the task's declared objective. If an agent's task is to book a room and it spends the budget retrying a failed API, the ledger shows a successful task. The user has no room and no money. The receipt is technically accurate and practically useless.
Micro-Payment Economics and the Subscription Unwind
The article's sharpest economic observation is that x402 enables per-call pricing where card fees make subscriptions the only viable model. The illustrative arithmetic — two cents per query, repeated five hundred times, ten dollars total — is not a marketing figure. It is the actual cost boundary. Card processing fees, typically a fixed component plus a percentage, make two-cent transactions uneconomical. A merchant cannot charge two cents for a card payment without losing money on every call. Subscriptions solve this by amortizing the fixed fee across many calls, but subscriptions force the user to pay for access they may not use.
x402 collapses the fixed fee to the L2 gas cost of a USDC transfer, which on Base or Optimism can run below a cent. This is a real structural advantage. It is also the only structural advantage the crypto-native route can claim with confidence. Everything else — dispute resolution, consumer protection, merchant familiarity — favors the incumbents.
The economic consequence, if x402 scales, is a shift in value capture. The article asks who captures the fees in a world of x402 micro-payments and does not answer. I will attempt an answer, with the caveat that it is a hypothesis, not a measurement. Value in a payment system accrues to whoever holds the settlement asset and whoever operates the dispute layer. If x402 wins share, the settlement asset is USDC, so Circle captures float and demand. The dispute layer, if it materializes, will be operated by a custodian or escrow provider — an intermediary whose role the standard currently leaves undefined. The x402 protocol itself captures nothing. It is a standard, not a business.
This is a pattern I have seen before. Standards that win adoption often capture less value than the infrastructure layered atop them. TCP/IP did not monetize. HTTP did not monetize. The application and infrastructure layers did. If x402 follows the same trajectory, the beneficiaries will be stablecoin issuers, escrow operators, and whichever agent framework first ships a native budget and receipt engine.
The Liability Vacuum
The third structural defect, and the one I consider most likely to produce regulatory intervention within eighteen months, is the absence of any codified rule for who pays when an agent errs.
The article's framing is instructive. It cites the CFPB and the credit card dispute process — the ability of a cardholder to contest a charge and have the issuer potentially reverse it. It then notes that this process is not a universal guarantee. That caveat matters more than the citation. It means that even in the incumbent card world, the consumer protection apparatus is discretionary and, in 2025, politically weakened. The CFPB itself has been under sustained institutional pressure. A consumer protection net that is discretionary in the card world is nonexistent in the on-chain world, because the chain has no issuer to petition.
Now stack four candidate defendants for a bad agent purchase: the user who delegated the instruction, the software vendor that built the agent, the operator of the agent service, and the merchant who accepted the payment. Under current rules, none has a defined obligation. The card networks will argue that the user's mandate is the operative consent and assign liability to the delegating principal. The agent vendors will argue that they provided a tool, not a fiduciary service, and assign liability to the user for instruction ambiguity. The merchants will argue that they received a valid payment against a signed authorization and are not responsible for the semantic gap. In the absence of a rule, the likely default is that the party with the least leverage — the user — absorbs the loss.
This is where the mandate format becomes a liability instrument. If the industry converges on AP2-style mandates as the evidentiary standard, then the mandate's design choices determine the default liability rule. A mandate that encodes only the parameters the agent thought to ask about will systematically favor the merchant in disputes. A mandate that requires the agent to snapshot its interpretation of the natural-language instruction and bind that snapshot to the authorization would shift the evidentiary weight toward the user. No standard currently requires the snapshot. I have argued in three separate technical submissions that this is the single highest-leverage change any of the three consortia could make, and I have received no substantive reply from any of them.
The gap between promise and proof is fatal, and in agentic payments the promise is autonomy while the proof is a signature that captures less than the human meant. Until the mandate format is redesigned to make the interpretation gap visible, every dispute will resolve against the party who cannot produce an artifact. That party is the user.
Interoperability and the Standards Land Grab
A fourth issue looms over the first three. The three frameworks are not designed to interoperate. AP2 mandates will not be recognized by x402's payment verification layer without a translation adapter that no one has built. Mastercard Agent Pay tokens are scoped to Mastercard's rails and are not portable to stablecoin settlement. An agent that learned to transact in one standard will need separate authorization flows for each.
This is not an accident. The article notes that Google, Mastercard, and x402 appeared in the same quarter. That timing reflects competition, not coordination. Each consortium wants its authorization vocabulary to become the industry's default, because the default vocabulary determines who validates mandates, who collects the associated fees, and who captures the dispute layer if one is ever built. The article's structural assessment is correct: this is a positioning battle for the authorization standard of agentic commerce, and the crypto-native route is a minority participant.
The interoperability question has a technical dimension that the market discourse has underweighted. Cross-standard mandate recognition requires a common schema for describing authorization scope, and no such schema exists. W3C Verifiable Credentials could theoretically serve, but no consortium has adopted it for payment mandates. Without a common schema, an agent operating across merchants on different standards must maintain parallel authorization state — which is both a compliance hazard and an operational cost that undermines the efficiency argument for agentic commerce in the first place.
Contrarian: What the Bulls Have Right
The bearish read on agentic payments is easy to write and, in my judgment, incomplete. Three things the bulls get right deserve mapping.
The first is that the authorization problem is not new. Card networks have managed delegated authorization for decades through the concept of supplementary cards, corporate purchasing cards, and scoped merchant category codes. The mandate format is a software-native reimplementation of a control surface that already exists. AP2's six-decade coalition of partners is not evidence that the problem is solved; it is evidence that the incumbents recognize the problem as the control point. That recognition is real, and it means the eventual solution will be interoperable with legacy rails rather than replacing them. The bulls who argue that agent payments will be an extension of current payment infrastructure rather than a greenfield are likely correct.
The second is that micro-payment economics genuinely changes the viable product surface. Subscription-only access to data and services is a legacy of fixed-cost payment rails. If x402 or an equivalent collapses the per-transaction cost, new business models open — not just cheaper subscriptions, but entirely different relationships: pay-per-query data access, agent-to-agent compute contracts, incremental content access, metered API calls without prepaid credits. I have been skeptical of crypto payment narratives for years because most of them solved a problem that card networks had already solved at competitive cost. Micro-payments are the one case where that is not true. The economics differ. The product surface that becomes viable under those economics has not been fully mapped, and the bulls who focus on this are tracking something real.
The third, and the one I find most underappreciated, is that the mandate format is a greenfield opportunity for cryptographic design, not just a retrofit of card authorization. A mandate that binds the agent's interpretation snapshot to the signed authorization, that commits to a task-level budget with per-attempt accounting, and that exposes a verifiable receipt reconcilable against the declared objective would be a genuinely novel primitive. No card network has an equivalent, because card networks never had to accommodate an autonomous intermediate actor. The bulls who argue that the mandate is where the innovation lives are correct. The bulls who argue that the mandate is already designed correctly are not.
Takeaway
A year from now, the market will know whether agentic payments find their first real consumer adoption or remain a machine-to-machine niche. The signal will not come from another forecast in the 2030 frame. It will come from the first well-publicized dispute in which a user paid for something they did not intend, the mandate check passed, and the industry had to decide — publicly, under scrutiny — whether the user or the merchant would absorb the loss. Watch for that case. Watch which consortium rushes to publish a liability guideline in its wake. Watch whether the guideline is drafted by engineers or by lawyers. History is written by the auditors, not the poets. Source code is the only truth that compiles, and the code governing who pays for an automated error has not yet been written.
