TrustLens – Fraud Prevention & Chargeback Defense for WooCommerce

Most WooCommerce fraud doesn't look like fraud. It looks like a customer. The shopper who returns nearly everything they buy. The "new" account that shares a shipping address with three others you already flagged. The checkout that's quietly taking dozens of declined cards in a row. None of that trips a payment gateway's per-transaction check — because each individual charge looks fine. It's the pattern across orders that gives it away, and that's the part most stores never see until the chargeback ratio is already climbing. TrustLens watches that pattern. Here's a two-minute walkthrough of how it works: https://youtu.be/Xxz8lcTnAlU WooCommerce fraud prevention built on customer behavior, not just card checks TrustLens is a customer trust scoring and fraud detection plugin for WooCommerce. Instead of judging a single transaction, it scores every shopper 0–100 from how they've actually behaved on your store — order history, returns, coupon use, disputes — and sorts them into six segments: VIP, Trusted, Normal, Caution, Risk, Critical. Open any customer's profile and you see exactly which signals moved their score. Nothing is a black box. How trust scoring works Every customer starts at a neutral base score of 50. From there, TrustLens' eight detection modules each contribute signals — positive or negative — based on what that customer has actually done: a clean return history nudges the score up, coupon abuse pulls it down, a filed dispute pulls it down further. Customers also earn a small, transparent age bonus as an account passes 90, 180, and 365 days since their first order. Every signal that touched the score — module, points, and a plain-English reason — is listed right on the customer's profile. Nothing is a mystery number. The final score is clamped to 0–100 and mapped into one of six segments:

• VIP (90+) — your best customers; bypasses velocity-based checkout rules by default
• Trusted (70+) — solid history, low risk
• Normal (50+) — the default for new or unremarkable accounts
• Caution (30+) — some signals worth watching
• Risk (10+) — meaningful abuse or dispute signals present
• Critical (0+) — the strongest risk signals TrustLens tracks

Every threshold above is the default and fully configurable in Settings, because a 40% return rate might be alarming for one store and unremarkable for another. For the full mechanics, see the customer trust score guide and the segments explained guide. Eight detection modules, working in the background Return abuse. Tracks refund rate, refund value, and refund frequency over time rather than judging any single return in isolation. A customer who returns one order out of twelve looks very different from one who returns three out of four. Order patterns. Watches velocity and behavior across a customer's order history — a signal that's invisible when you're looking at orders one at a time in the WooCommerce admin, but obvious once it's plotted against everyone else's normal buying pattern. Coupon abuse. Catches the two most common ways discount codes get exploited: a "new customer" welcome code used repeatedly from accounts that are really the same person, and coupon codes applied in patterns that don't match organic use. Category-aware risk. Return behavior means something different depending on what's being returned — a high return rate on apparel is often just sizing, while the same rate on electronics or consumables is a different story. This module scores returns in the context of the product category rather than one blanket rule for the whole catalog. Linked accounts. Builds fingerprints from shipping address, billing address, phone number, IP address, payment method, and device user agent, then flags when multiple customer "accounts" share enough signals to plausibly be the same person or fraud ring behind separate identities. This is how TrustLens catches someone opening five accounts to claim five first-order discounts. Shipping anomalies. Flags address-hopping and reshipping patterns associated with stolen-card fraud — an order pattern that looks like it's testing which shipping addresses a stolen card will get through on. Chargeback tracking. Automatically ingests disputes from Stripe and WooPayments the moment they're filed, keeps a running per-customer dispute count, and feeds that history into the trust score, so a customer with two prior disputes isn't treated the same as a first-time buyer. Card-testing defense. Real-time protection against bots that probe your checkout with a rapid burst of small, mostly-declined charges to find out which stolen card numbers are still live. A one-click Panic Freeze button lets you lock down checkout instantly if you spot an attack your automatic thresholds haven't caught yet. Card-testing attacks: what they are and why they cost more than the declines A card-testing attack isn't someone trying to buy from you — it's a bot using your checkout to validate a batch of stolen card numbers before using them elsewhere, firing small charges that just want a "declined" or "approved" answer. Most fail, so the pile of declined orders looks harmless. The real cost shows up sideways: gateway fees on every attempt, a higher fraud score with your payment provider, and — if even a handful of those cards are live — chargebacks landing weeks later with your store's name on them. TrustLens watches decline velocity per device in real time, matching on both the browser fingerprint and a server-side fingerprint (IP and user agent) so a bot can't dodge detection by rotating its browser signature. When a device crosses your threshold, it's locked out of checkout automatically — before the attack reaches your gateway, runs up fees, or produces a chargeback down the line. VIP Customer Bypass is on by default, so real repeat customers are never caught in a velocity rule meant for bots. Full mechanics are in the card-testing defense docs. The Command Center dashboard One screen shows your store's health score, trust-score trends, the six-segment distribution, your high-risk list, and a chargeback-ratio speedometer benchmarked against Visa, Mastercard, Amex, and Discover monitoring thresholds — so you can see a dispute problem building before it triggers a monitoring program, not after. Chargebacks: seeing the ratio before the card networks do Visa, Mastercard, Amex, and Discover each run monitoring programs that watch your chargeback ratio — disputes as a percentage of transactions — and enroll merchants who cross a threshold into a program with extra fees, extra scrutiny, and in bad cases the threat of losing processing entirely. Most merchants only learn the exact numbers when their processor emails them: Visa's VFMP sits at 0.65%, Visa's VDMP at 0.9%, Mastercard's ECP at 1.5%, and Amex and Discover's excessive-dispute programs at 1.0%. TrustLens captures the card brand on every Stripe and WooPayments order and tracks how many end up disputed, so your blended monthly ratio shows up on the dashboard as a speedometer — Healthy, Approaching, or Action-needed — measured against those same four thresholds. The point isn't to replace your processor's own monitoring; it's to give you the same number they're watching, weeks before a threshold crossing becomes a phone call. See the chargeback speedometer and ratio thresholds guide and the Stripe chargeback tracking guide for the full picture. How TrustLens compares Your payment gateway scores the transaction — the charge itself, at the moment it happens. It's genuinely good at catching an obviously stolen card, but has no memory of what that customer did last month and no way to connect two "different" accounts placing suspiciously similar orders. TrustLens scores the customer, over time, using exactly the signals a per-transaction check can't see. A simple IP blocklist stops a known-bad address and nothing else — it doesn't adapt when someone switches networks, doesn't know a "new" account is really a repeat offender, and does nothing for friendly-fraud chargebacks or return abuse, since those orders come from real cards on real networks. See the IP blocking vs. behavioral fraud scoring comparison for where each approach holds up and where it doesn't. For specific alternatives, see FraudLabs Pro vs. TrustLens and TrustLens vs. WooCommerce's built-in anti-fraud tools. Meet the customers TrustLens catches The serial returner — sends back a third or more of what they buy; no single return looks wrong, the pattern across a dozen orders does (Return Abuse + Category-Aware Risk). The coupon farmer — a "new" account every few weeks for the same first-order discount, connected by Linked Accounts and flagged by Coupon Abuse. The fraud ring — one billing address, payment method, or device spread across several names, surfaced automatically by Linked Accounts. The card-testing bot — dozens of small, mostly-declined charges hunting for live stolen cards; Card-Testing Defense locks it out before it reaches your gateway. Integrations and compatibility TrustLens sits inside the store you already run. Stripe and WooPayments disputes are ingested automatically — no webhook setup required; other gateways (PayPal, Square, offline) use a manual chargeback form on the order screen. Both Classic and WooCommerce Blocks checkout are enforced, so a blocked customer is blocked either way. TrustLens declares full WooCommerce HPOS compatibility, supports GDPR data export and erasure via standard WordPress privacy tools, and includes a REST API for looking up customers, scores, and segments, and for triggering recalculations. Pro adds signed webhooks for pushing trust events to Slack, Zapier, or your own tools — see the webhooks and REST API integration guide. Already have order history? Historical Sync builds trust profiles from your existing orders in small background batches, so you're not starting from a blank slate. Details in the Historical Sync guide. You stay in control TrustLens never auto-blocks a single customer in the free version. It surfaces the risk; you decide — block at checkout, allowlist forever, or just watch the trend. Every score, badge, and detection module is visible and adjustable from Settings. Privacy is built the same way: everything runs inside your own store, customer identifiers are pseudonymized with keyed HMAC-SHA256 (not reversible, not portable to another site), and no customer data is ever sent to a third party by default. Free — the complete detection plugin

• All 8 detection modules — return abuse, order patterns, coupon abuse, category-aware risk, linked accounts / fraud rings, shipping anomalies, chargeback tracking (auto-ingest from Stripe & WooPayments), and real-time card-testing defense with a one-click Panic Freeze
• Trust scoring engine — 0–100 score, six segments, every signal visible on the profile, an account-age bonus for established customers, fully configurable thresholds
• Command Center dashboard — score trends, segment distribution, high-risk list, and a chargeback-ratio speedometer (Visa / Mastercard / Amex / Discover)
• Customer management — trust badges on the orders list, detailed profiles, bulk actions, allowlist protection, checkout enforcement (Classic + Blocks)
• Operational — Historical Sync, REST API, HPOS support, GDPR export/erasure, core email notifications

Pro — act on what TrustLens finds Advanced Chargeback Monitor and Dispute Evidence Reports. Where the free speedometer shows your blended ratio, Pro breaks it down per card brand against Visa VDMP/VFMP, Mastercard ECP, Amex, and Discover, adds a 12-month trend chart and a dispute-deadline worklist, and generates a representment-ready Dispute Evidence Report that matches the disputed order against the customer's prior order history and flags whether it qualifies for Visa Compelling Evidence 3.0. Each report carries a tamper-evident fingerprint and QR code so a card issuer can independently verify it's genuine at a neutral domain. See the dispute evidence report guide. Automation Rules. Build if-this-then-that logic on everything TrustLens detects: 15 triggers (score changes, new orders, refunds, disputes, linked-account detections, card-testing attacks, and more), 30-plus condition fields, and actions like blocking a customer, holding an order, sending an email, firing a signed webhook, allowlisting, cancelling, or tagging. A save-time validator catches rules that could never fire before you save them, and an inline inspector shows exactly why each rule did or didn't trigger. See the automation rules playbook. Card-Testing Defense Pro. Adds auto-escalation for attacks that outpace your base thresholds, a geo-diversity safeguard so a flash-sale traffic spike isn't mistaken for a bot, fingerprint and IP-range allowlists, full attack history, and Slack or email alerts the moment a lockdown triggers. See the card-testing auto-escalation guide. Payment Method Risk Controls, Scheduled Reports, and more. Restrict specific payment methods for risky segments without locking a customer out of checkout entirely, receive daily, weekly, or monthly trust-intelligence summaries by email, and get advanced notification types beyond the free version's core alerts. See the scheduled reports guide. Bottom line: Free surfaces the risk. Pro acts on it. Getting started Install TrustLens and open TrustLens → Dashboard. All 8 detection modules and card-testing defense are already running with sensible default thresholds — there's nothing to configure before it starts working. If you have existing orders, Run Historical Sync to build trust profiles from that history in the background. Full steps are in the Installation section below, or the getting-started guide with screenshots. Docs & resources

• Getting started with TrustLens
• How TrustLens scores a customer
• The 8 detection modules, explained
• Card-testing defense docs
• Chargeback Monitor docs
• Why TrustLens Free never auto-blocks
• Free vs Pro, in detail
• Full changelog

Who it's for If your store has outgrown "just watch the orders list" — because refunds are eating margin, a coupon code is circulating somewhere it shouldn't, or you've had a chargeback ratio scare — TrustLens gives you the visibility to catch it early and the control to act on your own terms — starting with the order history your store already has. More from Webstepper TrustLens protects your revenue; Smart Cycle Discounts grows it — scheduled BOGO, bulk, tiered, and coupon campaigns for WooCommerce, with Cycle AI to build the deal from a plain-English description. Built and supported by the same team.

1. Install TrustLens directly from the WordPress plugin repository, or upload the trustlens folder to /wp-content/plugins/
2. Activate the plugin through the Plugins menu — TrustLens checks for WooCommerce automatically
3. Open TrustLens → Dashboard to see the Command Center
4. Click Run Historical Sync to build trust profiles from your existing WooCommerce orders — the sync runs in the background in small batches and does not affect site performance
5. Visit TrustLens → Settings to adjust scoring thresholds, checkout blocking, and notification preferences

What works out of the box:

• All 8 detection modules are enabled by default
• Card-Testing Defense ships enabled with sensible thresholds — no configuration required to start blocking stolen-card attacks
• VIP Customer Bypass is on, so repeat buyers are never disrupted by velocity rules
• Chargeback tracking is active for Stripe and WooPayments — disputes ingest automatically
• TrustLens does not auto-block any customer in Free until you explicitly choose to

If you use Stripe or WooPayments, no extra setup is required for chargeback and card-brand capture. Other gateways can be tracked through the manual chargeback entry form on the order edit page.

1.3.13

• Fix: Failed payments are now counted across WooCommerce gateways. Card-Testing Defense previously relied mainly on Stripe and WooPayments-specific decline hooks, so gateways without a dedicated adapter could create failed orders without recording the decline. TrustLens now uses WooCommerce's generic failed-order transition as the common fallback, while keeping gateway adapters for the earlier signals they provide.
• Fix: Declines are attributed to the checkout that created the order. Device identity is stamped onto classic and Store API checkout orders before they are saved, and pay-for-order retries refresh the same metadata. Request-scoped attribution replaces the old WooCommerce session handoff, so a stale fingerprint from an earlier cart cannot be attached to an unrelated order.
• Fix: A decline is recorded only once when multiple signals fire. Gateway-specific callbacks and the generic failed-order transition can both report the same payment failure. Per-request deduplication now collapses those signals without suppressing a later retry.
• Fix: Card-Testing status screens now show the module's real state. The Card-Testing page and Command Center report Disabled when protection is switched off instead of presenting live-looking status text and metrics.

1.3.12

• New: Release a held device. Held fingerprints on the Card-Testing page now show how many times each has been caught, with a Release control beside them. Because a repeat offender can now be held for up to 24 hours, this is the way out if a device is caught by mistake — shoppers sharing an office network or a mobile carrier address can look alike to any device signature. Releasing lifts the block, clears the device's strike history so it starts over, and withdraws the card-testing penalty from linked customer trust scores.
• Improvement: Lockout durations are filterable via trustlens/card_testing/lockout_seconds for stores that want a different escalation curve.
• Fix: A device caught card testing more than once is now held for progressively longer. Until now every lockout lasted 90 seconds, no matter how many times the same device had already been caught. An attacker could burn its hourly decline allowance, sit out the lockout, and come back to a counter that had rolled over — so a single device the plugin had already positively identified as hostile could keep pushing failed orders through indefinitely, day after day. Lockouts now escalate with each offense (90 seconds, then 15 minutes, then 1 hour, then 24 hours), which cuts what a persistent device can push through from roughly 190 failed orders a day to around a dozen. A shopper whose card genuinely declines a few times still gets only the original brief pause.
• Fix: Your 24-hour decline and submission figures were roughly double the real numbers. On any store whose shoppers load the device-fingerprint script, each decline was recorded twice — once per device identity — and every store-wide total counted both. That affected the Card-Testing page, the dashboard widget, the module status pill and, on Pro, the hourly attack timeline. The counts are now accurate, so the decline rate you use to decide whether an attack is still running means what it says. Per-device detection thresholds were never affected.
• Fix: Bots that change their device signature on every attempt are no longer invisible to the submission limit. The submissions-per-minute rule counted attempts only against the browser-reported identity, which an attacker can regenerate at will, so the counter never climbed past one and the rule could not fire. Attempts are now also counted against a server-derived identity the attacker cannot choose. This matters most on stores whose payment gateway does not report declines back to TrustLens, where the submission rule is the main line of defense.
• Fix: Top attacking fingerprints no longer misses the worst offender (Pro). A bot that rotates its browser identity accumulates its history under a server-derived one, which the report was not counting — so the single most active attacker on the store could be absent from the list entirely.

1.3.11

• New: Declines in 1 hour — a new Card-Testing threshold, 8 per device by default, that backstops the 60-second rules. Lower it if attacks are still getting through; raise it if real shoppers are being caught.
• Improvement: Velocity counting now runs as a single database query per checkout instead of one per window, so the added hourly check costs nothing on the checkout path.
• Fix: Repeat and slow-paced card-testing attacks are now stopped. A device that simply waited out its 90-second lockdown got a clean slate, because the 60-second decline counter had already rolled past the evidence that triggered it — so a patient bot could keep pushing failed orders through indefinitely. A new hourly decline limit outlives the lockdown, so a repeat offender stays blocked. It also catches the bot that paces itself to stay under the per-minute rules.
• Fix: The pay-for-order checkout route is now protected. Attempts at /checkout/order-pay/ — where an attacker creates a single order and then loops payment retries against it — bypassed every Card-Testing rule. They now pass through the same defense as normal checkout, and their declines are counted against the device making them.
• Fix: The card-testing penalty now reaches trust scores. A customer whose device was caught in an attack was meant to lose 30 points, but the penalty looked for that device under the wrong identity and never applied. Scores now reflect card-testing activity as documented.
• Fix: Card-Testing Defense no longer reads as off while it is running. On installs where the setting had never been written, the dashboard, settings and status screens showed the module disabled even though protection was active.
• Fix: Event cleanup keeps running when the module is switched off. Turning Card-Testing Defense off left its daily purge orphaned, so the velocity event table kept growing instead of honouring your retention window.
• Fix: The flash-sale safeguard now engages (Pro). Auto-escalation's geo-diversity check demanded more distinct countries than an escalation window could ever hold, so it never suppressed anything — meaning a genuine worldwide traffic spike could trip a store-wide panic freeze.

1.3.10

• Fix: Return, dispute, and cancellation rates are now accurate on stores that issue partial refunds or re-complete orders. Each order counts once toward a customer's return rate no matter how many partial refunds it receives, and re-completing an order (or bulk-updating order statuses) no longer inflates their order count. Previously a single order refunded in installments could push a good customer's return rate past 100% and wrongly flag them as a serial returner.
• Fix: Chargeback amounts recorded from WooPayments now show the correct value instead of 100 times too high.
• Fix: Two manual chargebacks recorded in the same moment no longer overwrite each other in the Open Disputes worklist.
• Fix: First-order coupon abuse is judged more precisely. Placing several orders in quick succession — before any of them completes — is no longer mistaken for repeated "first order" coupon use.
• Fix: A customer's cancellation rate is now always shown as a true share of their orders, instead of occasionally exceeding 100%.
• Maintenance: Removed a defunct Stripe webhook hook whose signature no longer matched the gateway; Stripe disputes continue to be tracked through the gateway's dedicated dispute events. Added regression tests covering the refund, order-completion, and coupon counters.

1.3.9

• Fix: Activating TrustLens now dependably opens the TrustLens dashboard. After you finish — or skip — the one-time setup opt-in, you land on the dashboard every time, instead of occasionally being left on the setup screen.
• Maintenance: Updated the bundled Freemius licensing framework to 2.13.4 (routine dependency update, no change to behavior).

1.3.8

• Fix: Dashboard and report time windows now follow your store's timezone consistently. The last-24-hours, hourly, weekly, and trend figures — and the live-activity sparkline — line up with when events actually happened. Previously, on stores whose database runs in a different timezone than WordPress, these windows could be shifted by your UTC offset and the sparkline could drop its most recent hours.
• Fix: Pro high-risk velocity alerts and the weekly/monthly summary emails were counting the wrong time window. On stores set west of UTC, the "several orders in a short window" alert could miss its window entirely and never send; it now measures the correct window everywhere.
• Fix: Automation conditions "customer age (days)" and "days since last order" now measure elapsed time correctly in your store's timezone, so day-boundary thresholds fire when they should.
• Fix: The Card-Testing lockdown status now displays correctly on stores using a persistent object cache (Redis/Memcached). The active-lockdown banner, the "targeted" device list, and the attack-window audit could show empty even while an attack was actively being blocked. Real-time blocking was never affected — only the on-screen status and audit trail.
• Fix: Linked-account detection no longer treats a shared web browser or IP address as proof that two accounts are the same person. Common browsers and shared networks (mobile carriers, offices, households) were creating false links that could lower a genuine customer's trust score or restrict their payment options at checkout. A link now requires a stronger shared signal, such as a matching address, phone number, or payment method.
• Fix: The dashboard "Trust Score Trends" chart now shows real day-by-day history. A customer's daily score snapshot was being overwritten every time their score recalculated, so on active stores the chart could collapse to a single point instead of a trend. Snapshots are now kept per day — earlier days preserved — and old history is tidied up automatically.
• Improvement: Payment-method controls now never remove a customer's every payment option. If your restriction settings would end up disabling all available gateways for a risky customer, TrustLens leaves checkout usable instead of silently blocking the sale (use customer blocking if you want to stop a customer entirely).
• Improvement: Lighter memory footprint on every request. Your automation rules and scheduled-report settings are no longer autoloaded on page loads that never use them; they're read only when actually needed. Existing sites are migrated automatically on update.
• Maintenance: Internal cleanup and restructuring with no change to behavior — removed unused code paths, added a database index that keeps the Trust Score Trends chart fast as history grows, and split the automation engine into focused components (rule validation, condition evaluation, and action execution) for easier maintenance and testing.

1.3.7

• Improvement: The Store Trust Network now withdraws a shared flag. When you win a chargeback, allowlist a customer, or a flagged customer's risk clears, TrustLens removes that customer's flag from your linked stores within the hour — instead of leaving it in place. An allowlisted customer is never shared in the first place. For the complete changelog of earlier versions, visit the full changelog.