TrustLens

Changelog

All notable TrustLens releases from the plugin readme. Track new detection workflows, dashboard improvements, operational fixes, and core platform updates in one timeline.

Version 1.3.21

Latest Release Reliability

This release fixes how TrustLens behaves on large and long-running stores. A background job that could fill the database on stores without HPOS now finishes and stops, Historical Sync stays within memory however many orders one customer has, and orders placed through WooCommerce’s Checkout block are analyzed the moment they are placed.

Added
  • 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.
Fixed
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Version 1.3.20

Release Notes Admin Experience

Every TrustLens screen now uses one set of controls. Buttons, dropdowns, fields, checkboxes and on/off switches are defined once and look and behave the same everywhere, so a setting reads the same way on Refunds as it does on Automation. Alongside that, this release carries the refund-accuracy work from 1.3.18: refunds are counted once, by one component, and the Refund Risk Preview on the order screen saves properly again.

Added
  • 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.
Improved
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
Changed
  • 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.
  • Approving and releasing a refund case require two different people. The approver can no longer release their own case.
  • 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.
  • 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.
Fixed
  • 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.
  • 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.
  • 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.
  • A finished refund case no longer blocks later refunds on the same order. Only an open case enforces the workflow; global enforcement is unchanged.
  • 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.
  • 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.
  • 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.
  • Editing the open automation rule refreshes what it shows. Its trigger, conditions and action kept their pre-save values until the page was reloaded.
  • 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.
  • 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.

Version 1.3.17

Release Notes Admin Experience

TrustLens administration is now organized around the decisions a merchant makes. Refund policy and product-category risk have a dedicated workspace, related alerts and integrations are grouped together, and every TrustLens menu uses one consistent navigation source so new protection tools remain easy to find.

Improved
  • 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.
  • Refund protection is easier to operate. Return thresholds, Pro case enforcement, SLA controls and searchable product-category multipliers are now together under Settings → Refunds.
  • 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.
  • 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.
Changed
  • 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.
  • The primary menu now prioritizes operational work. Dashboard, Customers, Refund Cases, Chargeback Monitor, Card-Testing Defense, Automation and Settings appear in a consistent sequence.
Fixed
  • Existing bookmarks continue to work after the reorganization. Legacy Notifications, Reports, Webhooks, API, Store Network and Automation URLs redirect to their new canonical locations.
  • Order trust links now open the intended customer profile. The order column uses the current customer route instead of the retired profile query format.

Version 1.3.16

Release Notes Refund Intelligence

Returns are no longer just a counter. TrustLens now keeps an idempotent refund ledger, understands partial and cumulative refunds, measures product and customer return risk in context, and gives Pro stores an approval-and-evidence workflow before risky money leaves the business. Existing stores move through a guarded shadow migration with parity checks and rollback instead of an abrupt data switch.

Added
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
Improved
  • 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.
  • 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.
  • 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.
Updated
  • Tested with WordPress 7.1.
Fixed
  • 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.
  • 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.
  • 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.

Version 1.3.14

Release Notes Browser Challenge

Card-Testing Defense could always stop an attacker it could recognise. This release adds one that works when it cannot. Every rule until now counted what a device had done and blocked it past a threshold, which an attacker defeats by changing IP or browser on every attempt — each try arrives as a brand-new visitor with a clean counter. An optional Cloudflare Turnstile challenge changes the question from who is submitting to what the attempt cost, and card testing only pays while attempts are free. It is off by default and, on the recommended setting, invisible to shoppers who actually browsed your store.

Added
  • 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.
  • 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.
  • 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.
  • 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.
Improved
  • 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.

Version 1.3.13

Release Notes Gateway-Agnostic Decline Tracking

Card-Testing Defense now follows a failed payment from checkout to the order that records it, regardless of which WooCommerce payment gateway handled the attempt. That closes the generic attribution gap behind stores seeing failed orders without matching decline activity, while preventing an earlier checkout’s device identity from leaking into an unrelated order.

Fixed
  • 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.
  • 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.
  • 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.
  • 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.

Version 1.3.12

Release Notes Repeat-Offender Lockouts

1.3.11 stopped attacks from getting a clean slate every 90 seconds, but it still let each attacking device through at a fixed rate, hour after hour. 1.3.12 gives Card-Testing Defense a memory: a device caught more than once is held for progressively longer, so a persistent bot runs out of room instead of settling into a steady drip. It also corrects the decline and submission figures you use to judge whether an attack is still live.

Added
  • 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.
Improved
  • Lockout durations are filterable via trustlens/card_testing/lockout_seconds for stores that want a different escalation curve.
Fixed
  • 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.
  • 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.
  • 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.
  • 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.

Version 1.3.11

Release Notes Card-Testing Hardening

1.3.11 closes four gaps in Card-Testing Defense that let a determined attacker keep going: a lockdown that forgot why it fired, a checkout route that was never guarded, a trust-score penalty that never applied, and a Pro safeguard that never engaged.

Added
  • 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.
Improved
  • 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.
Fixed
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Version 1.3.7

Release Notes Store Trust Network

1.3.7 makes the Store Trust Network let go — a shared flag is now withdrawn from your linked stores the moment the risk clears, so the network never keeps a customer flagged after you’ve cleared them.

Improved
  • 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.

Version 1.3.6

Release Notes See the Store Trust Network at work

1.3.6 makes the Store Trust Network visible — flags from your linked stores now appear right where you work — plus clearer plan messaging and a refreshed review prompt.

Improved
  • See the Store Trust Network at work (Pro, multi-site). Flags shared by your linked stores now appear right where you need them: a panel on the customer profile, a line on the WooCommerce order screen, and a new network status + early-warnings summary on the dashboard that surfaces shoppers a sister store flagged before they could build any history with you. The network already protected you quietly in the background — now you can see it doing its job.
Changed
  • Refreshed review request. The occasional review prompt is now an on-brand card with warmer, friendlier wording — the same one-click dismiss and “remind me later” controls, just nicer to look at.
Fixed
  • Clearer plan messaging for single-site Pro. On a single-site plan (for example Starter), the Store Trust Network tab showed a generic “upgrade to Pro” prompt even though you already had Pro. It now correctly points to the Professional and Business plans that include the network, so the path to enabling it is obvious.

Version 1.3.5

Release Notes Store Trust Network

1.3.5 adds the Store Trust Network for owners of multiple stores, plus a lighter WordPress dashboard and two fixes.

Added
  • Store Trust Network (Pro, multi-site). If you run more than one WooCommerce store, link them so a customer who racks up return abuse or chargebacks at one store is automatically recognized at the others. It is opt-in and off by default: generate one secret group key, paste it into each store, and list your store URLs. Stores share flags in the background, so checkout is never slowed or blocked when another store is offline — and no names or email addresses ever leave a store, only an irreversible hashed signal. Your existing per-store data and trust scores are untouched.
Improved
  • Faster WordPress dashboard. TrustLens no longer loads its full admin script and style bundle on the dashboard home screen — only the small stylesheet the Customer Trust widget needs — so the main dashboard stays light for every admin.
Fixed
  • More accurate return-rate scoring. Corrected an off-by-one that slightly skewed every customer’s stored return rate, and the trust signal built from it. Existing customers are recalculated automatically once on update.
  • Removed a WordPress 6.7+ “translation loading triggered too early” notice from the Freemius activation message (it now runs on the init hook), so it no longer shows up in Site Health or debug logs.

Version 1.3.4

Release Notes Activation Fix

1.3.4 is a quick fix for a fatal error that could stop the plugin from activating in some setups.

Fixed
  • Activation no longer fails with a fatal error. In some setups the plugin could stop with a “Call to undefined function” error during activation; the installer now loads its helper functions in the right order before seeding default settings.

Version 1.3.3

Release Notes Free-build packaging fix

1.3.3 is a small packaging hotfix that ensures the free version always ships as free. It includes everything from 1.3.2 — the settings-save fix, streamlined chargebacks, the usage-data opt-in, and the rest.

Fixed
  • Free-version packaging — hardened how the Freemius configuration is packaged so the free build always deploys as the free version. A packaging regression could otherwise leave the free build in licensed/premium mode — prompting for a license key and showing “Sorry, you are not allowed to access this page” on the plugin’s own screens.

Version 1.3.2

Release Notes Settings Reliability & Streamlined Chargebacks

1.3.2 fixes an important settings bug — saving one Settings tab could quietly reset options on the other tabs — and brings every chargeback control together in one place. It also adds a clear usage-data opt-in, makes data removal on uninstall more reliable, and refreshes the plugin’s name to better reflect what it does.

Added
  • Usage-data opt-in — a clear control in Data & Privacy to share anonymous usage data (off unless you opt in), with a one-time, dismissible reminder.
Improved
  • Clearer confirmation-email message after opt-in or activation, so it no longer looks like activation stalled or failed.
Changed
  • Every chargeback control is now in one place. The Chargeback Tracking on/off toggle joins the other detection modules in Settings → Modules, and auto-block, ratio alerts, and dispute-report verification all live on the Chargeback Monitor page. The separate Settings → Chargebacks tab has been removed.
  • Chargeback auto-block now defaults to off. Auto-blocking permanently blocks customers at checkout, so it is now opt-in — set a threshold on the Chargeback Monitor when you want it. Stores that already configured it keep their setting.
  • More reliable data removal on uninstall. When “remove data on uninstall” is enabled, TrustLens now clears all of its data through a single prefix contract so nothing is left behind, and the redundant “Delete All TrustLens Data” button has been removed (uninstall and the Data tab cover it).
  • Renamed to TrustLens – Fraud Prevention & Chargeback Defense for WooCommerce to better reflect what the plugin does. No settings or data change.
Fixed
  • Saving one Settings tab no longer resets the others. Previously, saving a tab (for example General) could silently wipe or reset options that live on other tabs — detection modules, chargeback thresholds, webhook events, scheduled-report recipients, and more. Each Settings form now saves only its own options.
  • Long device-fingerprint hashes no longer overflow the “Targeted now” list in the Card-Testing attack feed.

Version 1.3.1

Release Notes Reliability & Polish

1.3.1 restores the Chargeback Tracking module to the free version — recent free builds had unintentionally left it out, so free stores again get per-customer dispute tracking and the blended chargeback-ratio speedometer. It also polishes the activation and account screens and hardens how the free and Pro builds are packaged so a free feature can’t go missing again.

Improved
  • Clearer, privacy-first wording on the activation and license screens — a reminder that TrustLens never sends your customer, order, or payment data — with the TrustLens icon now shown on them.
  • The Account screen now carries an on-brand TrustLens panel with quick links to your dashboard, documentation, and support.
  • Activating the Pro version now automatically deactivates the free version (and vice-versa), preventing duplicate-plugin conflicts and stray PHP notices when both are installed.
Changed
  • Hardened the free/Pro build pipeline — a single source of truth now controls which files are Pro-only, and an automated pre-release check verifies every build, so a free feature can’t be dropped (or Pro-only code shipped to free users) by mistake.
Fixed
  • Chargeback Tracking restored on the free version — free stores again get per-customer dispute history and the blended chargeback-ratio speedometer on the dashboard. A packaging error had unintentionally left this module out of recent free builds; Pro stores were unaffected.

Version 1.3.0

Release Notes Verifiable Evidence

The centerpiece of 1.3.0 is the new Chargeback Evidence Report (Pro) — a representment-ready document that builds your Visa Compelling Evidence 3.0 case automatically and, uniquely, lets a card issuer independently verify it as genuine and unaltered at a neutral domain: every report carries a tamper-evidence SHA-256 fingerprint, a scannable QR code, and a public verification page. It’s rounded out by a broad reliability and accuracy pass across scoring, reporting, chargebacks, automation, and the dashboard.

Added
  • Dispute evidence report (Pro) — the chargeback dispute report is now a representment-ready evidence document. It matches the disputed order against the customer’s prior orders by shared identifiers (billing/shipping address, device, IP), flags history that qualifies for Visa Compelling Evidence 3.0 (two or more shared identifiers from an order 120–365 days before the dispute), and summarizes the continuity you can submit to fight the chargeback.
  • Independent report verification (Pro) — every evidence report carries a unique fingerprint, report ID, a verification link and a scannable QR code that take a card issuer straight to webstepper.io/verify to confirm the report is genuine and unaltered. The report confirms on-screen whether it registered (and retries automatically in the background if the service can’t be reached), and the Chargeback Monitor’s open-disputes list flags which reports are registered. Only a one-way fingerprint and non-personal figures are sent — never customer data — and it can be switched off in Settings → Chargebacks.
Improved
  • All CSV export paths (admin and scheduled/bulk) neutralize spreadsheet formula injection by escaping cells that begin with =, +, –, @, tab or carriage return.
Updated
  • Updated the Freemius SDK to 2.13.2, hardened webhook-log pruning and card-testing alert scheduling, and stopped an internal scoring snapshot row from appearing in customer signal lists.
Fixed
  • Card-brand detection now reads nested Stripe dispute payloads correctly, so disputes are attributed to the right brand (Visa/Mastercard/Amex/Discover) and your chargeback ratios are accurate instead of landing in “unknown”.
  • Dispute updates from a payment gateway no longer overwrite stored details — a status-only update can’t zero out a dispute’s amount or reopen a dispute you’ve already closed.
  • Disputes resolved through the alternative Stripe integration now clear from the Open Disputes worklist instead of lingering as falsely “overdue” and inflating the dashboard’s due-soon count.
  • Monthly ROI and protection figures now report each calendar month’s own data instead of repeating the current rolling window for every past month.
  • Weekly and scheduled reports now use the correct time window and send time on stores not set to UTC, instead of being offset by the site’s timezone.
  • Recalculating a customer’s trust score via the REST API now triggers your automation rules, notifications and webhooks, matching the in-app and bulk recalculation.
  • Customer segments are assigned correctly even when the segment-threshold filter returns a partial set, and the high-risk list and dashboard counts now refresh promptly after changes such as allowlisting.
  • The “New Risky Customer” email now alerts only on a genuine first-time customer, and first-order coupon-abuse detection no longer misflags a returning customer’s second order as their first.
  • Repeat-refunder and velocity alerts now fire when a count jumps past the threshold (not only when it lands exactly on it), once per pattern without spamming.
  • Risk signals in the evidence report now show refund and customer-value amounts as clean currency (e.g. $2,429.00) instead of raw price markup.
  • Automation email actions fall back to the site admin address when no notification email is configured; bulk actions for remove-from-allowlist, remove-tag and export now run instead of being silently marked complete; and the Historical Sync panel and REST statistics endpoint report accurate values.

Version 1.2.8

Release Notes Walkthrough

See TrustLens in action — the plugin page now features a full video walkthrough of how TrustLens scores every customer and catches abuse, alongside refreshed store artwork. No functional changes to the plugin in this release.

Added
  • Video walkthrough — a short explainer showing how TrustLens turns real shopping behavior into a 0–100 trust score and surfaces returns, coupon, linked-account and card-testing abuse, now on the plugin page.
Updated
  • Refreshed the plugin banner artwork.

Version 1.2.7

Release Notes Automation

Automation you can rely on — the rule engine now fires when it should, blocks first-time card-testers, holds orders for verification, counts webhook deliveries honestly, and gains ten new conditions (including a skip-allowlisted-customers guard) — plus a new dispute-deadline worklist so chargeback responses never slip past their window.

Added
  • Dispute deadline worklist on Chargeback Monitor — every open dispute with its response deadline and a live countdown, plus a due-soon count on the dashboard, so a chargeback response window never slips past you.
  • Ten new automation conditions — write rules on full and partial refunds, coupons used, first-order coupons, disputes won and lost, order edits, reviews-before-refund, and whether a customer is allowlisted or flagged.
  • Skip trusted customers — rules can now exclude allowlisted buyers with an is_allowlisted condition, so blanket rules don’t catch the people you’ve already vouched for.
  • Flagged for review is now a real customer status — the Flag action shows a badge, adds a filter on the Customers screen, and clears in one click, instead of leaving a note nobody could find.
Improved
  • Automation Add Tag now writes a real customer tag — visible on the customer page and removable in bulk — instead of a hidden note.
Fixed
  • Rules that quietly never fired now fire — first-order rules at checkout, and card-testing blocks against brand-new attacker emails, now work as configured.
  • Require Verification now actually holds the order for review (and flags it) instead of doing nothing.
  • Webhook activity is counted honestly — each delivery counts once (queued, then delivered or failed) instead of logging both a success and a failure for the same call, and queued deliveries are properly cancelled when the plugin is deactivated.
  • Allowlisting a customer now clears any review flag, so a trusted customer can’t stay flagged.
  • The rule builder no longer rejects valid rules — mixing 1 and true on a yes/no condition, or upper- and lower-case country codes, is understood correctly.
  • Choosing to remove all data on uninstall now also drops the disputes table, and automation log cleanup keeps running even after a Pro license lapses.

Version 1.2.6

Release Notes Usability

A friendlier cockpit — TrustLens now guides you to the right action, remembers your choices, and explains itself in plain language, so protecting your store takes fewer clicks and less guesswork.

Added
  • Quick Start setup card on the dashboard — three guided choices (block risky customers, email alerts, import past orders) get a new store protected without hunting through settings.
  • Block reason picker — when you block a customer you can record why, from a preset or your own note; it’s saved to the customer’s notes and history so you keep an audit trail.
  • Plain-language score summary on each customer — see at a glance what’s weighing a score down and what’s in their favour, instead of decoding raw signal bars.
  • Segment glossary and inline help — a built-in legend for VIP through Critical with their score bands, plus ? tips that explain terms like “fingerprint” right where you need them.
  • Recommended next actions on the dashboard and Card-Testing Defense — each screen now tells you what to do, not just what’s happening.
Improved
  • Customer actions no longer reload the whole page — block and unblock update in place with a confirmation toast, and allowlist or recalculate keep your scroll position so you never lose your place.
  • Panic Freeze remembers your chosen duration instead of resetting to 15 minutes each time, and the misleading “1 hour” option (which the server capped at 30) has been removed.
  • Card-Testing Defense is now discoverable as the 8th detection module from the Modules tab in Settings.
  • Signal explanations on the customer page are now keyboard-accessible, not hover-only.
Fixed
  • The Automation tab now shows consistently in the in-app header, matching the WordPress admin menu.

Version 1.2.5

Release Notes Visual Refresh

Dashboard visual refresh — every chart now reads as one product. All eight charts across the dashboard, Chargeback Monitor, and Card-Testing Attack History repainted in the TrustLens emerald palette to match the website, with softer tooltips, smoother lines, and proper empty states.

Changed
  • All dashboard charts repainted in the TrustLens emerald palette to match the website — Trust Score Trends, Segment Distribution, Refund Activity, Hourly Activity, Category Returns, Monthly Protection, the Chargeback Monitor 12-month trend, and the Card-Testing Defense Attack History timeline. Replaces the previous mix of Bootstrap red/orange/green and a stray purple that had drifted in over earlier releases.
  • Chart tooltips switched from black bubbles to light cards with subtle slate borders and softer typography so they no longer overpower the data.
  • Line charts now use thinner 2px strokes with smoother curves and gradient fills that fade fully to transparent; bar charts have rounded 6px caps.
  • Snappier 600ms entry animation (was the Chart.js 1s default).
  • Hourly Activity chart now uses an emerald intensity gradient (low → slate, high → emerald) instead of a purple-to-violet ramp, so quiet hours read as quiet and busy hours pop.
  • New shared chart-theme.js module — every chart in the plugin pulls from one palette, so future charts pick up the same identity automatically.
Fixed
  • Segment doughnut’s “X customers” total now sits on the actual ring center. Previously, the bottom-positioned legend pushed the doughnut up but the label kept dividing the full canvas height in half, landing the text below the ring.
  • Segment-doughnut legend markers (VIP / Trusted / Normal / Caution / Risk / Critical) now render as perfect circles instead of slightly-oval boxes.
  • Empty charts now show a quiet “No data yet” message instead of a blank canvas, so a fresh install doesn’t look broken before any orders have been scored.

Version 1.2.4

Release Notes Blocks Checkout Fix

Card-Testing Defense false-positive fix and WordPress 7.0 compatibility. Stops legitimate shoppers from being locked out of WooCommerce Blocks checkout during normal cart activity.

Fixed
  • Card-Testing Defense was incrementing its decline counter on every Store API cart write — add-item, update-item, apply-coupon, select-shipping-rate, update-customer — not only on actual payment submissions. A normal shopper rapidly adjusting quantities or applying a coupon in a Blocks cart could cross the 10-submissions-per-60s threshold and lock themselves out for 90 seconds.
  • The request gate now carries an explicit intent field populated from the route — the velocity recorder only counts true checkout submissions, and the card-testing module short-circuits on cart writes (which also removes two unnecessary COUNT(*) queries from every cart click).
  • The email blocklist continues to fire on cart writes per the 1.3.0 design — known-bad customers still cannot add items to cart. No configuration change required; existing thresholds keep working but are now fed only real payment attempts.
Compatibility
  • Tested up to WordPress 7.0 (“Armstrong”). Full audit completed across PHPMailer 7.0.2, Backbone 1.6.1, CodeMirror v5 / Espree, Interactivity API state.navigation deprecation, Block API version, Block Hooks REST move, REST permission_callback coverage, early-init translation, and PHP-8 deprecation surfaces. No plugin changes were needed for 7.0.

Version 1.2.3

Release Notes Security & Reliability

Security and reliability hardening. Closes a Card-Testing Defense bypass via fingerprint rotation, an IP-spoofing path through X-Forwarded-For, a webhook secret exposed in the DOM, and several race conditions in the score-update and chargeback paths.

Fixed — Security
  • Card-testing defense bypass via client fingerprint rotation. Bots rotating their JavaScript-side fingerprint per request avoided the per-fingerprint velocity threshold. Declines are now also recorded under the server-fallback fingerprint (IP + User-Agent + Accept-Language) — the velocity detector accumulates and targets even rotating attackers.
  • VIP bypass too permissive in Card-Testing Defense. Previously, any customer with at least one completed order was permanently exempt from card-testing velocity blocks. The threshold now matches the plugin-wide trustlens_min_orders setting (default 3 orders), and customers in risk or critical segments no longer bypass card-testing defense regardless of order count.
  • IP spoofing via forwarding headers. HTTP_X_FORWARDED_FOR and HTTP_CLIENT_IP were trusted unconditionally. Both code paths now default to REMOTE_ADDR; sites legitimately behind a trusted reverse proxy can opt in via the new trustlens/trust_proxy_headers filter.
  • Webhook signing secret exposed in DOM. The Pro Webhooks “Test” button rendered the signing secret as a data-secret HTML attribute, readable by any browser extension or XSS payload. The secret is no longer rendered to the page.
  • Dispute Report didn’t validate the hash format. $_GET[‘hash’] is now checked against wstl_is_email_hash() before lookup.
  • Webhook endpoints option marked autoload=no. Endpoint config (including plaintext HMAC signing secrets) is now loaded only when a webhook needs to fire.
  • Panic Freeze duration ceiling. Server-side ceiling is now 30 minutes by default, filterable via trustlens/card_testing/panic_max_duration.
Fixed — Reliability
  • Chargeback meta now HPOS-compatible. Manual chargeback writes switched from update_post_meta() to WC_Order::update_meta_data() so the chargeback indicator and Record Manual Chargeback form work correctly on HPOS stores.
  • Webhook async dispatch could pile up duplicates on rapid identical triggers. Now dedup’d via wstl_ensure_single_action; retries still bypass dedup so failed deliveries get their 60s / 120s / 240s attempts.
  • Score-update queue race. Read-then-write pattern that could double-schedule recalculation under concurrent events is now race-free via unschedule-then-schedule semantics.
  • Chargeback record double-increment under concurrency. Two separate UPDATEs replaced with a single atomic UPDATE when the outcome is known at record time.
  • Shipping anomaly re-entrancy. The trustlens/shipping_anomaly action and address_anomaly_detected event now fire once from handle_order_completed, not from every score recalculation.
  • Lockdown targets transient race. Switched from one shared transient map to one transient per fingerprint so concurrent target writes never conflict.
  • Cron reconciliation on every page load. ensure_notification_schedules() now self-throttles to once per hour, with explicit invalidation on notification-setting changes.
  • Automation customer_age_days / days_since_last_order timezone drift. Both sides now anchor to UTC, eliminating up to ±14 hours of drift on non-UTC sites.
Fixed — Activation & Onboarding
  • Card-Testing Defense not actually enabled by default. The readme advertised “ships enabled with sensible thresholds” but the activation flow never set the trustlens_module_card_testing_enabled option. New installs now enable card-testing defense and the VIP customer bypass automatically; existing sites keep their current values.
  • Welcome email never sent on default-off installs. The 24-hour-post-activation welcome summary was gated behind the master notifications switch (which ships disabled). It is now gated only by its own opt-out, so the onboarding email actually fires.
  • Plugin row “Dashboard” / “Settings” shortcuts added to the Plugins screen, matching standard WordPress plugin UX.
  • Dashboard onboarding card now signals active protection — a small pill next to the onboarding steps confirms detection modules are already scoring incoming orders.
Changed (Potentially Breaking for Webhook Receivers)
  • Webhook signature scheme v2. Outgoing webhook signatures now cover timestamp + ‘.’ + body instead of body alone, with a new X-TrustLens-Timestamp header carrying the Unix epoch. Receivers can now reject replayed deliveries. Verification: compute ‘sha256=’ + hmac_sha256(timestamp + ‘.’ + body, secret) and constant-time-compare against X-TrustLens-Signature. Update existing webhook receivers before upgrading.

Version 1.2.2

Release Notes Automation Rewrite

Automation Rules — reliability rewrite and major capability expansion. Plus Card-Testing Defense admin UX consolidation and a persistent plugin-wide admin header.

Added
  • Five new automation triggers — Chargeback Filed, Dispute Recorded, Linked Accounts Detected, Card-Testing Attack, and Shipping Anomaly.
  • Fourteen new condition fields including total order value, total disputes, linked accounts, customer age, payment method, country mismatch, and coupon total.
  • Two new actions — Allowlist Customer and Cancel Order — for expressive automation workflows.
  • Save-time rule validator that blocks rules which can never fire, with a specific inline reason per failed condition or action.
  • Rule inspector now shows SKIP status with the reason — answering “why didn’t my rule fire?” in one glance.
  • Dashboard alert band for active Panic Freeze, targeted lockdowns, and card-network programs over chargeback threshold.
  • Module-status pill row on the dashboard — on/off plus one stat for each subsystem.
  • Persistent plugin-wide admin header with unified nav, live status pill, notifications bell, and ⌘K command palette.
Changed
  • Webhooks now dispatch async with automatic retry (60s / 120s / 240s backoff) and are HMAC-SHA256 signed by default.
  • Rule editor no longer full-page reloads on save or delete — errors appear inline inside the modal.
  • Card-Testing Defense page consolidated from four tabs into a single live view — panic controls, live state, and targeted fingerprints visible without clicking.
Fixed
  • Concurrent rule saves were last-write-wins — now serialized via an advisory lock.
  • A failed action used to lock the rule out for an hour via cooldown — now clears on error so the next event retries.
  • Rules with an unknown condition field silently matched everything; now rejected at save time.
  • Timezone drift between log timestamps and inspector counters when MySQL server TZ ≠ site TZ.
  • Operators <, <=, and <> couldn’t save at all.
  • “Send Email” action now honors the recipient field as a per-rule override.
  • “Refund Processed” trigger silently dropped order context — order-only actions and conditions now fire on refunds.
  • Card-testing attacks with an identifiable customer email now fire trustlens/checkout_blocked so notifications, automation, and webhooks can react.
  • Unchecking “Enable Card-Testing Defense” or “VIP bypass” didn’t save (Settings API checkbox quirk).
  • Slack webhook delivery failures are now logged instead of swallowed.
  • Uninstall clears card-testing options and cron hooks; deactivation unschedules card-testing crons.

Version 1.2.1

Release Notes Chargeback Monitor

Chargeback Ratio Monitor — new feature. Track your store’s chargeback ratio against Visa, Mastercard, Amex, and Discover monitoring thresholds at a glance.

Added (Free)
  • Dashboard Chargeback Ratio speedometer — blended calendar-month ratio with Healthy / Approaching threshold / Action needed status.
  • Chargeback tracking moved from Pro to Free — automatic dispute ingestion from Stripe and WooPayments, per-customer dispute counters, and chargeback impact on trust scores now ship in every build.
  • Manual chargeback entry form on the order edit page for gateways that don’t push dispute webhooks (PayPal, Square, offline).
  • Automatic card brand capture on Stripe and WooPayments paid orders. Historical Sync also captures card brand.
Added (Pro)
  • Dedicated TrustLens → Chargeback Monitor page with per-brand ratio breakdown (Visa VDMP/VFMP, Mastercard ECP, Amex, Discover), threshold progress bars, 12-month trend chart, recent disputes feed, top-disputed customers, and one-click Dispute Evidence Report.
  • Daily email alert when any card brand reaches a configurable percent (default 70%) of its network threshold. Deduplicated per brand per calendar month.
  • Trailing-30-day ratio window alongside the Free calendar-month view, plus customizable warn-threshold percent (50–100%).
  • Auto-block after N lost disputes is now actually enforced (the setting has existed since 1.2.0 but had no runtime effect until this release).
Fixed
  • Bulk customer actions (block, unblock, allowlist, recalculate, delete) no longer fail with a fatal error — AJAX handler now dispatches directly to the correct static methods with a whitelisted action set.
  • Chargeback Monitor ratio and trend queries are now transient-cached (15 min / 1 hour TTL) with automatic invalidation on new disputes, so the dashboard doesn’t re-query order meta on every page load.

Version 1.2.0

Release Notes New Module

Shipping Address Anomalies — new detection module. Detects address hopping, billing/shipping country mismatches, and address change velocity. Plus a redesigned Customer Detail Analyst Grid.

Added
  • Shipping Address Anomalies detection module — address hopping, country mismatches, and address change velocity signals.
  • Address diversity ratio scoring — penalizes customers who ship to many different addresses relative to order count.
  • Configurable velocity window setting (7–90 days, default 30) in Settings → Modules.
  • Pro: address diversity trend analysis and enhanced country-mismatch severity.
  • Customer Detail Analyst Grid — redesigned profile with trust score gauge, signal impact bars, return rate trend chart, activity feed, linked accounts, and collapsible admin notes.
  • Weekly return rate trend data with 1-hour transient cache for the customer profile chart.
Fixed
  • Action Scheduler runaway loop on the email-hash backfill — scheduling is now idempotent and race-free; failing orders are tagged with a sentinel so one bad row can’t block backfill forever.
  • Shipping anomalies country-code backfill silent-skip loop — unresolvable rows now get a sentinel value and the batch runner terminates cleanly on all failure modes.
  • Historical sync no longer hangs in “running” state when a single malformed order throws — transitions to a terminal “failed” state so the user can retry from the UI.
  • Customer lookup now accepts legacy 32-char MD5 hashes alongside the current SHA-256 format for backward compatibility.
  • Reset data now succeeds on free installs that don’t have Pro-only tables.

Version 1.1.8

Release Notes Maintenance
Fixed
  • Prevented excessive Action Scheduler task accumulation so order meta saves no longer trigger unnecessary WooCommerce analytics reimports.
Added
  • Daily cleanup of completed Action Scheduler actions older than 7 days to keep the database lean.
Updated
  • Freemius SDK updated.

Version 1.1.7

Release Notes Pro Feature
Added
  • Pro one-click Dispute Evidence Report for professional, print-ready behavioral risk reports in payment processor dispute responses.
  • “Dispute Report” button on the customer profile page and order metabox for instant report generation.
  • Report output now includes trust score, risk signals, order history, return analysis vs store average, linked accounts, and the full event timeline.
  • Extensible action hooks trustlens/customer_profile_actions and trustlens/order_metabox_actions for Pro feature buttons.

Version 1.1.6

Release Notes Orders UI
Added
  • Color-coded trust segment badge column on the WooCommerce orders list for at-a-glance risk review during order processing.
  • Segment filter dropdown on the orders list for Critical, Risk, Caution, Normal, Trusted, and VIP customers.
  • Sortable trust column so merchants can sort orders by segment severity with Critical customers first.
  • Trust badge now links directly to the TrustLens customer profile for one-click access to full behavioral history.
  • Automatic _trustlens_email_hash order meta storage with Action Scheduler backfill for existing orders.
Improved
  • Unscored customers display a “New” badge, while safe segments use muted styling so risky orders stand out faster.

Version 1.1.5

Release Notes Platform Update
Added
  • Shared TrustLens mail sender with recipient validation, structured error capture, and rolling email delivery logs.
  • Keyed HMAC-SHA256 hashing for customer identifiers and linked-account fingerprints.
Changed
  • Refreshed the WordPress.org title, description, FAQs, and search-focused copy around customer risk, abuse detection, disputes, and chargebacks.
  • Split the admin controller into focused pages, settings, notices, and AJAX service classes for cleaner maintenance.
Fixed
  • Welcome summary is now marked sent only after successful delivery and can retry after transient mail failures.
  • Test notification now uses the same delivery path as real emails and surfaces detailed mailer errors when available.
  • Scheduled reports now honor weekly and monthly recipient settings, support comma-separated recipients, run at the configured due time, and include a working manual send path.
  • Stored scheduled reports now track real per-recipient delivery results, retry failed sends, and avoid false-positive sent logs.
  • Privacy export and erasure now include signals, linked-account fingerprints, category stats, and automation logs.
  • Automation actions now write canonical action IDs and analytics/ROI reporting reads the correct action names.
  • Customer blocking now logs customer_blocked events consistently so reports and event-based metrics stay accurate.
  • Customer state changes now use consistent canonical events and webhook wiring for blocked, unblocked, and allowlisted flows.
Improved
  • Notification and report cron hooks are now reconciled during runtime, cleared when disabled, and cleaned up correctly on uninstall.
  • Reset and customer delete flows now clear all related operational data, logs, and derived records consistently.
Removed
  • Removed the TrustLens-specific auto-update notice and one-click auto-update toggle so updates are managed only through standard WordPress controls.
  • Removed remaining active md5() usage from plugin code, replacing it with SHA-256 for internal dedupe keys.

Version 1.1.4

Release Notes Dashboard
Added
  • Polished empty-state UI for Trust Score Trends, Refund Activity, Activity by Hour, and Protection Trend when dashboard data is unavailable.
Fixed
  • Historical Sync completion summary now reports the actual profiled customer count from the TrustLens customer table.
  • Dashboard health attention messaging now aligns with actual risk-customer counts.
Improved
  • Historical Sync backfill now reconstructs historical events with original timestamps and keeps rebuilds idempotent.
Docs
  • Deployment guide now documents only the Freemius ZIP based WordPress.org deploy flow.

Version 1.1.3

Release Notes Historical Sync
Added
  • Historical Sync now backfills coupon behavior metrics including total_coupons_used, first_order_coupons, and coupon_then_refund.
  • Historical Sync now rebuilds category aggregates and linked-account fingerprints from older WooCommerce orders for more accurate scoring inputs.
  • Historical Sync now reconstructs historical timeline events for orders, refunds, and coupon events using original order and refund timestamps.
Improved
  • Sync backfill paths are now re-sync safe and remove previously generated synthetic sync events before rebuilding.

Version 1.1.2

Release Notes Sync Reliability
Fixed
  • Historical Sync now safely handles WooCommerce refund objects and no longer fails with OrderRefund::get_billing_email() errors.
  • Empty dashboard sync flow now always shows the correct progress UI when sync starts.
Improved
  • Sync batch AJAX failures now recover UI state instead of leaving controls hidden.
Added
  • Reliable activation redirect to the TrustLens dashboard after plugin activation.

Version 1.1.1

Release Notes Sync Reliability
Fixed
  • Historical Sync now surfaces precise server error messages instead of generic AJAX failures.
  • Optimized sync startup order counting to avoid loading all order IDs in memory.
  • Corrected sync customer totals to count only newly inserted customers across batches.
  • Ensured WordPress pointer assets are enqueued on TrustLens admin pages to prevent Freemius pointer JS errors.
Improved
  • Refactored duplicated batch-processing logic into a shared internal helper for consistency.
  • Removed unused sync polling code path and dead AJAX endpoint, and hardened Action Scheduler fallbacks.

Version 1.1.0

Release Notes Payment Controls
Added
  • Dedicated Payment Controls settings tab.
  • Pro Payment Method Risk Controls to hide selected gateways for risky segments at checkout.
  • Pro Velocity Protection for temporary gateway restrictions during high order-attempt spikes.
  • Pro Linked Account Protection using linked-account fingerprints for real-time gateway restriction decisions.
Improved
  • Restriction event logging now includes trigger reasons and linked-account risk context for better auditability.

Version 1.0.6

Release Notes Upsell UX
Added
  • Redesigned Pro upsell experience with polished value panels, comparison rows, and improved CTAs across Automation, Notifications, Webhooks, Reports, and Chargebacks.
Improved
  • Unified upsell rendering via a shared component for more consistent styling and messaging.
  • Dashboard empty state now always shows the Historical Sync action with clearer guidance when no eligible historical orders exist.
Fixed
  • Removed obsolete locked-notification upsell styles and redundant upsell markup paths.

Version 1.0.5

Release Notes UI
Improved
  • UI improvements across the plugin.

Version 1.0.4

Release Notes Admin UX
Added
  • Automation is now a dedicated menu with its own dashboard-style page.
  • Chargebacks Pro settings tab with module enable/disable and configurable auto-block after lost disputes.
  • Test notification timeout handling with a clear message when mail or SMTP is not configured.
Changed
  • Automation moved out of Settings, and the old Automation tab URL now redirects to the new Automation page.
  • Modal styling refreshed with a card look, accent bar, overlay blur, and improved header, body, footer, and close button.
  • Global “Enable Notifications” now applies to all notifications, both Standard and Pro.
  • Pro notifications list refactored to a single source of truth with no duplicate markup.
Fixed
  • API tab no longer shows the stored key hash when a key exists; placeholder and copy instructions are shown instead.
  • API documentation now matches implementation for lookup, update customer, events, recalculate, and stats/segments endpoints.
  • REST API routes for customer events and recalculate used the then-current 32-character email hash format.
  • Historical Sync started from Settings → Data now shows progress updates correctly.
  • Test notification no longer spins indefinitely when server mail is not configured.
Improved
  • Redundancy cleanup on Automation, Data, and Notifications pages, and Chart.js is no longer loaded on the Automation page.

Version 1.0.3

Release Notes Maintenance
Fixed
  • Bug fixes.

Version 1.0.2

Release Notes UI Polish
Improved
  • Dashboard and customer pages UI refinements across spacing, sizing, alignment, and visual polish.
  • Color system upgraded with reusable segment variables and a primary plugin color token.
  • Admin styles split into page-specific files for better maintainability and scoped loading.
  • Test data generation now seeds higher trust scores in the 80-95 range.

Version 1.0.1

Release Notes Packaging
Updated
  • Release packaging and deployment workflow updates with no functional changes.

Version 1.0.0

Initial Release Foundation
Core Engine
  • Trust score calculation engine with weighted signal aggregation on a 0-100 scale.
  • Six-tier customer segmentation: VIP, Trusted, Normal, Caution, Risk, and Critical.
  • Account age loyalty bonus of up to +15 points for long-standing customers.
  • Configurable minimum order threshold before segment classification.
  • Allowlist system with automatic score override to 100.
Detection Modules
  • Return abuse detection with refund rate, refund value, and return frequency analysis.
  • Order pattern analysis for completion rates, cancellation tracking, and order velocity.
  • Coupon abuse detection for first-order discount exploitation and coupon-then-refund patterns.
  • Category-aware scoring with per-category return rate tracking and weighted penalties.
  • Linked accounts detection via address, phone, IP, payment, and device fingerprinting.
Dashboard & Analytics
  • Nine-section command center dashboard with store health score.
  • Six interactive Chart.js charts covering trust trends, segment distribution, refund activity, hourly activity, category return rates, and monthly protection trend.
  • KPI cards for total customers, average trust score, new high-risk, 24-hour events, total orders, and return rate.
  • ROI scorecard with money protected, money at risk, protection rate, and actions taken.
  • Top returners table and a high-risk customer attention list.
Customer Management
  • Searchable customer list with segment, score, and return rate columns.
  • Customer detail page with full behavioral history and signal breakdown.
  • Manual block and unblock with checkout enforcement.
  • Allowlist management for VIP protection.
  • CSV export for the full customer list and JSON export for individual customer profiles.
Integrations
  • WooCommerce order edit screen integration showing customer trust score.
  • REST API with eight endpoints and API key authentication.
  • GDPR data export and erasure via WordPress privacy tools.
  • WooCommerce High-Performance Order Storage compatibility.
  • Action Scheduler for asynchronous score processing.
Notifications
  • Blocked checkout email alert.
  • Welcome summary sent 24 hours after activation.
  • Weekly protection summary report.
Historical Sync
  • Background import of existing WooCommerce orders.
  • Progress tracking with start, stop, and resume controls.
  • Batch processing without site performance impact.