An AI agent can complete a technically valid card payment without completing a purchase the buyer actually permitted. The resulting dispute is not resolved merely by asking whether the card was authenticated. Responsibility depends on the mandate, the seller’s obligations, the payment instrument, the jurisdiction and evidence of what the agent did. New contracts are beginning to assign that risk expressly.
An Authorized Card Is Not Necessarily an Authorized Order
Suppose a shopper instructs an AI assistant: ‘Buy one pair of running shoes, size 9, maximum $150, from a seller that accepts returns.’ The agent locates a $140 listing but orders two pairs for $280, selects an ineligible merchant or approves express shipping beyond the stated budget. A card issuer can authorize the $280 charge, and the merchant can fulfill it. Yet the agent has exceeded the buyer’s instructions. This is a different problem from a fraudster stealing a card number, and the law does not supply a universal answer across countries or funding sources.
The dispute contains at least four questions. Was the payment instrument used with valid authentication? Did the human delegate authority for *this particular* order? Did the merchant deliver goods conforming to the order that was actually placed? And which commercial counterparty must reimburse someone if the agent’s reasoning departed from its delegated instructions? An authentication approval answers the first question at most. It does not prove the second.
This becomes a retail issue because a user interface may combine product recommendation, cart creation, checkout and payment into one response bubble. Our related reporting on banks blocking unauthorized AI agents from customer accounts illustrates the tension between automation and institutional responsibility. Preventing untrusted account access and preventing an authorized agent from overspending are complementary, but separate, control problems.
The Contractual Breakthrough: Stripe Allocates Agent Error Risk
Stripe’s published Agentic Commerce Agent Terms contain unusually direct language. As between Stripe and the agent-interface provider, they place responsibility for certain unauthorized agent transactions on the interface provider where consent was not appropriately obtained, the purchase exceeded authority, or bugs, hallucinations and misinterpretations caused the transaction [1]. The terms also require auditable records of consent and the user’s authority at the time of each transaction. This is primary-source evidence that the industry is no longer treating unintended purchases as an abstract AI-safety discussion.
That allocation is not, however, a ruling that the consumer always receives a refund from the AI company. It defines rights among identified contractual parties. Depending on payment method and jurisdiction, consumer rights may operate separately and override attempts to contract them away. Similarly, Stripe’s terms describe the seller as the merchant of record with responsibility for fulfillment, returns and certain buyer service matters. A returnable pair of shoes delivered as ordered by a merchant is not automatically a merchant fulfillment failure merely because the agent should never have placed the order.
A second important clause distinguishes who operates the agent from who operates the merchant checkout. The agent interface needs to capture and retain purchase authority; the merchant needs to describe the goods, price, taxes and delivery; the payment credential provider should restrict use to the permitted amount and seller. The bank and card network then assess the payment instruction under the applicable rules. A single defective order may implicate multiple layers without making every layer jointly liable for every loss.
How AP2 and Scoped Tokens Could Build an Evidence Trail
Figure 1 | Purchase mandate, token and receipt must be independently verifiable.
Google’s Agent Payments Protocol, AP2, defines separate roles for the shopping agent, credential provider, merchant, merchant payment processor and a trusted surface that obtains informed user consent [2]. Its authorization framework distinguishes the user’s delegation of a mandate from a verifier’s subsequent check that a specific purchase fits it [3]. These are design responsibilities proposed by the protocol, not proof that every live agentic transaction currently follows this system or that AP2 overrides payment law.
Stripe describes Shared Payment Tokens that restrict use to a particular seller, maximum amount and time window, without disclosing the underlying card data to the AI agent [4]. For an order capped at $150, a credential scoped to $150 should prevent a $280 attempt through that credential even if the shopping model misreads the user’s intent. It cannot determine whether the selected shoes are counterfeit, whether a stated color matters or whether the user intended only one item at $140. Authorization controls and product-quality controls are different.
Visa’s Trusted Agent Protocol focuses on proving and recognizing agent identity in merchant interactions [5]. Identifying a genuine agent helps distinguish it from a malicious bot; it does not by itself prove that any given purchase was approved by the cardholder. Indeed, a properly identified agent might commit the very mistake the buyer fears. A robust evidentiary chain needs *both* identity and specific permission.
For a deeper look at model governance and control testing, our AI-powered banking audit framework sets out why logging a model output is less useful than independently controlling its ability to execute money movement.
Original Responsibility Matrix: Five Failure Cases
| What went wrong? | First-party issue to investigate | Potential remedy route | Why liability is not automatic |
| Stolen payment credential used by unrelated fraudster | Payment security / unauthorized transaction | Bank or issuer error/dispute process | Depends on instrument and legal definition |
| Agent exceeds signed dollar cap | Agent mandate and credential enforcement | Interface provider, issuer, merchant cancellation | Valid payment authentication may coexist with excess mandate |
| Agent stays in budget but buys wrong product | Instructions, merchant listing, return conditions | Seller return/cancellation, provider complaint | May be authorized payment but erroneous product selection |
| Merchant charges more than checkout approved | Seller amount integrity | Issuer dispute, merchant refund | Merchant evidence and final amount matter |
| Customer approved purchase then regrets it | Applicable returns or cancellation rights | Merchant return policy / consumer law | Regret is not equivalent to unauthorized payment |
The matrix is an analytical diagnostic tool, not a statement that any company has been found legally responsible for each category. Dispute timelines, chargeback rights and mandatory refund requirements differ across cards, debit transfers, credit products and non-card rails.
What EU and U.S. Consumer Payment Law Actually Protects
Under PSD2 Article 73 in the European Union, a payer’s PSP generally has to refund an *unauthorized payment transaction* immediately and no later than the next business day after noticing or being notified, subject to the statute’s conditions and fraud-related exception [6]. The rule is valuable but it cannot be applied mechanically to an AI buying the wrong size or an item the user dislikes. First establish whether the transaction legally lacked payment authorization, as opposed to deviating from a separate shopping instruction. Article 74 sets other conditions for payer liability; implementation and factual proof matter.
In the United States, the CFPB explains that Regulation E’s unauthorized electronic fund transfer definition addresses transfers initiated by someone other than the consumer without actual authority and with no benefit to the consumer. It also describes an exclusion involving access devices furnished to another person by the consumer [7]. Whether an AI agent or its provider fits that framework is fact-sensitive and should not be assumed. Credit-card disputes also operate under separate rules: do not equate all card purchases with a debit-account EFT. For an AI-driven purchase, who had the device, whom the consumer delegated to, and whether the transaction delivered any benefit may matter materially.
This tension highlights a missing concept in many advertisements for ‘AI shopping’: authorization to *use a credential* and authorization to *buy an item* can diverge. A bank may have high-confidence token authentication, while the user has strong evidence the agent was only allowed to spend half the amount. A technically valid transaction is not a definitive legal conclusion about consumer authorization.
Worked Example: The $150 Mandate and the $280 Basket
Figure 2 | Limits control payment exposure, not product selection.
Assume an agent receives a $150 total-spend cap and produces a $280 basket. The excess is $130, or 86.7% above the mandate. If a merchant allows cancellation before dispatch, the amount potentially avoided is $280. If goods have shipped, resolution could involve return shipping, restocking, partial refunds or contested fees. No universal formula assigns the $130 excess automatically to a provider, because user approval, contract terms, returned goods and the funding rail all matter.
Consider three credential designs. In an unrestricted-card design, the agent can attempt the entire $280; the only limit is fraud/issuer controls. A merchant-only token reduces where the credential can be used but may not prevent the extra quantity. A merchant-, amount- and time-scoped token with a $150 limit should block the $280 authorization at the payment layer, assuming the cap is properly enforced. The third design addresses the dollar overrun; it still needs explicit product and quantity controls if the agent can substitute an unwanted item below $150.
An economically useful experiment is to audit the outcome of ‘disallowed agent actions,’ rather than just the accuracy of language-model answers. How often does the system attempt an out-of-scope purchase? How often is a payment prevented? How often is the order canceled before shipment? And how often is a consumer made whole only after a formal dispute? Those four rates reveal distinct control failures.
Original Sensitivity Model: Controls Can Introduce Their Own Costs
Figure 3 | Modelled annual error and false-decline costs.
Imagine 100,000 annual agentic purchases. In a wholly illustrative base case, 0.10% create an unauthorized-purchase incident and each incident creates $180 in direct remedial losses plus $35 of processing and customer-support cost. Expected annual burden: 100 x $215 = $21,500. Suppose hard spend and merchant constraints reduce the incident rate to 0.02%: 20 x $215 = $4,300, a savings of $17,200 before implementation costs. These are hypothetical assumptions, not measured market incidents.
Now include false blocking. If the controls incorrectly reject 1% of otherwise valid purchases, that is 1,000 blocked legitimate orders. At an illustrative $25 contribution margin per lost order, potential lost contribution is $25,000. Savings from prevented unauthorized purchases would then be smaller than lost contribution. But if 80% of incorrectly blocked orders successfully resume after customer reapproval, the opportunity cost falls to $5,000 and net operational benefit before system cost is $12,200. A checkout system must measure false rejects and user recovery along with prevented abuse.
This model cautions against simplistic maximum-lockdown or maximum-autonomy strategies. The correct objective is to minimize total expected loss—fraud and agent errors, merchant-support cost, lost conversion, disputes and control operating expense—while honoring mandatory consumer protection. A low fraud rate with unusably high false rejects is not a satisfactory product.
The Evidence Consumers and Merchants Should Preserve
The most useful artifact is a compact mandate record showing maximum total price including tax and shipping, quantity, seller identity, permitted substitutions, destination address, expiry, whether recurring purchases are allowed and the consumer approval timestamp. The merchant should preserve the order summary and the amount presented to the verifier. The payment provider should retain token scope and authorization outcome. Together, these records could distinguish a compromised credential from an agent running past its instructions.
A post-incident response must be ordered sensibly: stop any further agent spend; preserve logs before automated systems overwrite them; request cancellation if fulfillment is pending; notify the payment provider when a payment is genuinely disputed; then pursue merchant return rights or the AI provider’s contractual remedy. Do not file a ‘stolen card’ declaration merely to reverse an unwanted but genuinely approved purchase. In many cases, rapid seller cancellation is commercially better than a delayed issuer dispute.
The operational challenge is broader than shopping. Our article on banking supervisors’ concerns about autonomous AI examines why agent identity, permission boundaries and human intervention must remain independently testable wherever software can trigger financial obligations.
What Would Prove the Emerging Framework Is Working?
One convincing test would be a verifiable decline of every purchase exceeding a cryptographically signed price cap, regardless of the language model used. A second would show that an approved purchase has a tamper-evident consent and checkout trail that a consumer can review in a dispute. A third would demonstrate low false-decline rates with effective recovery when legitimate orders are blocked. None depends on marketing claims about being a ‘trusted agent.’
By contrast, persistent purchases outside saved mandates, inconsistent evidence among agent and merchant logs, or repeated disputes about who should refund customers would show that liability is being pushed around instead of reduced. Protocol adoption is a mechanism; actual unauthorized-purchase and consumer-remedy outcomes are the test.
Bottom line. Unauthorized AI purchases need not create a legal vacuum, but there is no single liable party for every case. Payments law protects particular unauthorized transactions, private contracts allocate responsibilities among intermediaries, and seller obligations govern order fulfillment. The strongest design prevents unauthorized execution, rather than promising to solve all errors after the debit is complete.
Methodology
Research cutoff: 23 October 2026. Legal descriptions reflect primary sources as published, not individualized advice. The scenario assumes 100,000 annual purchases, a baseline unauthorized-incident rate of 0.10%, a controlled rate of 0.02%, $215 per incident, 1% legitimate false declines, $25 contribution per non-recovered order and 80% reapproval recovery in one case. All scenario percentages are assumptions. Contractual obligations between Stripe and agent providers are not represented as court findings or automatically applicable to every consumer.
Sources & primary documentation
Selected source documents, accurate to the research cutoff. Numbered references correspond to references in the article; links are clickable.
[1] Stripe: Agentic Commerce Agent Terms (contractual risk)
[2] Google AP2: Payment-protocol specification
[3] Google AP2: Agent authorization framework
[4] Stripe: Agentic commerce primer and scoped tokens
[5] Visa: Trusted Agent Protocol
[6] EUR-Lex: PSD2 Articles 72–74
[7] CFPB: Unauthorized EFT interpretation and FAQs
[8] Google: AP2 overview and role boundaries
[9] Stripe: General services agreement, AI agents
[10] CFPB: Credit-card charge dispute deadlines
[11] CFPB: Product refund versus credit-card dispute
[12] Visa: B2B agent payment pilot, Oct 2026
[13] FTC: Internet merchant delivery and refund duties
[14] CFPB: Regulation E error resolution
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574