When we talk about e-commerce fraud, a lot of the focus goes to botnets, proxy networks, and stolen credentials. But there’s a vector that’s becoming increasingly sophisticated and harder to catch with basic device fingerprinting: rooted (Android) and jailbroken (iOS) devices.

In a standard mobile environment, the OS sandboxes applications to keep data isolated and secure. Rooting shatters that sandbox. Power users do this for customisation; fraudsters exploit root access to bypass the very security mechanisms that e-commerce platforms rely on. The tricky part is that not every rooted device belongs to a fraudster; some are just developers or tech enthusiasts. A blanket ban on all rooted devices creates unnecessary friction and false positives.

The most effective approach is dynamic risk scoring. By combining multi-layered root detection (checking for Magisk hide, abnormal file systems, and binary analysis) with behavioural biometrics, we can evaluate the user's actual intent. If a rooted device is exhibiting bot-like navigation or rapid-fire card entries, the risk score spikes, and the transaction is blocked. If it behaves like a normal user browsing a catalogue, it can be handled with step-up authentication instead. 

How do fraudsters exploit rooted devices?

• Standard fraud tools look at Device IDs, MAC addresses, and GPS locations to flag suspicious activity. With root access, fraudsters use tools to spoof kernel-level data. They can make a single device look like thousands of unique, legitimate mobile phones to bypass velocity checks.
• Using dynamic instrumentation toolkits like Frida or Xposed, attackers can hook into an e-commerce app’s processes in real-time. This allows them to bypass SSL pinning, intercept API traffic, and manipulate variables during the checkout flow before the payload is encrypted.
• Root access makes it trivial to run automated scripts directly on the device. Fraudsters can simulate human interactions to test stolen credit cards or execute credential-stuffing attacks from an environment that looks like a real mobile user rather than a headless browser.
• Rooted environments can intercept the API calls meant to verify a fingerprint or Face ID, injecting a "success" response to authorize fraudulent transactions or account takeovers.

Why is detection crucial for E-commerce?

• Protecting the Checkout Layer: The checkout is the most sensitive touchpoint. If a device is compromised, fraudsters can manipulate the transaction before payment authorization even occurs. You need to know if the environment is secure before processing the data.
• Trusting Your Telemetry: Risk engines run on data. If a device is rooted, its telemetry (location, device specs, network info) is fundamentally untrustworthy. Detecting the root allows you to properly adjust the behavioural risk score for that specific session.  
• Preventing Reverse Engineering: Fraudsters often decompile legitimate apps to identify vulnerabilities or create malicious repackaged clones. Root detection adds a layer of friction, making it significantly harder to analyse the underlying code.

How does the Sensfrx Mobile SDK neutralise threats originating from compromised devices? 

Sensfrx goes beyond basic device fingerprinting by continuously validating both the runtime environment and the user's physical behaviour. 

• Rather than just looking for a superficially rooted flag, the SDK scans for modified binaries, abnormal system permissions, SELinux enforcement, and root management tools. These signals are evaluated by the Sensfrx Cognitive Engine to determine the device's true security state.
• To stop attackers from intercepting API traffic or bypassing SSL pinning, the SDK actively detects function-level hooking and injected libraries and specifically targets frameworks like Frida. If runtime manipulation is detected, the app can block or alert on the activity in real time.
• Because root access makes running automated scripts trivial, Sensfrx tracks precise screen touch coordinates, interaction timing, and gyroscope-based motion patterns. The Cognitive Engine analyses this telemetry to easily distinguish a scripted bot from a genuine user holding a device.
• To combat reverse engineering and malicious repackaging, the SDK continuously validates the app’s runtime integrity, checking for altered signatures, duplicate package identifiers, and unauthorised code injections.
• Sensfrx ensures your risk models are fed authentic data by actively detecting emulator environments, proxy-based location masking, and GPS spoofing.

When legitimate agentic AI assistants browse your store to buy items for real customers, your security tools flag them as malicious threats and block them at the checkout. Real human shoppers take minutes to think before buying. AI agents can add 50 items to a cart in milliseconds to check availability or compare prices across platforms, accidentally locking up your inventory.

This creates a nightmare for your business operations. Your analytics data become a mess of false positives, marketing teams cannot trust conversion metrics, and valuable inventory gets tied up in phantom carts. Worst of all, you are actively locking out high-intent buyers who are ready to spend money, driving them straight to competitors whose sites actually welcome AI shoppers.

The fix requires a shift from outdated behavioral tracking to intent-based security. By implementing AI-friendly handshakes, dedicated machine-to-machine API gateways, and advanced behavioral fingerprinting, you can safely welcome profitable AI commerce traffic while keeping malicious hackers out.

What to do about it?

•  Implement zero-duration inventory holds for automated sessions. Do not reserve physical warehouse stock for an agent until a valid payment token is successfully pre-authorised.
• Adopt the IETF AgentID protocol draft by configuring your firewall to validate signed Agent Identity Tokens (AIT) carried over JWT. Support cryptographically signed authorization proofs issued by trusted networks like the W3C AI Agent Protocol Community Group's community standards, treating verified agents as authenticated enterprise workloads rather than anonymous browsers.
• Overhaul traditional Web Application Firewall (WAF) rule sets that block high-frequency IP requests. Instead, utilize multi-factor intent scoring that cross-references high traffic speeds with a valid payment token pre-auth, cryptographic authorisation proofs, and explicit data payloads (like a direct add-to-cart call following product search) before applying rate limits.
• Tag agent-driven sessions separately in your analytics. Do not let automated shopping traffic mix with human engagement data or fraud model training.
• Build API-style checkout endpoints for verified agents. Keep them separate from human-facing pages. Use risk scoring models designed for non-human behaviour.
• Deploy structural defense checks to catch malicious botnets claiming to be trusted AI shoppers. Cross-verify incoming agent sessions using network-level trust layers, such as the Visa Trusted Agent Protocol (TAP) or Mastercard Agent Pay frameworks, which match public cryptographic keys against known agent provider registries.

 

What is actually happening

Friendly fraud occurs when a genuine customer makes a legitimate purchase and then disputes the charge with their bank and effectively obtains a free product. With household budgets tightening in 2026, consumers are discovering that bank dispute processes are fast and consumer-friendly.

The merchant bears the burden of proof in every dispute, and most do not have the documentation infrastructure to fight back effectively, leading to lost product and revenue alongside chargeback fees.

What to do about it

• Delivery confirmation with signature capture: For high-value orders, require a signature on delivery. A signed delivery receipt is your strongest evidence against a non-delivery claim.
• Granular order communication: Send detailed confirmation emails and shipping notifications. A paper trail showing the customer was informed at every step substantially weakens dispute claims.
• Clear, accessible return and refund policies: Many cases start because a customer could not find an easy way to return an item. A friction-free return process removes the motivation to dispute instead.
• Evidence packages: Build a library of response templates that include order details, IP address, and delivery confirmation. Speed of response is critical to winning these disputes.
• Repeat offender flagging: Track customers who have previously filed disputes. Multiple disputes from the same account should trigger order holds or manual review on future purchases.

What is actually happening

Triangulation fraud runs a three-party scam at your expense. A fraudster builds a fake storefront with prices lower than the market rate. A real customer places a legitimate order there and pays the scammer with clean money. The scammer then purchases that same item from your store using a stolen credit card, ships it directly to the real customer, and pockets the difference.

You see a normal-looking order with a real delivery address. The payment authorisation is fine. Weeks later, the stolen card owner notices the charge, disputes it, and you receive a chargeback and then lose the product, the revenue, and the chargeback fee.

What to do about it?

• Triangulation fraud almost always ships to an address that has no relationship to the card's billing address. Weight this signal heavily for new or unverified customers.
• Check the order email domain: Fraudsters frequently use temporary or disposable email addresses. Flag orders from domains like mailinator.com, guerrillamail.com, or newly registered domains.
• Velocity checks on shipping addresses: The same delivery address receiving multiple orders from different billing names and cards is a strong triangulation signal, even if each individual card passes authorisation.
• Monitor for below-cost pricing on referral sources: If orders are being referred from an unknown external site, investigate the source. Triangulation often drives traffic from lookalike storefronts.
• Chargeback ratio monitoring: Track your chargeback-to-order ratio by product category. A spike in disputes for specific high-demand items often indicates an active triangulation campaign.

Advanced Bot and Fraud Detection

• Behavioural Biometrics: Analyse mouse movements, keystroke rhythms, and pauses. Bots are mathematically precise, whereas humans are inconsistent. Flag anomalous user behaviour that heavily deviates from historical baselines.
• Device Fingerprinting: Track users across rotating IPs by building a unique identifier using browser settings, OS, and screen resolution.
  • Network Integrity: Penalise or block traffic originating from data centres, proxies, and VPNs.
  • Spatial Inconsistency: Flag hardware mismatches, such as a mobile device exposing desktop-level GPU traits.
  • Proxy Floods: Identify single IP addresses generating a high diversity of browser signatures.
• Session Monitoring: Analyse temporal patterns to separate human hesitation from automated scripts.
  • Buyer Velocity: Bots often complete checkouts in under 30 seconds, while humans typically take 3 to 5 minutes.
  • Abnormal Duration: Flag sessions that are either unnaturally short, just like those hit-and-run bots, or excessively long data scrapers.
  • Navigation Behaviour: Detect abnormal, non-sequential jumps between the cart, payment, and product pages.

A new wave of AI-driven bots does not rush to checkout. Instead, these agents browse product pages, scroll through listings, and add items to carts slowly and naturally, exactly as a real shopper would. Traditional velocity checks look for speed anomalies (hundreds of requests per second), so a bot moving at human pace passes through completely undetected.

These bots are increasingly used for scalping limited-edition items, competitive price scraping, and inventory manipulation. All without triggering a single alert on a rules-based fraud system.

What to do about it?

• Analyse mouse movement patterns, scroll cadence, click timing, and keystroke dynamics. Even a well-scripted bot produces statistically different signatures from a real human.
• Move beyond per-request rate limiting. Score the entire session and observe how long it spent on a page, whether it followed a natural reading path, and whether it hovered over images.
• Look for mismatches between the declared browser environment and actual capabilities. Headless Chrome, missing fonts, or suspiciously clean browser history are common signals.
• Add hidden form fields or invisible page elements that real users will never interact with. Any session that triggers these is almost certainly automated.
• Instead of hard blocks, introduce micro-challenges (invisible CAPTCHA scoring, delayed responses) for suspicious sessions to make attacks economically costly without harming real customers.

If your e-commerce site has ever been hit by a botnet testing stolen credit cards, you already know the consequences that follow. A massive wave of Reason Code 10.4 (Card-Absent Fraud) chargebacks can overwhelm your dispute team. Visa officially refers to card testing as an enumeration attack. When you are trying to fight those disputes, standard receipts are not going to be sufficient. You have to provide specific Compelling Evidence based on Visa core rules. If you are tired of automatically losing these disputes, here is the exact playbook for securing your checkout and generating the evidence Visa actually values.

The 3-Transaction Rule: Your Primary Defence

If a card testing attack results in successful fraudulent charges, Visa gives you a specific mechanism to win the dispute: The 3-Transaction Rule. You can win if you can prove that 3 or more previous undisputed transactions share specific matching data points with the newly disputed charge. You need a match on at least one of these:

1. Device ID or Fingerprint: Must be at least 20 characters, derived from two or more hardware or software properties. Hashes are acceptable.
2. IP Address: Must be the clear-text public IP, either IPv4 or IPv6.
3. Customer Account ID: Clear-text unique login ID recognised by the cardholder.
4. Email or Phone Number: Consistent contact information across transactions.

If you offer a free trial or vault cards for future billing, stop running small $1 or $5 test charges. Visa specifically requires that merchants use a zero-amount Account Verification request, layered with CVV2 and Address Verification Service checks. This approach validates the card without triggering unnecessary authorisations that bots exploit.

Bots run through thousands of cards per hour. To stop this activity and stay compliant, Visa mandates that Card-Absent merchants set daily velocity limits not exceeding 25 transactions per day for a single user. If a user hits 25 transactions, you must trigger additional verification. Proving you enforce this limit demonstrates to Visa that you are actively monitoring fraud.

During an attack, bots will continually retry a card. If your gateway receives a Category 1 Decline, such as Code 14 for Invalid Account Number or Code 04 for Capture Card, do not allow your system to retry it. Visa strictly prohibits resubmitting authorisation requests after a Category 1 decline. Forcing them through destroys your ability to win disputes and invites severe non-compliance penalties.

Compelling Evidence Requirements for Digital Goods

If you sell Software-as-a-Service (SaaS) or digital goods, Visa's baseline for Compelling Evidence is strict. You must capture the following information:

1. Purchaser IP address and geo-location: Record these at the exact date and time of the transaction.
2. Device ID or Device Name: Capture and store this for all transactions.
3. Verified profile access: Provide proof that the verified profile was accessed before the purchase date.
4. Layered verification controls: Use zero-amount verifications, cap users at 25 transaction attempts per day, and aggressively log Device IDs and IP addresses so you can leverage the 3-Transaction Rule when disputes arise.

Data Retention Timelines for Chargeback Defence

Maintaining records for an adequate period is critical for supporting chargeback disputes. Merchants must understand the chargeback windows set by different payment networks, as these determine the minimum duration for record retention.

Chargeback windows by payment network:

Payment Network	Typical Chargeback Window	Recommended Retention Period
Visa	120 days from transaction date	Minimum 1–2 years
Mastercard	120 days from transaction date	Minimum 1–2 years
American Express	Up to 120 days from transaction date	Minimum 1–2 years
Discover	Up to 120 days from transaction date	Minimum 1–2 years

Whilst the chargeback window is typically 120 days, merchants should retain all supporting evidence. This includes transaction records, delivery confirmations, customer communication, account login logs, and photographs. Merchants should keep these records for a minimum of one to two years after the transaction. This extended retention period provides protection against disputes that may take longer to emerge and ensures compliance with industry standards and regulatory requirements across different jurisdictions.

Merchants should establish a clear data retention policy that outlines which records must be kept, for how long, and in what format. Digital records should be stored securely and remain easily accessible for the duration of the retention period. This approach not only strengthens the merchant's position in dispute resolution but also demonstrates a commitment to maintaining proper documentation standards to financial institutions and regulatory bodies worldwide.

The strength of your chargeback defence depends on how comprehensively you collect and store transaction data. Are you actively passing rich Device Fingerprints to your payment gateways, or are you mostly relying on standard CVV checks? The merchants who win card testing disputes are those who treat evidence collection as a foundational part of their transaction processing, not as an afterthought.

It is a common industry challenge that merchants often lose chargeback disputes despite having positive customer feedback, such as five-star reviews. This discrepancy typically arises because financial institutions adhere to rigorous evidentiary standards that prioritise objective data over customer sentiment. There are two core structural issues that often lead to these outcomes.

1. Challenge of Identity Attribution
   A significant hurdle in dispute resolution is the lack of a verified link between the reviewer and the cardholder. Without technical proof, it is difficult to establish that the individual who praised the product is the same person who authorised and executed the payment.
2. Hierarchy of Evidence
   Standard banking protocols frequently prioritise logistical carrier data over user-generated content. In instances where signature confirmation is absent, “item not received” claims are difficult to contest unless supplemented by more granular digital proof.
   Enhanced Evidence Correlation for Merchants

To improve win rates, merchants should focus on building a technical handshake between customers' digital behaviour and physical delivery events. The following steps address both the challenge of identity attribution and the hierarchy of evidence

1. Align Device IDs and IP addresses from customer feedback with the metadata captured during the original transaction. This creates a direct, objective link between the reviewer and the cardholder, addressing the identity attribution gap at its core.
2. Cross-reference account login data with the transaction record to confirm that the same verified buyer account was used both at the point of purchase and at the time of review submission. A matching account identifier serves as direct evidence that the cardholder and the reviewer are one and the same.
3. Document post-delivery account activity by recording when a customer accesses their verified buyer account shortly after a carrier marks a package as delivered. This behaviour pattern indicates awareness of receipt and directly counters “item not received” claims.
4. Construct a timestamped narrative by documenting, for example, a login from a primary IP address to post a review within 24 hours of a GPS-verified delivery photo at the same location. This sequence ties identity confirmation to physical delivery proof in a single, coherent evidence chain.
5. Utilise shipping partners that provide GPS-stamped delivery photos to negate claims of non-receipt. When correlated with localised account activity originating from the same IP address or device used during the original transaction, this evidence satisfies both the logistical and identity attribution standards required by financial institutions.

Successful dispute management relies on proving both intent and receipt through precise data correlation. By simultaneously establishing that the cardholder and the reviewer are the same individual and that delivery was completed. Merchants can present objective, multi-layered evidence that meets the high standards required by financial partners to mitigate friendly fraud effectively.

What is actually happening?

Through an inventory hoarding attack or denial of inventory.

During a flash sale or a big product launch scalper bots flood the site. Add lots of items to many separate shopping carts.

Online stores hold onto inventory for a short time when someone adds an item to their cart to stop selling too much of it.

This means your real customers see an 'out of stock' message and go to a competitor to buy it.

Later when the cart sessions end the bots just abandon everything.

You are left with a warehouse, no sales from the launch, and customers who have already moved on to something else.

What to do about it?

Shorten cart reservation timers during high-traffic drops. Five-minute cart expiries during launches are a reasonable starting point. Normal shopping sessions rarely need more than that.

Change your inventory logic to deduct stock only upon a successful payment rather than upon cart addition. This is the single most effective structural fix for inventory hoarding.

Apply bot detection at the add-to-cart stage, not just at checkout. Flagging suspicious sessions before they ever hold inventory is far more effective than trying to recover stock after the fact. Use challenge-then-allow flows for borderline sessions rather than hard blocks to avoid turning away genuine customers who may have triggered a rule incorrectly.

Enabling 3DS 2.0 or Strong Customer Authentication on purchases of high-demand products shifts liability and adds meaningful friction for scalper bots that are running automated checkout flows. Real customers using modern banking apps handle 3DS prompts quickly and with minimal disruption.

For extremely high-demand drops, a virtual waiting room forces all traffic through a single, monitored entry point. This eliminates the ability for bots to hammer the add-to-cart endpoint in parallel and makes behavioural analysis much simpler.

Sensfrx uses device risk intelligence to analyse sessions the moment an item hits the cart. This ensures real customers never see a false 'out of stock' message caused by ghost inventory. Standard rate limiting is often insufficient for sophisticated scalpers. Sensfrx monitors and identifies non-human behaviour patterns.

What is actually happening

Advanced scraper bots and carding bots are engineered to mimic human browsing behaviour. They click through category pages, view product listings, and add items to carts just like a real shopper would.

Your Meta Pixel, Google Analytics tag, and TikTok tracking script cannot tell the difference. They record all of this activity and categorise the bot as a high-intent shopper. The algorithm then automatically allocates your ad budget to retarget these bot profiles across the internet.

The result is that your Customer Acquisition Cost rises, your Return on Ad Spend drops, and you have been paying to advertise Python scripts the whole time.

What to do about it

• Client-side pixels take in all data without any filtering. Server-side event tracking helps you to control and check the data before it is sent to ad networks. This way you can decide what data actually helps your ad algorithms. Client-side pixels get everything. Server-side event tracking gives you control over what data's sent. You can. Validate sessions with server-side event tracking. It helps your ad algorithms to work. Server-side event tracking is more accurate. You have control over your data, with server-side event tracking.
• Connect your bot mitigation software directly to your analytics platforms. When a session is flagged as a bot, explicitly exclude that session ID and its behavioural data from being sent to Meta or Google. Most enterprise-grade bot tools support this via direct integrations or webhook-based exclusion lists.
• For comprehensive protection, a dedicated fraud layer like Sensfrx specialises in e-commerce bot patterns and integrates across all of these touchpoints.
• Card testing is an arms race. Attackers continuously probe for weaknesses in rule sets and fingerprinting logic. Running periodic red-team exercises against your own checkout, or reviewing your processor's decline rate trends monthly, helps you identify gaps before attackers do. A site that is expensive and low-yield to attack gets skipped. One that is easy and high-yield becomes a target.

What is actually happening?

Most merchants expect a security dashboard to go red. In reality, the first alarm almost always comes from the marketing or CRM team. To bypass guest checkout limits, bots automatically generate thousands of fake customer accounts using addresses like john.doe.19384[@]tempmail[dot]com. Your system dutifully syncs all of them to HubSpot, Klaviyo, or Mailchimp. Because each bot abandons the cart right after testing the card, your automated abandoned cart email sequence fires off. Thousands of emails hit fake or dead inboxes, causing massive bounce rates that damage your domain's sender reputation.

On top of that, you end up paying higher tier fees to your CRM provider for storing thousands of junk contacts that have zero value.

What to do about it?

To protect your marketing lists you need to verify email addresses before you add accounts. You can do this by sending a code or a magic link. This helps to stop people from creating accounts.

You should also set up alerts for when someone starts to pay for something but then stops. This is different from when someone leaves things in their cart. It is a way to know if someone is trying to use a stolen credit card. Most programs that help you understand your website can show you this information if you ask for it.

You need to check for fake accounts and get rid of them. Look for accounts that have never bought anything and have names that seem suspicious or use email addresses that are only used once.

When you find out that someone is trying to attack your website, you need to act. This means you need to know how to stop people from getting to your website for a while, who to call at the company that handles your payments, and where to find the records of who has been on your website. You should look at these records all day so you can understand what is happening and make new rules to stop the attack.

It is also an idea to use a special kind of payment field on your website like the ones that Stripe offers. This helps to keep your website safe because you are not handling credit card information yourself. This makes it harder for bots to get into your website and steal information.

1. Use email verification to stop accounts
2. Set up alerts, for payment activity
3. Get rid of accounts regularly
4. Act fast when you find out about an attack
5. Use payment fields to keep your website safe

You should do all of these things to protect your website and your customers.

What is actually happening

Relying solely on basic CAPTCHAs is a legacy approach. Today's attackers run headless browsers like Puppeteer or Selenium, routed through millions of residential proxies. To a standard firewall, each request looks like a different person browsing from a normal home Wi-Fi network.

When they do encounter a CAPTCHA, they route it via API to human CAPTCHA-solving farms that charge fractions of a cent per solve. Bots will also deliberately target your lowest-cost items, like a $2 sticker or a digital download, to stay below your team's manual review thresholds.

What to do about it

When people buy things online do not make them do a CAPTCHA every time. Only make them do it if you think something is not right. For example if someone is buying a lot of things quickly or if their computer or phone is acting strange or if they are using a proxy server. Making everyone do a CAPTCHA is annoying for people and does not really stop malicious bots. There are tools like reCAPTCHA v3, Cloudflare Turnstile and hCaptcha that can check if someone is a person without bothering them. These tools can tell if someone is a bot or not, and they make it expensive for bot operators to keep trying.

Just looking at what kind of device someone's using is not enough. You should also look at how they move their mouse, type, scroll, and how long it takes them to do things. Bots are different from people even if they are trying to act like people. Do not let people buy things if they are using a proxy server or a VPN. Most real people do not use these things to shop. You can use tools like Cloudflare or Akamai to block this kind of traffic before it even gets to your website.

If you think someone is a bot, make your website load slowly for them. Bots need to be able to try a lot of things quickly, so if you slow them down, it is not worth it for them. They will probably go somewhere else that is easier to attack. This way you can protect your website without bothering people.

What is actually happening

Cybercriminals buy stolen card databases called dumps from the dark web. Before reselling them at a premium, they need to verify which cards are still active. To do this, they unleash bots directly on your checkout page.

The bot creates a cart, fills in stolen card details, and submits the checkout form. Their goal is not to buy your product. They just want to trigger a $0 or $1 authorisation ping from your payment gateway. Once the gateway responds with approved, the bot abandons the cart instantly.

Because no transaction actually settles, post-order fraud tools that analyse completed orders never even see the attack. But you get hit with thousands of authorisation fees from your payment processor all the same.

What to do about it

To stop people from trying to pay with cards, we should limit how many times someone can try to pay from the same computer, email or card. If someone tries to pay three to five times and it does not work, we should block them for a while.

When people try to pay a small amount of money, like one to five dollars, from the same computer, it is probably someone trying to see if a card is real. We should always ask for the card's security code to ensure it is real. Many cards lack this code, which helps prevent misuse.

We should also check that the address on the card matches the address the person is using. If it does not match we should consider it a high risk. Not let them pay. There are tools like Stripe Radar that can help us make rules to block people who are trying to use cards.

We can also stop people from trying to pay with cards by setting a minimum amount for payments. This way people cannot try to pay one dollar to see if a card is real. Some types of cards are used often for fake payments, so we should be careful with those.

We should not wait until someone tries to pay to check if they are real. We should check as soon as they put something in their cart. We should also watch for people who are trying to pay a lot of times in a short amount of time. If a lot of people are trying to pay and it is not working, it might be someone trying to use cards.