Friendly fraud — where a legitimate-looking customer purchases goods then disputes the charge — cost the e-commerce industry an estimated $25 billion in 2025. This brand was losing $340,000 a month to it.
The attacker group used a rotating pool of residential proxy IPs, making each transaction appear to originate from a unique, clean home connection. Traditional IP reputation tools scored them as low-risk. Stripe's built-in radar missed every single one.
What Sentinel Saw
Sentinel's client-side Edge SDK detected subtle hardware-level signatures shared across all the "different" accounts: identical WebGL renderer strings, matching TLS cipher suite ordering, and timing jitter patterns consistent with virtualized environments. Despite appearing to come from 400+ distinct IPs, Sentinel grouped them into a single fraud cluster within 6 hours of deployment.
The Block
A single rule was pushed: any checkout with a Sentinel cluster-match score above 0.85 required an additional step before payment was processed. The fraud group — unable to pass the check — abandoned the attack entirely. $0 in disputes were filed that month from the cluster.
Financial Impact
$340,000 in dispute fees and lost inventory saved in the first 30 days. Stripe's fraud risk flag on the merchant account was removed 45 days after deployment. The brand's chargeback rate dropped from 1.8% to 0.06%.
Why Stripe Radar Missed Every Single One
Stripe Radar is excellent at catching obvious card fraud — clearly stolen cards, IPs that recently appeared on fraud lists, addresses that don't match BIN country. The attack hitting this brand defeated all three.
The cards used were freshly stolen and not yet on any list. The IPs were real residential addresses sourced from a residential proxy network — exit nodes on AT&T, Verizon, and Comcast home connections. The shipping addresses matched the BIN countries because the attackers used legitimate-looking addresses (often abandoned properties or reshipping mules).
From Stripe's vantage point, every transaction looked like a normal customer making a normal purchase. The fraud only became visible 30-60 days later when the legitimate cardholders disputed the charges.
The Device-Cluster Signal That Cracked It
Sentinel's SDK collects ~400 device-level signals on every visit. The brand's data showed 400+ "distinct" customers across 45 countries placing orders in a single week. Sentinel's clustering engine reduced those 400 sessions down to 11 underlying physical devices based on:
- Identical WebGL renderer string ("ANGLE (Intel, Intel(R) UHD Graphics 620, OpenGL 4.1)")
- Matching TLS cipher-suite order (a JA4 hash collision — only 0.001% of real Chrome installs share this hash)
- Audio context sample rate of 44100 Hz with a specific oscillator phase signature consistent with virtualized environments
- Mouse acceleration curves sampled from the same generative library
The Block Strategy
The brand's engineering team didn't immediately block these clusters — they let them through for 48 more hours while gathering evidence. After confirming every transaction from those 11 clusters resulted in either an immediate dispute or no genuine fulfillment confirmation, they enabled a single rule: any checkout matching one of the 11 cluster IDs required SMS verification before payment was processed.
Within 6 hours, the attack stopped. The fraud cluster could not pass SMS verification at scale (each verified phone costs them money and takes time). They moved on to easier targets.
What Other Brands Should Take From This
Three lessons that apply beyond this specific case:
- IP reputation is a 2018 control. In 2026, every serious attacker uses residential proxies. If your fraud stack relies on IP reputation as a primary signal, you are catching the bottom 30% of attackers.
- Cluster on hardware, not on cards or IPs. Fraudsters can rotate cards and IPs cheaply. They cannot easily rotate physical devices, GPUs, or operating systems. That's the layer to attack.
- Don't add friction by default. Adding a CAPTCHA or SMS step to every checkout costs more in lost legitimate conversions than the fraud was costing. Add friction only to the sessions you have high-confidence evidence against.