Agentic chargebacks explained: who absorbs a disputed AI-agent purchase, what Visa’s rules and Amex Agent Purchase Protection say, and the record to keep.
TL;DR: Agentic chargebacks are disputes over purchases an AI agent made for someone. Fraud cases mostly follow existing card rules. The hard cases are everything short of fraud: the agent misread an instruction, exceeded its mandate, or the user claims it did. Network rules don’t yet settle who absorbs those, and American Express’s Agent Purchase Protection is a commitment to its own U.S. Card Members, under conditions it has published. Whoever runs the agent will be asked to prove what the agent was authorized to do and what it saw when it acted, which means writing that authorization-time context down at the moment of the decision.
A customer tells their shopping agent to reorder printer ink. The agent buys a new printer. Or it buys the right ink from a seller the customer has never heard of, at twice the usual price. Or it buys exactly what was asked, and the customer, who regrets the order, says the agent went rogue.
Each of these ends in a dispute, and each lands on rules written for a person clicking “buy,” not for shopping agents. Unauthorized-transaction rules ask a binary question: did the cardholder authorize this or not? An agent breaks the binary. The customer authorized the agent. Did they authorize this purchase?
Nobody has fully answered that yet. What you can do now is make sure that when the question is asked about your agent, you have the evidence.
An agentic chargeback is a payment dispute over a purchase that an AI agent initiated on a person’s behalf. It may claim fraud (someone else controlled the agent or credential), agent error (the agent bought something other than what was asked), or overreach (the purchase exceeded the authority the person gave). Resolving it depends on proving the mandate and what the agent acted on.
Worldpay’s head of agentic commerce put the current state plainly in 2026: “No liability shift exists yet.” The article notes that when an agent authenticates properly and a token is issued correctly, liability “generally follows existing authenticated tokenized-transaction rules.” Then: “Where it gets murkier is everything short of outright fraud.”
In the US, consumer protections already contain the concept that matters, authority, without an answer for agents. What follows summarizes the rule text; it isn’t legal advice.
For credit cards, Regulation Z defines “unauthorized use” as use “by a person, other than the cardholder, who does not have actual, implied, or apparent authority for such use, and from which the cardholder receives no benefit.” The official interpretation adds that whether such authority exists “must be determined under state or other applicable law.” It also says that a cardholder who furnishes a card and grants authority to a person “who exceeds the authority given” is liable for those transactions until the cardholder has told the creditor that the person’s use is no longer authorized.
Regulation Z’s billing-error rules offer a second path: a charge “for property or services not accepted by the consumer or the consumer’s designee, or not delivered to the consumer or the consumer’s designee as agreed.” The commentary’s examples include delivery of something different from what was agreed and delivery of the wrong quantity. It excludes disputes over the quality of goods the consumer accepted, and leaves whether acceptance occurred to state or other applicable law.
For debit cards and other electronic transfers, the Regulation E commentary has the same exceeded-authority rule. If a consumer furnishes an access device and grants authority to a person “who exceeds the authority given, the consumer is fully liable for the transfers unless the consumer has notified the financial institution that transfers by that person are no longer authorized.”
Both commentaries give the same examples of such a person: a family member or a co-worker. None of this text addresses software that a consumer set up to place orders for them.
Worldpay’s article summarizes the regulatory side: Regulation E “still assumes a binary,” and there is “no framework yet for ’I asked my agent to buy something inexpensive, and it bought something expensive instead.’”
Visa’s network rules now address agent purchases directly. The April 2026 edition of the Visa Core Rules and Visa Product and Service Rules defines an Agentic Payment Provider: an application that can “search, discover, and purchase products and services” for a cardholder after receiving the cardholder’s payment instruction and verification. Section 4.1.24 sets its obligations. As above, this summarizes rule text and isn’t legal advice.
Before the purchase. The provider must “Clearly state the expiration date of the Cardholder-defined payment instruction” and “Obtain Cardholder acknowledgement that they are responsible for actions taken by the Agentic Payment Provider.”
During the purchase. It must “Use only the Cardholder-defined criteria for purchasing the goods or services,” and it may not aggregate multiple agentic transactions into one.
After the purchase. It must make an order confirmation available to the cardholder for at least 120 days.
Responsibility. Section 4.1.24.10 reads, in full: “A Cardholder is responsible for any actions taken by an Agentic Payment Provider as part of an Agentic Transaction as if the Cardholder initiated the Transaction.” How that sentence interacts with Regulation Z and E in a given dispute is a question for counsel.
The same rules add no agent-specific dispute condition, so an agent dispute is filed under whichever existing condition fits the claim, such as 10.4 (Other Fraud – Card-Absent Environment) or 13.1 (Merchandise/Services Not Received). The dispute chapter’s only agent-specific language sits in condition 10.4’s compelling-evidence path: for disputes processed from October 24, 2026, the login IDs it can match on include “login IDs for an Agentic Payment Provider.”
For a builder, the operative phrase is “Cardholder-defined criteria.” Whether a purchase stayed inside them is a question your own records have to answer.
Fraud through the agent. Someone else controlled the agent, stole the credential it holds, or tricked it with injected instructions. This is closest to existing card-not-present fraud and is the best-handled case.
Agent error or overreach. The user really did delegate, and the agent acted outside the instruction: wrong item, wrong quantity, over budget, wrong seller. The user is right, and somebody absorbs the cost.
Mandate repudiation. The agent did exactly what it was told, and the user disputes it anyway. Worldpay calls this “friendly fraud with a new excuse”: a false “my agent went rogue” claim. Without evidence of the instruction, the merchant cannot challenge it.
The second and third look identical from the outside. Both say “the agent did something I didn’t want.” Only a record of the mandate, and of what the agent did against it, tells them apart.
American Express calls its commitment for agent purchases an industry first. It announced Amex Agent Purchase Protection alongside its Agentic Commerce Experiences (ACE) Developer Kit in April 2026. The ACE page describes it in forward-looking terms: “In the future, if a Card Member authorizes a registered AI agent to make a purchase, and that agent sends American Express the customer’s authenticated purchase intent, American Express will protect eligible customers from charges related to AI agent error.”
The terms published on that page set the conditions:
Two details matter for builders. First, the protection runs on captured intent: no authenticated intent from a registered agent, no coverage. Amex’s ACE kit lists Intent Intelligence as the service that captures purchase intent “to support authentication, authorization, and disputes,” and on October 13, 2026 Amex published an Intent Intelligence framework built around a Create Intent API, an Intent ID and a Proof of Intent Token. Second, the test is deviation from intent. “Buy the best headphones” cannot be deviated from in a way anyone can verify; “Sony WH-1000XM5, under $350, from an authorized retailer” can.
The protection also has a scope Worldpay points out: it “covers the card member – it doesn’t resolve what the merchant absorbs if the underlying dispute is about agent behavior rather than fraud.”
| Condition | What the ACE page states |
|---|---|
| Cards | U.S. Credit Cards issued by American Express National Bank and American Express Travel Related Services Company, Inc. |
| Agent | Must be registered with American Express and integrated with the ACE developer kit |
| Intent | American Express must receive the Card Member-authenticated purchase intent from the agent |
| Covered error | Transactions where the purchase deviates from the Card Member-authenticated purchase intent |
| Order of operations | Available only after the Card Member has initiated a return, where possible, with the merchant |
| Exclusions | Claims may not be available where intent is subjective or non-verifiable (the page’s examples are “best” or “really nice”) or if a claim is fraudulent |
| Status | “Full terms and conditions will be made available in the future” |
Strip the protocols away and every agent dispute asks four questions:
Protocols are converging on the first row. The Agent Payments Protocol (AP2), which Google announced in September 2025, defines a Checkout Mandate and a Payment Mandate, each “open” (constraints before a cart is final, such as budget and allowed instruments) or “closed” (authorization for a specific checkout or amount), chained “to provide a complete, verifiable audit trail.”
The second and third rows are on you. A mandate proves what was allowed. It does not prove the agent read a correct price, that the budget had room, or that the user had not revoked the mandate a minute earlier.
| Question | Evidence | Who usually holds it |
|---|---|---|
| What did the user authorize? | The signed mandate or intent: items, budget, merchant, expiry | Agent platform; issuer if intent was sent to it |
| What did the agent see when it acted? | Price, item, seller and availability as read at decision time | Agent platform |
| Which limits were in force? | Budget remaining, per-agent caps, policy version at that moment | Agent platform or the fintech running the agents |
| Did the purchase match? | The order and authorization, compared with the above | Merchant, issuer |
The numbers below are illustrative.
A user gives a household agent an open mandate: groceries and household goods, $400 a month, approved merchants only. On the 28th the agent orders $62 of supplies. The user disputes it: “That order put me over my budget.”
The agent platform checks. Its spend counter is rebuilt every ten minutes from order confirmations. At the moment of the order, the counter read $331. A second agent instance, running on the user’s tablet, had placed a $41 order four minutes earlier, not yet in the counter. Real spend before the disputed order was $372. The disputed order took the month to $434.
The user is right, and the platform can only show it with a record of what the agent read. If all it logged was “order placed, mandate valid,” it cannot tell the user’s claim from a repudiation, and neither can anyone downstream.
The fix is a decision record written in the same transaction as the spend check, so the record cannot disagree with what was checked.
-- One statement: the spend check and the decision record commit together.
WITH checked AS (
-- Lock the mandate row; no row back if revoked, expired or over budget.
UPDATE mandates
SET spent_this_period = spent_this_period + :amount
WHERE mandate_id = :mandate_id
AND status = 'active'
AND expires_at > now()
AND spent_this_period + :amount <= period_cap
RETURNING mandate_id,
spent_this_period - :amount AS spend_before,
period_cap,
policy_version
)
INSERT INTO decision_records
(decision_id, mandate_id, agent_id, merchant_id, item_ref,
price_seen, spend_before, period_cap, policy_version, decided_at, outcome)
SELECT :decision_id, mandate_id, :agent_id, :merchant_id, :item_ref,
:price_seen, spend_before, period_cap, policy_version, now(), 'approved'
FROM checked
RETURNING decision_id;
-- zero rows: the mandate is revoked, expired or over budget. Do not buy.
The UPDATE serializes every instance of the agent on one mandate row: under PostgreSQL’s READ COMMITTED, a concurrent update waits, then re-checks its WHERE clause against the committed row. The record takes its spend, cap and policy version from the row the check just updated, so it cannot disagree with the check. That closes the gap in the worked dispute: the tablet’s $41 order is in the mandate row before the $62 order is checked, so the $62 order is declined. Two instances ordering at the same moment cannot both slip under the cap either, which is the race condition a periodic counter leaves open.
Two habits make the record useful in a dispute. Record inputs, not just the outcome: the price and spend the agent read, and the policy version. And attach the identifiers the payment carries, such as an Amex Intent ID or an AP2 mandate reference, so the issuer’s record and yours can be joined.
The Tacnode Context Lake™ holds the agent side of the loop: the decision context an agent reads before it buys, and the decision it writes. Mandates, per-agent limits, spend reservations and decision records are state the agent platform owns. Held in Tacnode, they are covered by full ACID transactions, so the check and the record commit together, and two agent instances spending against one mandate cannot both pass its cap. The derived context the decision reads, such as spend this period across every instance or orders with this merchant in the last hour, is computed on demand against the latest committed data in the same system. Order confirmations and refunds from merchant or processor systems can arrive by change data capture and join the same state, as current as that feed. The chargeback itself is processed where it always was; Tacnode decides no disputes and enforces nothing inside a card network’s, issuer’s or merchant’s ledger.
When a dispute arrives weeks later, the decision ledger answers the questions in the table: what was allowed, what the agent saw, which agent spend limits were in force. For the payment protocols that carry intent, see Visa Intelligent Commerce and Mastercard Agent Pay; for why concurrent agents need transactions, see ACID for agents.
Former Cockroach Labs. Tells stories about infrastructure that actually make sense.
Fresh Context Newsletter
The argument behind the posts — what breaks when AI acts on stale data, from the team building the Context Lake. About twice a month.
Book a demo and discover how Tacnode can power your AI-native applications.
Book a Demo