Your Terms of Service Are Evidence — Here's How to Make Them Win Disputes

This is Article 2 in our Agentic Commerce and Chargebacks series. Article 1 covered the broader landscape of what happens when AI agents complete purchases and the dispute rules haven't caught up. This article is about one specific weapon you already have — and almost certainly aren't using correctly.

The Weapon Most Merchants Are Wasting

Every merchant that accepts card payments has Terms of Service. Almost none of them use those terms effectively as chargeback evidence.

The pattern is predictable: a merchant gets a chargeback, pulls together their order data and shipping confirmation, submits the representment — and loses. Not because they didn't fulfill the order. Not because the transaction wasn't legitimate. But because the cardholder's story to their bank was "I didn't agree to those terms" or "I didn't know about the cancellation policy" or "I never authorized recurring billing."

A properly constructed Terms of Service acceptance — collected correctly, logged thoroughly, and surfaced at the right moments — directly refutes each of those claims. It transforms "the customer says they didn't know" into "here is the timestamp, IP address, and exact version of the terms the customer accepted at 2:47 PM on February 3rd."

That's the difference between losing a winnable dispute and winning it.

Browsewrap vs. Clickwrap: The Legal Difference That Determines Whether Your Terms Hold Up

Courts have spent two decades sorting out which kinds of online agreements actually bind users. The answer has been remarkably consistent: it depends on how the agreement was presented and accepted.

Browsewrap: The Agreement Courts Often Won't Enforce

Browsewrap agreements claim that users accept terms simply by using a website. The terms exist somewhere — usually linked in the footer or on a separate page — but the user takes no affirmative action to agree to them. The theory is that presence on the site implies consent.

The landmark case here is Specht v. Netscape Communications Corp. (2d Cir., 2002). The court refused to enforce an arbitration clause buried in a software license that users could access by scrolling below a download button — but which was not displayed to them and required no affirmative acceptance. The court held that "a consumer's clicking on a download button does not communicate assent to contractual terms if the offer did not make clear to the consumer that clicking on the download button would signify assent to those terms."

That logic has echoed through dozens of subsequent cases. The fundamental problem with browsewrap is that users can genuinely not know the terms exist. Courts generally won't bind someone to terms they had no reason to know about, regardless of what the merchant claims.

Browsewrap isn't categorically unenforceable — Register.com, Inc. v. Verio, Inc. (2d Cir., 2004) enforced terms against a sophisticated commercial actor who repeatedly scraped a website after being told the terms applied. But that case turned on Verio's actual knowledge through repeated interaction, not passive website presence. That logic doesn't help you with a one-time retail customer disputing a subscription charge.

Clickwrap: The Standard That Holds Up

Clickwrap requires users to take an affirmative action — typically checking a box or clicking "I agree" — before they can complete a transaction. Courts have consistently enforced clickwrap agreements when the design makes clear what the user is agreeing to.

The design matters as much as the mechanism. In Meyer v. Uber Technologies, Inc. (2d Cir., 2017), the court evaluated whether Uber's app adequately notified users that creating an account bound them to terms of service including an arbitration clause. The court found the notice insufficient given the visual design and how small and inconspicuous the relevant text was. The arbitration clause was invalidated not because clickwrap is unenforceable, but because this particular design failed to give adequate notice.

The takeaway from Meyer isn't that clickwrap fails. It's that the design has to actually communicate what's happening. An unchecked checkbox buried below the fold, next to dense grey text in 8-point font, won't get the job done.

Which Terms Actually Matter for Chargebacks

Not all terms are equal in a chargeback dispute. The terms that matter are the ones directly relevant to the reason code being used. General boilerplate about governing law and limitation of liability means nothing to an issuing bank analyst reviewing a Visa 13.2 dispute. Specific, clearly written, checkout-visible terms are what shifts the outcome.

Here's how to map your terms to the disputes you're most likely to face:

Visa 13.2 — Cancelled Recurring Transaction

This is the reason code used when a cardholder claims they cancelled a subscription and you kept charging them, or claims they never authorized recurring billing at all. Your ToS defense here requires two things: proof that recurring billing was clearly disclosed and accepted before the first charge, and a clear record of your cancellation process.

The specific terms that matter: explicit disclosure of the billing frequency, the amount (or how it's calculated), how to cancel, and the notice period required before cancellation takes effect. These need to have been affirmatively accepted at signup, not just available somewhere on your site.

For recurring billing disputes, the acceptance log becomes your primary evidence. The timestamp and terms version showing the customer agreed to recurring billing before the disputed charge was processed is often the single most important piece of evidence in the package.

Visa 13.1 and 13.3 — Merchandise Not Received / Not as Described

When a cardholder claims they didn't receive an item or that it wasn't what they ordered, your ToS can establish the delivery timeline they agreed to and define what the product actually is. Delivery window language in your terms, combined with your shipping confirmation and tracking data, directly addresses the "not received" claim. Product specifications incorporated by reference into your terms (through links to product pages at time of order) address the "not as described" claim.

For digital goods and SaaS, your terms are even more important because there's often no physical delivery to prove. If your ToS clearly defines what the service is, what the subscription includes, and what the refund window is, you have a documented record of what the customer purchased and agreed to receive.

Mastercard 4855 — Goods or Services Not as Described

Similar logic applies here: your product specifications, service description, and any limitations on what's included should be explicitly stated in or incorporated into your terms. If the cardholder claims the product wasn't what they expected, your evidence package should include the terms they accepted that described exactly what they were getting.

The Audit Trail That Wins Representments

Collecting ToS acceptance is only half the battle. The other half is logging it in a way that you can actually present as evidence months later, when the dispute arrives and you need to reconstruct exactly what happened at checkout.

Here's what to capture at the moment of acceptance:

• Timestamp (UTC): The exact date and time the acceptance was recorded. Store in UTC to avoid timezone ambiguity.
• IP address: The IP from which the acceptance was submitted. This corroborates that the acceptance came from a real session, not a server-side auto-accept.
• Account ID / email: The identifier linking this acceptance to the specific customer account involved in the dispute.
• Terms version: A version number, date, or hash identifying the exact version of the terms accepted. This matters because terms change over time, and you need to be able to produce the exact terms in effect at acceptance, not the current version.
• Checkbox state: Whether the checkbox was checked by the user (vs. pre-checked). Courts have distinguished between user-checked boxes and pre-checked defaults.
• Order ID: Link the acceptance record to the specific transaction being disputed.

Store this in a tamper-evident log with appropriate retention. Chargebacks can arrive up to 120 days after the transaction, and if you go to arbitration, the records need to be available and credible. A structured database with immutable write-once logging is far better than flat files that could be questioned for integrity.

The AI Agent Angle: Why This Becomes Critical Now

If you've read Article 1 in this series, you know that AI agents — shopping assistants, automated procurement tools, AI-driven subscription managers — are already completing real purchases. This creates a specific problem for ToS acceptance: when an algorithm clicks through checkout, who agreed to the terms?

The legal framework is more robust here than most merchants realize.

The E-SIGN Act and UETA: Electronic Agents Are Already Covered

The Electronic Signatures in Global and National Commerce Act (E-SIGN Act) and the Uniform Electronic Transactions Act (UETA) both explicitly address "electronic agents" — automated systems that take actions with legal effect on behalf of a person. UETA Section 14 states that a contract may be formed by the interaction of electronic agents, even if no individual was aware of or reviewed the terms at the time. This is statutory law, not speculation.

What this means practically: an AI agent completing a purchase on behalf of a consumer can form a binding contract. The merchant isn't dealing with a legal gray area — the framework explicitly covers this scenario. The consumer who authorized the AI agent to shop on their behalf is bound by the agreements the agent enters into, subject to the same rules about adequate notice and acceptance method that apply to human users.

Apparent Authority: The Common Law Foundation

Even before electronic agent statutes, the common law doctrine of apparent authority covered this territory. If a principal (the human consumer) authorizes an agent (the AI shopping tool) to act on their behalf, third parties (merchants) who deal with the agent in good faith can rely on that authorization. The principal is bound by what the agent does within the scope of that authorization.

If a consumer sets up an AI shopping assistant, grants it access to their payment method, and tells it to "find and buy the best option," the merchant who sells to that agent is reasonably relying on the consumer's authorization. The consumer's ability to later claim "I didn't personally click agree" is significantly weakened.

What Isn't Settled Yet

Most of the AI agent case law to date involves companies being bound by their own AI — as in Moffatt v. Air Canada, where Air Canada was held responsible for a chatbot's incorrect representation of its bereavement fare policy. The scenario where a consumer deploys an AI agent and then disputes the resulting transaction is a logical extension of established doctrine, but it hasn't been heavily litigated. How courts will treat cardholder claims that "my AI agreed but I didn't personally approve this specific purchase" remains to be fully worked out.

The direction of the law is clear. The specific fact patterns are still developing.

The Explicit Authorization Clause

Given this landscape, the most practical thing you can do right now is add explicit language to your checkout ToS addressing automated purchases. Something along these lines:

This clause doesn't change the underlying legal analysis — the E-SIGN Act and apparent authority doctrine already point in this direction. What it does is make the authorization explicit in the contract record, creating a cleaner paper trail for dispute resolution.

And critically: it works right now for human buyers too. A customer who has a family member complete their checkout, uses a browser extension to autofill forms, or delegates purchasing to an assistant has explicitly acknowledged their responsibility for authorized third-party actions. That's a useful clarification in any dispute where the cardholder claims someone else "must have" made the purchase.

Five Things to Fix This Week

This doesn't have to be a six-month project. Here are the specific, actionable changes that will move the needle on your ToS as a chargeback defense:

1. Switch from Browsewrap to Clickwrap

If your site currently presents terms through a footer link without requiring any affirmative action, that needs to change. Add an unchecked checkbox to your checkout flow with visible text linking to your terms and explicitly stating that completing the purchase means accepting them. Make it a required field — the form doesn't submit without it checked.

2. Surface the Specific Terms That Matter at Checkout

Don't just link to a 50-page document. Adjacent to the acceptance checkbox, display the two or three specific terms most likely to appear in a dispute: your cancellation policy, your refund window, your delivery timeline. Make the cardholder see them at the moment of purchase, not just have access to them theoretically.

3. Build a Proper Acceptance Log

If you aren't already storing timestamp, IP address, account ID, and terms version for every acceptance event, implement that now. This is often a straightforward database change. Talk to your developer about what's currently captured and what isn't.

4. Add the Agent Authorization Clause

Work with your attorney to add explicit language addressing purchases made by authorized agents, software, or automated systems. This addresses the AI agent scenario directly and also catches a range of other "someone else completed my checkout" situations.

5. Surface Key Terms in Order Confirmation Emails

Your order confirmation email is a second opportunity to create documented evidence that the customer received notice of the relevant terms. Include the key clauses — cancellation policy, refund window, delivery terms — in plain text in the email body. This creates a second documented touchpoint that you can include in your representment package alongside the checkout acceptance log.

Frequently Asked Questions