Filing a Plumbing Complaint Under "Electrical"

Payment networks have spent decades refining the taxonomy of things that go wrong between a consumer and a merchant. Eight reason code categories. Hundreds of sub-codes. Evidence requirements calibrated to specific failure modes: fraud, duplicate charges, products never received. The system assumes two parties and a human decision.

Then an AI agent bought someone the wrong running shoes.

Dolores "Dee" Ledger has worked in dispute operations at a major payment network for eighteen years, a tenure spanning the transition from paper-based chargeback processing to automated evidence evaluation. She is, by her own account, "the person who reads the file." We spoke with her about what that file looks like when the transaction was initiated not by a human, but by a delegated AI agent.

A note on sourcing: Ms. Ledger does not exist outside this publication, and her surname is a little too perfect for payments. Her observations are grounded in the concrete details of Visa's Agentic Commerce Protocol, Mastercard's Agent Pay framework, and the dispute infrastructure documented by Stripe and the payment networks. The character is hypothetical. The operational gaps she describes are not.

You've been processing disputes for almost two decades. What's actually different about the first agent-initiated disputes hitting your queue?

Dee: The file is fatter and thinner at the same time. I've got fields I've never seen before. A vault token ID, an allowance object with a max amount and an expiry timestamp, a checkout session ID scoped to a specific merchant.¹ More structured pre-authorization data than I get on a typical card-not-present transaction. A human tapping "buy now" on their phone doesn't generate an allowance object.

But then I go looking for the stuff I actually need to resolve the dispute, and it's just... not there.

What's missing?

Dee: The mandate. The consumer told the agent "find me running shoes under $150." That instruction is the case. It determines whether the agent was within scope. And it's sitting in a chat log on the AI platform's servers. It doesn't flow into the payment record. It doesn't appear in the checkout session. It's nowhere in my file.

I can see the agent stayed under the spending limit. I can see the merchant charged the correct amount for the item ordered. I can see the allowance wasn't expired. Everything in front of me says: authorized, processed correctly, within bounds. And the consumer is telling me the agent bought dress shoes instead of sneakers.

So where does that dispute land in the existing reason code taxonomy?

Dee: Nowhere clean. Stripe maps network codes into eight categories: fraudulent, duplicate, product not received, product unacceptable, subscription canceled, credit not processed, unrecognized, general.² Walk through them with me.

Fraudulent? No. The consumer authorized the agent. Unrecognized? No, the consumer recognizes the merchant, they told the agent to shop there. Product unacceptable? Maybe, but the product is fine. Perfectly good pair of shoes. Just not what the consumer wanted. No cardholder authorization? The cardholder did authorize. They authorized the agent. They didn't authorize this specific item.

So it falls into "general." And "general" is where disputes go to receive insufficient evidence guidance, because the system doesn't know what to ask for. I've been doing this eighteen years. "General" is the reason code equivalent of a shrug.

Visa's Mark Forestell described this as "something happened in the middle," where both consumer intent and merchant processing were correct, but a problem occurred between them.³ Does that framing match what you're seeing?

Dee: Most honest description I've heard from anyone at the network level. He's naming a structurally new layer.

In a standard card-not-present dispute, I have two parties. Consumer and merchant. Did the consumer authorize? Did the merchant deliver? Binary questions, mostly. Now I have three parties: consumer, agent platform, merchant. And four possible gaps. The consumer authorized the agent but not this specific transaction. The agent translated the mandate incorrectly but stayed within the allowance bounds. The merchant processed correctly but received a wrong-item selection from the agent. And the platform holding the mandate record, the actual evidence I need, isn't party to the dispute at all.

What about the new infrastructure? Agent Score, the Agentic Registry, the allowance object. Doesn't that close some of these gaps?

Dee: It closes the fraud gaps beautifully. Someone spins up a fake agent, tries to charge stolen credentials? The registry and the agent trust score catch that. The token scoping catches that. The allowance is locked to a specific merchant ID, a specific maximum amount, a specific checkout session.¹ Real progress. Genuinely impressive plumbing.

But fraud isn't the hard problem here. The hard problem is the dispute where nobody did anything wrong. Consumer authorized in good faith. Agent operated within bounds. Merchant charged correctly. Consumer still got the wrong thing. The interpretation happened in a layer the payment system can't see, and the evidence lives in a system the payment network can't subpoena.

What about Visa's Compelling Evidence 3.0 requirements? Do those work for agent-initiated transactions?

Dee: This is where I start to get a headache. Compelling Evidence 3.0 requires the merchant to submit at least two customer identifiers, and at least one has to be device-level. IP address, device ID, device fingerprint.² The idea is you match the disputed transaction's device signals to a pattern of prior undisputed purchases from the same customer.

An agent browsing programmatically presents its own IP. The device fingerprint is the agent platform's infrastructure fingerprint. If I'm trying to match that against the consumer's prior purchase history from their home laptop, nothing matches. The framework was designed around human device continuity. Agents break that assumption completely. Every agent transaction looks like a first-time purchase from a data center.

What failure mode worries you most?

Dee: Two things keep me up.

First, the retry. Agents retry on timeout. If the merchant's checkout API isn't idempotent and the agent fires twice, the consumer gets two charges.⁴ That maps to the "duplicate" reason code, which I know how to handle. But the causation is completely different. No human double-clicked. A software loop fired. And the evidence of why it retried lives in the agent platform's logs, not the merchant's records. I can adjudicate the symptom. I can't investigate the cause.

Second, scope creep across sessions. Consumer sets a $500 monthly limit. Agent makes twelve purchases across unrelated sessions, each one within bounds. Consumer sees the aggregate on their statement and disputes. No single charge was unauthorized. To reconstruct what happened, I'd need session data from the agent platform, transaction records from multiple merchants, and the network's token history. That data is distributed across systems that don't have established sharing protocols yet. I'd have an easier time getting three divorced parents to agree on a vacation itinerary.

Is the industry going to solve this?

Dee: Forestell said it himself back in March: "we're working on that."³ Since then they've shipped the Trusted Agent Protocol and Agent Score. Visa's modifying the token framework and data capture process. Mastercard's Agent Pay program specifies consumer controls and registered agents.⁵ The bones are there. Good bones.

But the dispute reason codes haven't been updated. The evidence requirements haven't been rewritten. The mandate still lives outside the payment record. And I'm still categorizing agent-interpretation failures as "general" and hoping the analyst downstream can figure out what I couldn't.

Last question. What would you want in the file that isn't there yet?

Dee: Two things.

First, the chat log. Give me the consumer's instruction and the agent's response. Put it in the evidence package the way we put shipping confirmations and email transcripts in today. That single artifact resolves eighty percent of the ambiguity I'm dealing with.

Second, give me a reason code. Call it "authorized agent, misselected item." Call it whatever you want. Just give it a name so the system knows what evidence to ask for.

Footnotes

1. Agentic Commerce Protocol, Delegate Payment API reference (beta). https://www.agenticcommerce.dev/docs/reference/payments ↩ ↩²

2. Stripe, Dispute reason code categories and Dispute object. https://docs.stripe.com/disputes/categories and https://docs.stripe.com/api/disputes/object ↩ ↩²

3. AP reporting by Barbara Ortutay and Ken Sweet, June 10, 2026, on Visa/OpenAI partnership announced at Visa Payments Forum. https://finance.yahoo.com/sectors/technology/articles/visa-plugs-payment-network-chatgpt-180150542.html ↩ ↩²

4. Stripe, Agentic commerce for sellers documentation. https://docs.stripe.com/agentic-commerce/for-sellers ↩

5. Mastercard, "Mastercard unveils Agent Pay," April 29, 2025. https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html ↩