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 high return rate pulls it down, 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
• 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

These segment cutoffs are defaults; developers can change them with the trustlens/segment_thresholds filter. Module thresholds, such as the return-rate levels, are adjustable in Settings, because a 40% return rate might be alarming for one store and unremarkable for another. For the full mechanics, see the customer risk scoring 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 alert that appears the moment your ratio crosses a Visa, Mastercard, Amex, or Discover monitoring line. 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 VAMP marks a merchant Excessive at 1.5% in the US, Canada, Europe, Asia Pacific and Latin America (2.2% in CEMEA) and counts fraud reports as well as disputes, Mastercard's ECP starts 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. The free dashboard alerts you as soon as your monthly ratio crosses one of those lines; Pro's Chargeback Monitor shows the ratio for each network against its line, and how far you are from the nearest one, before you get there. The point isn't to replace your processor's own monitoring; it's to give you the same number they're watching. Visa's VAMP ratio also counts fraud reports that never reach WooCommerce, so treat the Visa figure as a floor. See the 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, adjustable module thresholds
• Command Center dashboard — score trends, segment distribution, high-risk list, and a chargeback-ratio alert (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 dashboard alerts you once a line is crossed, Pro shows your ratio for each card brand against Visa VAMP, 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: 16 triggers (score changes, new orders, refunds, disputes, linked-account detections, card-testing attacks, and more), 40-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 WooCommerce customer risk scoring works
• 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 small batches from your browser, so keep the page open until it finishes; it 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.23

• New: Challenge Failed in the rule editor. The trigger added in 1.3.14 could not be chosen when building a rule.
• New: Due dates and outcomes for manual disputes. The manual chargeback form takes a response due date, which puts the dispute in the deadline worklist, and a manual dispute saved as Pending can be marked won or lost on the order screen.
• Change: Visa VAMP replaces VDMP and VFMP. Visa merged its dispute and fraud monitoring programs into VAMP in 2025. The Chargeback Monitor now compares your Visa ratio with VAMP's 1.5% merchant line, which applies in the US, Canada, Europe, Asia Pacific and Latin America from 1 April 2026. Stores in CEMEA, where the line is 2.2%, can change it with the trustlens/chargeback_thresholds filter. VAMP also counts fraud reports that never reach WooCommerce, so the Visa ratio TrustLens shows is a floor.
• Fix: Order Placed rules that hold or cancel an order now wait for the payment. Hold Order, Cancel Order and Require Verification on an Order Placed rule changed the order's status before the gateway charged. With the Checkout block, WooCommerce could then treat the order as needing no payment and move it to processing without charging; with the classic checkout, the payment moved it straight back to processing. The action is now kept on the order and applied once the payment is confirmed, so the order goes to on-hold. A cancel never cancels an order whose payment was taken: the order is held with a note asking you to refund if you cancel it.
• Fix: The Linked Accounts automation condition works. It read a column that always held 0, so rules such as "Linked Accounts greater than 2" never matched. Linked-account counts are now also refreshed on the accounts a customer is linked to.
• Fix: Block linked account coupon abuse works. The Pro setting looked for a shipping-address field that nothing filled in, so it never blocked a coupon. It now uses linked-account matches and the address and phone entered at checkout, so a first-time shopper who shares an address with an account that already used a welcome coupon is refused the coupon.
• Fix: Chargeback ratio alert emails reach stores that activated Pro later. The daily check was scheduled only when the plugin was activated, so a store that entered its Pro license afterwards never received ratio alerts. It is now scheduled whenever Pro is active.
• Docs: The readme and admin text no longer describe a free chargeback-ratio speedometer. The free dashboard alerts you when your ratio crosses a network line; the per-brand view is in the Pro Chargeback Monitor.
• Docs: Corrected the readme on card-testing windows and lockouts, on how new customers are scored before the minimum-order threshold, on segment cutoffs (developers change them with the trustlens/segment_thresholds filter), on the number of automation triggers, and on how Historical Sync runs.
• Docs: Admin help text for VIP customer bypass, checkout blocking and payment controls now matches what the plugin does.
• Docs: The Linked Accounts setting now says accounts are linked by shared addresses, phone numbers and payment methods — a shared IP or browser never links them.

1.3.22

• Update: Updated Freemius SDK to the latest version.

1.3.21

• New: Skip Historical Sync and analyze new orders only. Onboarding offers this beside the sync button when a store has past orders. Past orders can still be imported later with Import past orders.
• Fix: A background job no longer reschedules itself forever on stores without HPOS. On stores that keep orders in the classic posts tables, the one-time email-hash backfill picked up the same 100 orders on every run and queued itself again, adding tens of thousands of Action Scheduler entries an hour. It now works through the remaining orders once and stops; updating restarts it with the fix.
• Fix: Historical Sync no longer runs out of memory on customers with many orders. It loaded a customer's whole order history five times over in one request, so a single address with thousands of orders, such as a marketplace or business account, could exhaust a 256 MB limit and stop the sync. Orders are now read a page at a time, and each customer is profiled once per sync instead of once per batch, which also makes large syncs much faster.
• Fix: Orders from the Checkout block are analyzed at checkout. WooCommerce's Checkout block never fires the hook TrustLens listened for, so on stores using it new orders skipped customer profiling, coupon and category tracking, linked-account fingerprints, automation rules, alerts and the high-risk webhook until their status changed.
• Fix: A retried payment no longer counts an order twice. When a customer retried a failed payment on the classic checkout, the order's events, coupon use and category stats were recorded a second time.
• Fix: Customers with a long address history are no longer penalized right after a sync. Historical Sync dated every past address as first seen on the day it ran, so the address-velocity signals read years of addresses as this month's and took up to 10 points off. Addresses are now dated by the orders that used them, and running the sync again gives the same result.
• Fix: Customers are no longer linked to an account that does not exist. Orders without a billing email were stored under a blank owner, and anyone who shared an address, phone or card with such an order lost at least 5 points for the link. Those records are removed on update and no longer created.
• Fix: Chargeback Monitor per-brand ratios are correct on stores without HPOS. Every card brand was counted against every order, and the card-brand backfill on the monitor page could keep running without end.
• Fix: The review and opt-in notices now appear for stores that never ran a sync. They counted customers from the sync status, so a store profiling customers from live orders stayed at zero.

1.3.20

• New: Customer tags can be removed. A tag can be taken off from the customer profile, applied or removed across a selection from the Customers screen, and removed by an automation rule. Until now a rule could attach a label that nothing could ever take off, so a rule that fired too widely marked those customers permanently.
• Improvement: One set of controls across every screen. Buttons, dropdowns, text and number fields, checkboxes, radios and switches are now defined once, so the same control is the same size, shape and colour whether it appears on Settings, Automation, Customers or the order screen.
• Improvement: Every setting that turns something on or off is now a switch. Nineteen of them were checkboxes, so the same kind of setting looked like a switch on one tab and a checkbox on the next.
• Improvement: Every status label reads the same way. Segment, blocked, allowlisted, module and sync labels were eight separate implementations; they are one now, on a soft ground with text dark enough to read — the previous white-on-colour labels missed accessible contrast.
• Improvement: Settings no longer stacks three rows of navigation. Sections such as Notifications and Scheduled Reports now sit in the page's own header instead of a third strip floating above the content.
• Improvement: Automation reads as a list you can open. Each rule shows its status, what it does, how often it has fired and its Edit and Delete controls in the same place, and opens its detail in line.
• Improvement: Detection Modules and Alerts & Reports lay out evenly. Cards in a row now share a height instead of ending wherever their own text stopped, and the notification list uses the full width of the page.
• Improvement: The dashboard's panels fill their cards. Panels in the same row were stretched to the tallest one and left up to 157px of white beneath their content.
• Improvement: Refund thresholds show their unit as part of the field. The percent sign was a loose character beside the box; it now sits inside the field's own frame.
• Improvement: Return-risk scoring reads the facts the ledger already captured instead of re-opening every order and refund, so score recalculation no longer slows down as refund history grows.
• Improvement: Return rate, refund counters and coupon-then-refund totals each have a single writer, removing the drift that came from several components maintaining the same numbers.
• Improvement: One risk table now decides a refund case's recommendation, risk level, opening status and on-screen name. The five recommendations were previously written out in four places, two of them behind a fallback that hid any disagreement.
• Change: Refunds are recorded whether or not Return Abuse Detection is switched on. The refund ledger feeds dashboards, reporting and Refund Defense, so turning return scoring off now silences scoring only.
• Change: Approving and releasing a refund case require two different people. The approver can no longer release their own case.
• Change: The dashboard says when the automation engine is paused. It reported rules as active whenever the feature was available, so a paused engine still showed active rules and a fire count of zero with nothing to explain it.
• Change: Clicking a TrustLens header tab no longer leaves a blue outline behind it. That ring came from WordPress's own focus style; the header now draws its own, for keyboard use only.
• Fix: The Refund Risk Preview no longer breaks the order screen. Its controls sat in forms nested inside WooCommerce's own order form, which browsers discard, so Update saved nothing and Open refund risk case created no case. The panel now sends its own request and leaves the order form alone.
• Fix: Return rates can no longer exceed 100%. A refunded order now always belongs to the customer's counted order set, so the orders TrustLens counts as refunded are always among the orders it counts, on live stores and historical sync alike.
• Fix: Warehouse inspections accept every condition the screen offers. The refund case screen and the workflow that validates it now share one list, so recording a returned item as opened or used no longer leaves the case unreleasable.
• Fix: A finished refund case no longer blocks later refunds on the same order. Only an open case enforces the workflow; global enforcement is unchanged.
• Fix: The refund-ledger migration can no longer retry a page forever. Retries are bounded, and a page that cannot be reconciled is recorded and skipped instead of rescheduling itself indefinitely.
• Fix: The full-refund rounding tolerance can be adjusted again. The filter that sets it was only read by a helper nothing called, so a refund short by a fraction of a cent was judged against a fixed value no store could change.
• Fix: Deleting the automation rule you have open now moves you on to another. The page was asking a panel that no longer exists whether the deleted rule was the selected one, so the answer was always no and the screen stayed on a rule that had gone.
• Fix: Editing the open automation rule refreshes what it shows. Its trigger, conditions and action kept their pre-save values until the page was reloaded.
• Fix: The Chargeback Monitor no longer stretches down the page as disputes arrive. Its activity feed has no end, and it was setting the height of the whole screen; it now scrolls in place beside the cards that sit next to it.
• Fix: Checked boxes no longer show two ticks, and switches no longer show one. WordPress draws its own tick into every checkbox and did not stop when TrustLens drew its own.

1.3.17

• Improvement: Detection Modules stays compact even on stores with many product categories. Category risk controls now live in a full-width Refunds workspace, so one long module no longer stretches neighboring cards down the page.
• Improvement: Refund protection is easier to operate. Return thresholds, Pro case enforcement, SLA controls and searchable product-category multipliers are now together under Settings → Refunds.
• Improvement: Related settings are grouped by merchant task. Notifications and scheduled reports now share Alerts & Reports, while webhooks, REST API access and Store Network live under Integrations.
• Improvement: Refund Cases now matches the rest of the admin experience. The inbox has the shared TrustLens header, live open-case status and a direct route to refund policy settings.
• Change: All TrustLens navigation now comes from one registry. The WordPress submenu, persistent header and Settings tabs share the same order, labels, visibility and Pro gating, preventing pages from disappearing from one menu while remaining in another.
• Change: The primary menu now prioritizes operational work. Dashboard, Customers, Refund Cases, Chargeback Monitor, Card-Testing Defense, Automation and Settings appear in a consistent sequence.
• Fix: Existing bookmarks continue to work after the reorganization. Legacy Notifications, Reports, Webhooks, API, Store Network and Automation URLs redirect to their new canonical locations.
• Fix: Order trust links now open the intended customer profile. The order column uses the current customer route instead of the retired profile query format.

1.3.16

• New: A canonical refund ledger that counts every refund exactly once. Full, partial, cumulative, edited and deleted refunds are reconciled across WooCommerce admin, legacy storage and REST APIs, preventing duplicate events from inflating a customer's return rate.
• New: Context-aware return-risk intelligence. TrustLens now weighs refund frequency and value together with delivery evidence, timing, repeated reasons, fulfillment state, products and categories, so a thin history does not carry the same confidence as a repeated pattern.
• New: Refund Defense case management for Pro stores. Risky refunds can require manager approval, returned-goods receipt, warehouse inspection, photos, product condition and serial-number evidence before WooCommerce is allowed to issue the money.
• New: A Refund Cases inbox and order-level workflow. Administrators can see the recommendation, SLA, missing obligations, tracking evidence and append-only audit history, then hold, approve, reject or release the case from WordPress.
• New: Safe migration controls. The Data settings screen now shows shadow-ledger progress, parity mismatches and guarded cutover or rollback controls, keeping the legacy view active until migration is complete and unexplained differences are zero.
• Improvement: Refund reporting now distinguishes order return rate from refund activity. Dashboards, customer screens, REST responses, notifications and scheduled reports use consistent weighted store rates and currency-aware refund values.
• Improvement: Billing-email changes no longer leave refund history on the wrong customer. Reconciliation rebuilds both the old and new customer, product and category projections when order ownership changes.
• Improvement: Refund automation has richer, replay-safe context. Rules can use refund amount, type, ratio, reason, product risk and defense recommendation without firing the same automation twice for one refund.
• Update: Tested with WordPress 7.1.
• Fix: Risky refunds can no longer bypass a completed or closed case. The WooCommerce refund gate continues to enforce the order's case history and validates the released amount and original-payment policy.
• Fix: Duplicate tracking and evidence tampering are blocked safely. Tracking checks and case creation are serialized against concurrent requests, while serial requirements remain server-owned and uploaded photo evidence must be a real image attachment.
• Fix: Migration retries cannot skip or double-count pages. Failed ledger writes retry within bounds, stale or future jobs cannot advance checkpoints, and pending comparisons prevent an early cutover.

1.3.14

• New: Browser challenge for checkout, free. An optional Cloudflare Turnstile challenge now runs before any payment reaches your gateway, covering classic checkout, block checkout and the pay-for-order page. It stops the attack pattern threshold rules cannot see: an attacker who presents a fresh identity on every attempt never accumulates the history a counter needs. Turnstile is free, and your site does not need to move its DNS or hosting to Cloudflare.
• New: Challenge only the checkouts that look automated. On the recommended setting TrustLens weighs how much shopping preceded a payment — how long the visitor has been on your store, and whether they built a cart — and challenges only what looks unearned. A customer who browsed, added to cart and filled in the form is never challenged. Two stricter settings are available for use while an attack is live: challenge anyone without a purchase history, or challenge every checkout.
• New: A connection test for your Cloudflare keys. Verification is deliberately built to let checkout continue if Cloudflare cannot be reached, so a Cloudflare outage can never close your store. The trade-off is that a host blocking outbound connections produces a challenge that looks configured but protects nothing. The Test connection button on the Card-Testing Defense page reports exactly that, so a silent misconfiguration surfaces before an attacker finds it.
• New: Challenge failures can drive automation rules (Pro). A failed challenge is now an automation trigger, so Pro stores can alert a channel, block the customer or tag them the first time an unearned checkout is turned away — without waiting for a device to cross a velocity threshold it may never reach.
• Improvement: Browser-challenge setup is now a guided three-step panel. Getting keys from Cloudflare, checking they work, and switching the challenge on are separate steps with their own status, rather than four more rows in the thresholds table. The panel states plainly whether the challenge is set up, ready but not turned on, or running — and says so honestly when Card-Testing Defense itself is switched off, since nothing is enforced in that case regardless of how the challenge is configured. For the complete changelog of earlier versions, visit the full changelog.