Who is liable when an AI agent buys the wrong thing? Chargebacks in agentic commerce
The cardholder authorized the agent. Did they authorize this purchase? That question sits between fraud and an ordinary dispute, and the evidence to answer it has to exist before the chargeback arrives.
In this essay
As of November 2026, the public Visa, Mastercard and AP2 materials reviewed here do not set out a dispute rule specific to purchases made by AI agents. Who bears the loss is decided by existing dispute rules, the terms between the buyer, the agent platform and the merchant, and the evidence each can produce. Agent purchases add a question that sits between fraud and an ordinary dispute: the cardholder authorized the agent, but did they authorize this purchase? Visa, Mastercard and the AP2 protocol are building the evidence to answer it, while the rules that will use that evidence are still forming.
This article treats liability as an evidence design problem. It is not legal advice, and terms vary by network, issuer, acquirer and market.
Are there chargeback rules for AI agent purchases yet?
Not as a distinct category, based on the public sources reviewed for this article. What exists are statements that evidence is being built for future disputes:
- AP2 says a primary objective is "to provide supporting evidence that helps payment networks establish accountability and liability principles", and leaves dispute procedures, retention and retrieval outside its scope. AP2: FAQ, AP2: specification v0.2
- Visa says the purchase outcome an agent reports, together with the user's instructions, can be used to resolve disputes. Visa Developer: Visa Intelligent Commerce overview
- Mastercard describes Verifiable Intent as linking identity, intent and action into a single privacy-preserving record. Mastercard: Verifiable Intent
The AP2 documentation states the open question plainly: when an agent transaction is fraudulent or wrong, is the user, the agent developer, the merchant, the network or the payment provider accountable? AP2: executive summary
For UK and EU customers, also ask counsel how the payment services rules on authorized and unauthorized transactions apply when consent was given to an agent. No regulator guidance that addresses agent mandates directly was found in the sources reviewed here.
Is an agent purchase fraud or an authorized purchase gone wrong?
Card dispute rules separate two broad families. In a fraud dispute, the cardholder says they did not authorize the transaction; Visa's card-absent fraud reason code 10.4 is an example, covered in Compelling Evidence 3.0. In the other family the purchase was authorized but something went wrong: goods not received, not as described, cancelled, duplicated or charged incorrectly. Visa's merchant guidance describes the response path: gather evidence, submit it to the acquirer and have it passed to the issuer for review. Visa: chargebacks
An agent purchase can land in either family, depending on what actually happened:
| What happened | Likely dispute family | Evidence that answers it |
|---|---|---|
| An unknown agent, or a stolen agent credential, made the purchase | Fraud | Registered agent identity, a token bound to that agent, the cardholder's passkey or mandate signature |
| The agent bought what was approved, but the item was faulty or late | Authorized, consumer dispute | Order record, delivery proof, the terms shown at checkout |
| The agent bought outside the approval: wrong size, over budget, another merchant | Contested; the cardholder may claim either | The signed instruction or mandate, and proof the checkout matched it |
| The same order was placed twice | Processing error | One purchase intention, idempotency keys, both receipts |
| The merchant changed items or price after approval | Authorized, but not as agreed | A merchant-signed checkout bound to the approval |
This mapping is illustrative. The reason code an issuer uses depends on the cardholder's claim and the network's rules. The third row is the new one: a purchase outside the approval looks authorized to the network, because a valid agent credential was used, and unauthorized to the cardholder, because they never agreed to it. Permission to research versus permission to buy covers how to write approvals narrow enough to settle that argument.
What evidence does a merchant need for an agent purchase?
Build the record at checkout, not when the dispute notice arrives. For each agent order, keep:
- The authority record. The signed instruction, mandate or intent record that authorized the purchase: Visa's passkey-approved payment instruction, AP2's Checkout and Payment Mandates, or Mastercard's Verifiable Intent record, depending on the rail.
- The order it was checked against. Exact items, quantities, price, currency, delivery promise and the return terms the agent was shown. In AP2, this is the merchant-signed checkout that both mandates are bound to.
- Agent identity. Which agent and platform, how it was verified (a Trusted Agent Protocol signature or Web Bot Auth check), and which agent-specific token paid.
- Authentication results. The passkey or 3-D Secure outcome and its timestamp.
- Fulfillment and service. Delivery proof, customer contact, and any cancellation or refund offered.
- A retrieval key. One identifier that links the payment to the authority record. AP2 suggests the Payment Mandate's transaction ID as the key for retrieving the Checkout Mandate.
AP2's dispute rules show what "verifiable" means: recompute the checkout hash, check that each receipt references the hash of its closed mandate, and verify both mandates under the merchant and processor rules. Only then do the mandates count as evidence of what the user and each party saw. AP2: specification v0.2 What AP2 is explains the mandates themselves, and the network-neutral dispute lifecycle covers case handling once a dispute is filed.
How do card networks describe agent authentication?
The networks describe authentication in different terms, which shapes what evidence will exist:
- Visa sets up a passkey when the agent is provisioned and asks the user to authenticate each payment instruction with it. Visa checks requests against that instruction, issues agent-specific tokens, and offers the Trusted Agent Protocol so merchants can verify signed agent requests. Visa Developer: Visa Intelligent Commerce overview
- Mastercard requires agents to be registered and verified before they transact, issues agentic tokens built on its tokenization and Payment Passkeys, and lets merchants verify agents with Web Bot Auth. Mastercard: agentic token framework It has also said it is working with the FIDO Alliance on a verifiable credential standard confirming amount, retailer and product. Mastercard: September 2025 announcement
- AP2 has the user sign on a trusted surface, or sign open mandates that the agent's key later closes. Any party may still challenge a transaction through existing mechanisms such as 3DS2. AP2: executive summary
Each of these produces a cardholder-linked signature over something. The dispute question will be whether that something was specific enough: a signature on "groceries this week" proves less than a signature on one cart.
Who pays when the agent gets it wrong?
Until rules settle, expect the answer to come from each party's terms and from what each can prove. Ask the same question of every participant:
- Buyer: what exactly did they approve, and was it specific enough to compare with the order?
- Agent platform: did the agent stay inside the approval, and what do its terms say about agent errors?
- Merchant: did the checkout match the approval, and did the merchant verify the agent before accepting the order?
- Issuer or credential provider: did it verify the instruction or mandate before releasing a credential?
Repeated orders deserve their own control, because a retry that creates a second purchase looks like a processing error to the cardholder. One durable purchase intention describes it.
What about stablecoin and x402 agent payments?
Card chargebacks do not apply. The x402 FAQ describes its exact scheme as a push payment that is irreversible once executed, so a refund is a new transfer from the seller, and a draft auth-capture scheme adds hold, capture and refund operations. x402 FAQ, x402: auth-capture scheme draft For these rails, the seller's refund policy and the agent's pre-payment controls carry the weight that dispute rules carry for cards.
FAQ
Can I file a chargeback if an AI agent bought the wrong item?
Usually you can raise a dispute with your card issuer, as for any card purchase. Whether it succeeds depends on the network's rules, what you approved and the evidence the merchant holds.
Is an AI agent purchase considered authorized?
It depends on what you approved. A purchase that matches a specific approval looks authorized; one outside it may be contested as unauthorized, and rules for that case are still forming.
What evidence should a merchant keep for agent orders?
The signed instruction or mandate, the exact order it was checked against, the agent's verified identity, authentication results, fulfillment proof and one ID that links them.
Do Visa and Mastercard have special dispute rules for AI agents?
Neither has published a separate agent dispute category in the sources reviewed here. Both describe agent authentication and intent records that are intended to support disputes.
Who is liable if an AI shopping agent makes a mistake?
There is no single answer yet. It depends on the agent platform's terms, the merchant's terms, network rules and which party can prove it acted within the approval.
Closing thought and further reading
The cardholder authorized the agent. Did they authorize this purchase? That question sits between fraud and an ordinary dispute, and the evidence to answer it has to exist before the chargeback arrives.
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.


