Chargeback fraud starts before the dispute

December 19, 2025 · 4 min read

When a cardholder disputes a transaction and has the charge reversed through their bank, the merchant loses the revenue, pays a dispute fee, and in most cases never recovers the goods or services. For online businesses where there is no face-to-face interaction and no physical card present, disputing a chargeback is difficult and rarely successful. The operational cost of contesting one (staff time, documentation, dispute fees) often exceeds the value of the original transaction.

The conventional response is to outsource the problem to a chargeback guarantee service. You pay a percentage of every transaction, the vendor covers disputed charges, and the problem appears to be solved. Eye4Fraud built a business on exactly this model. It is worth examining what that model actually cost merchants, even before things went wrong.

What merchants paid for

Eye4Fraud charged a percentage of each transaction in exchange for covering chargebacks it had approved. To assess risk, it needed data: transaction details, customer names, email addresses, phone numbers, physical addresses, IP addresses, and partial credit card information. All of it flowed to Eye4Fraud's systems on every purchase.

The fee applied to every approved transaction. A returning customer buying from their usual device and location, with years of clean history, presented minimal chargeback risk, yet the guarantor still collected its cut on that purchase just as it did on a first-time buyer with a fresh email address connecting through a datacenter IP. The economics of the guarantee required revenue from low-risk transactions to subsidize payouts on high-risk ones.

Then in 2023, a breach exposed roughly 16 million records from Eye4Fraud's infrastructure. By February the stolen data (totalling 65 GB) was listed for sale on a hacking forum. The compromised data included the full range of customer information merchants had been sending: names, emails, phone numbers, addresses, IP addresses, and partial credit card details.

The guarantee had protected merchants against chargebacks. It did not protect their customers against having their personal and financial data exposed.

The signals were in the merchants' own data

Here is the thing Eye4Fraud's model obscured: the behavioral signals that predict chargebacks are visible in data the merchant already has. They do not require a third party to detect.

Chargebacks follow a limited number of patterns, and each one leaves traces before any dispute is filed.

Account takeover is the most direct path. An attacker gains access to a legitimate account and makes purchases with the stored payment method. The real account holder eventually notices and files disputes. Before any payment event, the takeover is visible: a login from a new device or location, a changed email address, a session pattern inconsistent with the account's history.

New account fraud feeds chargebacks through accounts created with stolen or fabricated credentials. The registration itself carries signals: a disposable email address, a device shared with other recently created accounts, a connection through infrastructure associated with fraud operations. These are detectable at signup, before the account makes its first purchase.

Friendly fraud is harder because the account legitimately belongs to the person buying. But even here, the behavioral context around disputed activity often differs from normal patterns. A user who browses casually and makes occasional small purchases, then suddenly places a high-frequency series of orders followed by radio silence, is behaving in a way that can be scored and flagged.

Subscription abuse follows a recognizable pattern: an account stops engaging with the service but continues to be billed, then disputes the charges in bulk. Session engagement data surfaces this before the dispute window opens.

Every one of these patterns is detectable from login records, session data, device signals, and account change events that the merchant's own application generates. Sending all of that to a vendor, paying a percentage for the privilege, and hoping they store it securely is one option. Running the detection yourself is another.

How tirreno catches it on your infrastructure

tirreno is open-source security framework that runs on your own systems. Your application sends events (logins, registrations, session activity, account changes) to a tirreno instance you control. tirreno evaluates the behavioral signals, scores accounts, and provides enforcement through the blacklist API. The customer data never leaves your infrastructure.

The fraud_prevention and account_takeover presets cover the rules most relevant to chargeback-prone behavior. Every rule weight is configurable from the rules page. The auto-blacklisting threshold triggers automatic action for accounts that accumulate sufficient risk signal. The manual review threshold surfaces accounts for investigation before losses accumulate.

The detection logic is open source. When a rule needs adjusting for your specific product, you adjust it yourself. When you want to know how your customers' data is stored, you look at your own database.

Getting started

Install. Deploy a tirreno instance on any server or container you control. The administration guide covers setup and configuration.

Send events. Start with logins, registration, and account changes (email, password, payment method updates). Each event also needs a timestamp, IP, user agent, and event type. The developer guide has the API schema.

Apply the fraud_prevention preset. Open the rules page, activate the preset, and browse the activity page. Look for accounts with elevated risk scores, devices appearing across multiple registrations, and login patterns consistent with credential stuffing.

Tune and expand. Adjust rule weights to match your product's fraud patterns. Add session events (page views, purchase flows) to build richer behavioral baselines. Set blacklist thresholds based on what the data tells you.

Download at tirreno.com/download.