Agentic commerce chargeback liability: who pays when an AI agent buys wrong

The news: agentic commerce is building an evidence layer because it doesn't have one

On July 13, 2026, a company called A-Comm Technologies opened public comment on a draft standard almost nobody outside payments noticed, and it says more about the state of agent commerce than most of this year's product launches. The A-Comm Evidence Protocol is an open-source, Apache-2.0 licensed specification for recording what an AI agent did during a transaction — from discovery through fulfilment — in a tamper-evident form that any party can export and independently verify. Public comment runs through August 14, 2026.

Read the founding team and it stops looking like a side project. A-Comm was founded by former Visa payments leaders, with angel backing from executives at Visa, Mastercard, American Express, SoFi, Citigroup, Wells Fargo and Qualcomm. Its CEO, Krystal Gracier, framed the problem plainly: "For agentic commerce to scale, it needs to be observable, traceable, and auditable. No single company can build an ecosystem of trust on its own."

The same announcement cites Salesforce crediting AI with influencing 20% of global online sales in 2025, and expects agent-initiated transactions to reach real payment scale during peak retail season — the stretch that produces roughly 19% of annual retailer revenue.

Here's the part worth sitting with. Human checkout never needed an evidence protocol. Nobody proposed a standard for proving a person clicked "buy." The reason one is being drafted now is that when a buyer is software, the entire chain of proof that card disputes run on quietly stops working — and the industry knows it.

What a disputed agent purchase costs a merchant today

Start with the mechanics of a normal chargeback. A cardholder disputes a charge, the issuer asks the merchant for compelling evidence, and the merchant produces the digital exhaust of a human session: IP address, device fingerprint, navigation path, time on site, delivery confirmation. That package is what convinces an issuer that this person, on this device, made this purchase.

Now delegate the purchase to an agent. Every one of those signals is generated by the agent's infrastructure rather than by the customer, while the issuer still expects a clean link between the cardholder and the transaction. The merchant is asked to prove something the new architecture no longer records.

Underneath sits an unresolved legal question: was the transaction authorised? If a consumer tells an agent "find the best deal on running shoes and buy it" and it buys the wrong pair, US dispute practice has no settled answer on whether the consumer authorised that purchase — and the entire dispute process turns on that single word. As of 2026, no jurisdiction has enacted rules written specifically for autonomous purchasing.

The industry doesn't agree on who should pay, either. Surveys circulated by dispute-management firms put roughly 39% of respondents on the AI provider, 20% on the customer, 14% on the merchant or platform, 11% on the bank or processor, and 15% on some shared model. When opinion splits that evenly, it means the framework is still being written — and in the meantime, absent a network-specific protection, liability tends to default to the merchant. Datos Insights projects global chargeback volume rising about 24% between 2025 and 2028, to roughly 324 million disputes a year, and agentic volume lands on top of that, not instead of it.

Networks are moving, but partially. American Express introduced an agentic developer kit in early 2026 with a commitment to cover erroneous purchases made by registered agents on its network. Visa's Trusted Agent Protocol and Mastercard's Agent Pay both build agent identity frameworks. Those address who the agent is and how it behaves at authorisation — not what happens weeks later when someone contests the charge.

Regulators, meanwhile, have already picked a side on responsibility. The UK's Competition and Markets Authority published guidance on March 9, 2026 stating that consumer law applies whether a customer deals with a person or an AI agent, that businesses are responsible for their agents' conduct as they are for employees, and that this holds even when a third party supplied or designed the system. Under the DMCC Act, breaches can carry fines of up to 10% of worldwide turnover. Its blunt formulation: "if an AI agent you use does something illegal, you are responsible."

Why card rails can't produce this evidence on their own

It's tempting to read the evidence gap as an engineering oversight — logs someone forgot to write. It isn't. It's the direct consequence of how card payments work.

A card authorisation is a promise, not a fact. The money moves days later, and for months afterwards it can move back. That reversibility is the product: it's what let strangers transact online before there was any way to settle value with finality. But a promise has to be adjudicated, and adjudication needs evidence. So the card system grew an enormous apparatus — representments, compelling-evidence rules, liability shifts, dispute windows — whose entire job is reconstructing, after the fact, whether a payment should stand.

That apparatus rests on one assumption: a human authorised the payment, and traces of that human exist. Insert an autonomous third party between the human and the checkout, and the assumption fails. The response — an evidence protocol, agent registries, trusted-agent frameworks — is an attempt to rebuild the missing proof alongside a rail that structurally cannot generate it. Dispute-management specialists have been direct about the gap: the networks are shipping identity frameworks and live pilots, while the post-transaction plumbing for assigning liability without a human buyer remains almost entirely unaddressed.

Now look at the same transaction on a payment rail with settlement finality. An agent pays USDC on Base for one API call. The payment either happened or it didn't. It settled into a wallet the merchant controls, in about two seconds, and it left a public, timestamped, cryptographically signed record showing exactly which address paid what amount to which address, for which request. Nobody has to reconstruct intent months later, because nothing can be un-done months later.

That is not a claim that on-chain payments answer every question a standard like AEP is tackling. Whether the agent bought the right thing is a product and consent question, and it deserves the work being done on it. But the specific problem that costs merchants money — a settled payment being pulled back, and the merchant having to prove a negative about a buyer who was never human — simply doesn't arise. We've made the same structural argument about recurring payments that die by dispute and about virtual cards issued to agents: putting an agent behind a reversible instrument inherits every problem of the instrument.

How Payzum handles it: the payment is the receipt

Payzum is a non-custodial, crypto-only payment processor. Funds go straight to wallets the merchant controls — Payzum never holds, pools or moves them. That single design choice does most of the work in this discussion, and it's worth spelling out what it means for agent payments specifically.

Finality replaces adjudication. When an agent pays for one of your API calls in USDC on Base, the payment is on-chain and settled. There is no dispute window, no representment cycle, no compelling-evidence package to assemble, and no issuer deciding months later whether your business keeps the money. Refunds remain entirely possible — you send funds back when you judge that's right — but they're your commercial decision, not a reversal imposed on you.

The settlement is independently verifiable. This is the quiet overlap with what the evidence-standard work is chasing. An on-chain payment is observable (it exists in a public ledger), traceable (a specific payer address funded a specific request at a specific block) and auditable by any party without asking a network or a processor for permission. Payzum doesn't implement AEP, and no one should claim on-chain settlement resolves everything the standard covers — but the merchant-side proof problem, "can you show this payment happened and wasn't reversed," is answered by the rail itself.

Your own audit layer sits on top. Payzum ships signed webhooks, API keys, encrypted secrets, 2FA and a complete audit log, so the record inside your systems lines up with the record on-chain. For reconciliation and internal controls, that pairing — a signed event you received plus a transaction anyone can look up — is a stronger trail than what most card integrations produce.

And the volatility question has a boring answer. Auto-conversion to USDC or USDT is optional, so an agent's payment can land as a dollar-denominated stablecoin rather than something that moves overnight.

One point of precision we insist on, because the ecosystem gets it wrong constantly: in x402, Payzum is the middleware/proxy in front of your API — not the facilitator. Payment settlement runs through an external facilitator (today, Coinbase's). Payzum publishes the x402 URL, returns the 402, and once the payment settles to your wallet, proxies the paid call to your real endpoint using your key. The protocol was contributed to the Linux Foundation's x402 Foundation, and independent adoption data — Chainalysis has tracked agentic payments on Base crossing 100 million transactions — is public, which is itself the point: this is an open rail, not a private ledger.

How you'd actually set this up

1. Configure, don't code. In the Payzum dashboard you point to your existing endpoint, paste the API key or bearer token it already expects, and set a price per call. There's no protocol to implement and no change to your service.
2. Payzum publishes an x402 URL. An agent hitting it without payment receives an HTTP 402 Payment Required with the price and payment details, in the format agent clients already understand.
3. The agent pays in USDC on Base. Settlement runs through the external facilitator and lands directly in your wallet — Payzum never takes custody. Base confirmations are typically around two seconds. Roughly 1,000 transactions per month are free, then about $0.001 per transaction plus gas. // confirmar pricing actual
4. Payzum proxies the paid call. Your real endpoint is invoked with your key, the agent gets its response, and you get a signed webhook plus an audit-log entry — alongside an on-chain transaction anyone can verify. API providers can be serving paying agents the same day they configure it.

Where this fits in practice

The evidence and liability problem bites hardest where transactions are numerous, small and machine-initiated — exactly the shape of agent traffic. Concrete cases:

• An API or data provider selling per query. A pricing, enrichment or geospatial API charges a few cents per call. Under card rails, each of those is an unauthenticated micro-transaction you'd never economically defend in a dispute. Over x402, each call is a settled USDC payment in your wallet with an on-chain receipt.
• An MCP server or agent tool. You built a tool that agents call inside Claude or another client. There's no human session to fingerprint, no cardholder to authenticate, and no sensible way to onboard each agent with an API key. Per-call payment removes the signup step entirely.
• A publisher or research vendor metering machine access. Rather than blocking crawlers or negotiating bulk licences, you price access per request and let agents pay. The payment record doubles as your access log for who paid for what.
• A business that sells to humans and agents both. People still buy through hosted checkout, payment links, invoices or subscriptions; agents pay per call over x402. Both settle non-custodially into the same wallet, with optional auto-conversion to USDC or USDT.

Agent purchase on card rails vs. paid on-chain

Fair objections

"If payments are final, my customers have no recourse."

They have the recourse you give them, which for most businesses is what already happens: you refund. The difference is who holds the decision. On card rails an issuer can reverse a settled payment without your agreement, months later, and you pay a dispute fee whether or not you win. With final settlement, a refund is a payment you send because you decided the customer was right. Good merchants refund either way; only one arrangement lets a third party do it for you.

"We need an auditable trail for accounting, tax and internal controls."

You get two, and they cross-check each other: Payzum's signed webhooks and complete audit log inside your systems, and the on-chain transaction anyone can verify without asking us. That's a stronger reconciliation position than a processor statement alone. Standards work like AEP is aimed at a different layer — proving agent intent and behaviour across reversible rails — and it's worth following if you sell through card-based agent channels. This isn't legal or accounting advice; confirm your own reporting requirements.

"Isn't this only for APIs? We sell physical goods."

Today, x402 shines for per-request digital access, which is where agent traffic actually is. If you sell goods to people, the relevant Payzum surfaces are hosted checkout, payment links, invoices with overpayment detection and expiry, or in-person POS with a fresh QR per sale. Same non-custodial settlement, same absence of chargebacks — different front door.