If you run an online store, ecommerce fraud prevention is not one control at the payment step. It is a set of defenses spread across the whole customer journey: the login page, the signup form, the checkout, the dispute process afterwards, and the scripts running on your pages the entire time. Fraudsters probe every one of those points, usually with automation, and a stack built only to score transactions is blind to the parts where the attack actually begins.
This guide walks through the five fraud types that cost online retailers the most, how to prevent each one, and how to assemble them into a layered defense instead of a pile of disconnected tools. If you are shopping for specific products rather than a framework, the companion ecommerce fraud prevention software guide ranks ten vendors; this one is about the jobs to be done.
What counts as ecommerce fraud
Ecommerce fraud is any activity that uses your storefront to take money, goods, data, or account access that does not belong to the actor. The useful way to think about it is by where it happens in the journey:
- At login: account takeover.
- At signup: new-account and promo abuse.
- At checkout: card testing and payment fraud.
- After the sale: chargebacks and friendly fraud.
- Across the whole page lifecycle: Magecart and client-side skimming.
Two facts shape the entire defense. First, most of this is automated, so the earliest reliable signal is how a session behaves and what device it comes from, not the transaction it eventually fires. Second, a large part of the attack surface lives in the browser, where server-side and payment-processor tools cannot see. Those two facts are why device intelligence and client-side visibility sit underneath everything below.
Account takeover (ATO)
Account takeover is a fraudster logging into a genuine customer's account, usually with credentials leaked in a breach and replayed at scale (credential stuffing). Once inside, they drain stored value, steal saved cards, change the shipping address, or resell the account. Javelin Strategy & Research put US account takeover losses at $13.5 billion in 2025, up 18% year over year, which makes it one of the costliest categories on this list.
How to prevent it. Passwords alone will not, because the attacker already has a valid one. The durable signal is the device and session behind the login:
- Device fingerprinting catches a login from a device your customer has never used, and links many failed attempts back to one machine even across cleared cookies and rotating IPs.
- Automated-session and bot detection flags the tooling credential stuffing runs on (Playwright, Puppeteer, Selenium, and agentic browsers) before the login form is ever submitted at scale.
- VPN and proxy detection raises risk on logins hidden behind anonymizing connections, including the residential proxies that evade IP reputation lists.
- Step-up authentication (a one-time code, a re-auth prompt) applied only to risky sessions keeps friction off your real customers.
The point is to score the session before the credential check, not after. A full write-up lives on the account takeover use case.
New-account and promo abuse
Not all fraud needs a stolen account; some of it just needs many fake ones. Attackers create duplicate or synthetic accounts to farm signup credits, referral bonuses, free trials, and first-order discounts, or to stage later fraud. It rarely triggers a chargeback, so it hides in your growth metrics as "new users" while quietly draining promo budget.
How to prevent it. The tell is that many "different" accounts share one origin:
- Device correlation links accounts created from the same device even when the email, name, and payment method differ, which is the single most effective signal against promo farming.
- Incognito and anti-detect detection catches the private-browsing and hardened setups used to look like a fresh visitor each time.
- Velocity rules on device, not just IP or email, catch bursts of signups that a network-only view misses.
See the new-account fraud use case for the detection detail.
Card testing
Card testing is how criminals validate stolen card numbers before using them elsewhere. They fire large volumes of small authorizations or low-value orders against your checkout, keep the cards that succeed, and discard the rest. Even when the test charges are tiny, you pay authorization fees, risk gateway penalties for a high decline rate, and often eat the chargebacks when the real cardholder notices.
How to prevent it. Card testing is almost entirely automated and high-velocity, which makes it detectable at the session layer:
- Bot and automation detection identifies the scripted checkout attempts driving the volume.
- Device fingerprinting ties a spray of attempts back to one device even as the card numbers and IPs change.
- Velocity limits on payment attempts per device and per session throttle the testing loop.
- CAPTCHA or step-up on risky sessions only breaks the automation without punishing genuine buyers.
The card testing use case covers the signal set in depth.
Chargebacks and friendly fraud
A chargeback is a customer disputing a charge with their bank. Some are true fraud (a stolen card), but a growing share is friendly fraud: a real customer disputes a legitimate purchase, whether by genuine confusion or deliberately to get goods for free. Either way you lose the revenue, the goods, and a dispute fee, and too many chargebacks threaten your processing agreement.
How to prevent it. Two moves, in order:
- Prevent the transactions that become chargebacks. Stopping account takeover and card testing upstream removes a large share of the disputes before they exist.
- Win the ones you dispute with evidence. For friendly fraud especially, the bank wants proof the order came from the customer's device. Device-level evidence tied to the order, the fingerprint, the VPN or proxy status, and the automated-session verdict, is what turns a dispute in your favor.
cside exports chargeback evidence keyed to the same device fingerprint ID, packaged for the representment process, so you are not reconstructing what happened from logs after the fact.
Magecart and client-side skimming
The other categories are about who is transacting. This one is about what is running on your page. Magecart-style attacks inject a malicious script into your checkout, often through a compromised third-party dependency (an analytics tag, an A/B testing tool, a chat widget), and skim card data as the customer types it. Your server never sees the theft, your payment processor never sees it, and the customer completes a normal-looking purchase.
How to prevent it. You cannot score your way out of a skimmer; you have to see the scripts:
- Script inventory and integrity monitoring tells you every script executing on your payment pages and alerts when one changes or a new one appears.
- Third-party dependency monitoring catches the supply-chain route, where the attacker compromises a vendor you trust rather than your own code.
- PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 make script inventory and change monitoring mandatory for payment pages, and they are audited on your page, not your processor's.
This is a different discipline from fraud scoring, and cside covers it with client-side security script monitoring.
A layered defense framework
No single product stops all five. Effective ecommerce fraud prevention layers three things:
- A browser-level signal source. This sees the device, the session behavior, the automation, the VPN or proxy connection, and the scripts on the page, before the transaction fires. It is the layer most stacks are missing.
- A decisioning or rules engine. This consumes the signals plus your transaction data and decides to allow, challenge, or block. It can be a dedicated fraud platform or your own rules.
- Evidence and compliance. This is what you use after the fact: chargeback representment packages and PCI DSS script-monitoring records for your QSA.
The common failure is buying layer two and skipping layer one, then wondering why the scoring platform keeps missing automated attacks and fresh-device logins. The scoring engine is only as good as the signals feeding it, and the richest signals live in the browser.
Where cside fits
cside is a single first-party JavaScript snippet that supplies the missing browser-level layer for all five fraud types above. Because it loads from your own origin, there is no third-party collector domain for a filter list or an attacker to block, so you keep signal on privacy-conscious visitors.
- Device intelligence. A stable device fingerprint built from 250+ browser, device, and network signals per session, holding accuracy across incognito, VPN, and cookie-clearing. It returns alongside a real-time verdict: AI agents and automated sessions (OpenAI Operator, Claude for Chrome, Playwright, Puppeteer, Selenium), VPN and proxy connections including residential proxies, and incognito mode. That is the input every one of the fraud types above depends on.
- Client-side security. Script inventory and integrity monitoring for your payment pages, which is what PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 ask for and what catches Magecart-style skimming. This is script-monitoring, a separate discipline from the device-signal count above.
- Chargeback evidence. Device-level proof keyed to the same fingerprint ID, packaged for representment.
The signals come from one integration and one contract, and they feed whatever decisioning platform you already run, rather than replacing it. Device coverage is web today, with native iOS and Android SDKs in beta (early access) running the same engine as the web client.
Which controls should you prioritize?
- Losing accounts to credential stuffing: start with device fingerprinting plus automated-session detection on login.
- Promo and referral budget disappearing into fake users: device correlation at signup.
- A spike in tiny declined orders: bot detection and per-device velocity limits at checkout.
- Chargebacks eating margin: upstream prevention first, then device-level evidence for representment.
- PCI scope on your checkout: script inventory and change monitoring, which fraud scoring never sees.
Match the control to the loss you are actually taking, layer a browser-level signal source underneath your decisioning platform, and validate on real traffic before you commit. For a vendor-by-vendor comparison, see the ecommerce fraud prevention software guide.
