v1.12.2, no fatal error with WooCommerce deactivated

Fixed

• No fatal error with WooCommerce deactivated. The Antifraud menu stayed registered while WooCommerce was inactive, and the Activity Log and Reports tabs crashed on wc_get_order(). The admin screens and custom order statuses now load only when WooCommerce is active; the "requires WooCommerce" notice still shows and updates still arrive. Found during QA by @szczepaniakmateusz59-del (#13).

Full details in CHANGELOG.md.

v1.12.1 — Released orders stay released, checkout-seen marker

Fixed

• Released orders stay released. Moving an Auto Cancelled order back to Processing re-ran the post-payment analysis inside the release and cancelled it again in the same second. Released orders are now marked _wcaf_released, lose the fraud flag and Fraud badge, and are never judged again. Refunds keep the fraud designation as before.
• Store API bot rule no longer cancels customers whose browser blocks attribution. The plugin now records server-side that the checkout page was rendered in the customer's session (_wcaf_checkout_seen). "Store API Bot Order (no checkout session)" and the optional Unknown Origin rule fire only when the order has no attribution and the checkout page was never rendered. Orders posted straight to the API are caught as before.

Full details in CHANGELOG.md.

v1.12.0 — Classic checkout lock

Added

• Classic checkout lock. On a store whose checkout page renders the Block Checkout, the classic checkout's AJAX endpoints (wc-ajax=checkout, wc-ajax=update_order_review and their admin-ajax forms) are answered with HTTP 403 before any order is created or any gateway contacted. No customer of such a store sends those requests; card-testing toolkits that walk the legacy flow with one stolen card per fresh IP do. Engages only while the Block Checkout is detected, lets allowlisted IPs pass, counts refusals as refused:classic_checkout, and emails the alert recipients at most once an hour. Customer-facing text via the wcaf_classic_lock_message filter. On by default for new installs; existing installs are pinned off by the one-time option upgrade (schema version 2) and can turn it on under Detection Rules > Checkout Surface.
• Refused Before Payment table on the Reports tab, built from the daily counters (pre-payment refusals by rule, REST hardening blocks, classic checkout lock).

v1.11.0 — New installs start in Monitor mode

Changed

• New installs start in Monitor mode. The settings screen and README already told new stores to begin there, but activation defaulted to Block, so a fresh install with the default rules could move genuine orders into a fraud status before the merchant had seen a single detection. Existing stores keep the mode they had: a one-time upgrade step pins detection_mode to Block on any install whose stored options never carried the key. (#7)

v1.10.0 — HPOS fraud statuses, REST credential check, rolling decline window

First release assembled from reviewed Codex pull requests (#2, #3, #4, #5, #6, #8).

Fixed

• Fraud orders were invisible on the HPOS Orders list. Statuses are now registered and stored as wc-fraud-auto and wc-fraud-stripe, like WooCommerce's own. A one-time migration on the first request after updating rewrites the old values in wp_posts and the HPOS tables, backfills the persistent fraud flag, and clears caches, with direct SQL so no status hooks, notes, or emails fire. The combined Fraud view now exists on HPOS too, the Activity Log and Reports read the authoritative store, refunded fraud orders count in Reports, and alert emails use the HPOS-aware edit link. Usage-report counter key moves from marked:fraud-auto-cancelled to marked:fraud-auto. (#5)
• REST hardening no longer trusts credential-like input. Only a request WooCommerce authenticated as a manage_woocommerce user, or one with a valid Store API nonce, passes. WooCommerce's own permission check already refused fake credentials, so this hardens the plugin's layer. (#3)
• Repeated payment failures are counted over a true rolling 24 hours. Existing clusters keep their count for one more window. (#4)
• IP repeat tracking no longer grows without bound. One expiring transient per IP; the old wcaf_ip_store option is removed on first use. (#6)
• Post-payment rules never fall back to the request IP. (#6)
• wcaf_suspicious_order_detected always receives three arguments. (#8)

Changed

• Every outbound request sends a WC-Antifraud/<version> WordPress/<version> User-Agent instead of WordPress's default, which carries the site URL. README privacy section reworded. (#2)

Full details in CHANGELOG.md.

v1.9.0 — Linked to known fraud

Added

• Linked to known fraud. A new order is tied to an order already marked fraud in the last 30 days (Detection Rules > Linked to Known Fraud, look-back configurable, on by default) when the two share the billing email, the ship-to street and postcode, or the customer IP within an hour of each other. Catches the retry with a second card or gateway after a Radar block, and the reshipping pattern where a new name and card ship to the same address, neither of which a gateway verdict ties together.
• On a failed order any fraud order can be the link, a Stripe verdict included. On a paid order only the plugin's own detections and manual marks count, never a Stripe verdict, so a real customer Radar blocked who then pays another way keeps the sale.
• Customer-facing paths only (classic checkout and Store API). Orders marked by this rule alone are not reported to AbuseIPDB. The order note names the earlier order and what was shared.
• WCAF_Order_Status::recent_fraud_anchors(): one query for recent fraud orders and their compared fields, on the posts store or the HPOS tables.

v1.8.0 — Opt-in anonymous usage reports

Added

• Opt-in anonymous usage reports. Nothing is sent until an administrator answers the one-time question (also under Notifications > Privacy). Once a day, from WP cron only, a report keyed by a random install ID (never your site address) goes to prowoos.com with: plugin, WordPress, WooCommerce, and PHP versions and the locale; whether HPOS, the Block Checkout, and Order Attribution are in use; which rules are on and the detection mode; whether Cloudflare or a proxy was detected; and the previous day's event counts. Never emails, IP addresses, order details, URLs, or user data. Withdraw at any time; "Delete my data and stop" asks the receiver to remove everything for your install ID. Full field list in the README under Privacy.
• Daily event counters (30 days): fraud marked by reason, monitor flags, checkouts refused by reason, REST blocks, repeated-failure alerts, auto-bans, bans lifted by hand, "Block this customer" uses, and fraud orders un-marked by an admin.

Full details in CHANGELOG.md.

v1.7.0 — Trusted-proxy IP resolution

Fixed

• Client IP resolution no longer trusts forwarding headers from anyone. The connecting address is the customer unless it belongs to a proxy the plugin trusts: Cloudflare (published ranges fetched daily, bundled fallback), a proxy on the same host (private or carrier-grade NAT peer, detected automatically, so managed hosts need no configuration), or a proxy you declare. A bot can no longer forge its address to evade the IP blacklist and bans or get innocent addresses banned.

Added

• Lists > Trusted Proxies: declared proxy ranges (IPv4 and IPv6), a diagnostic showing how the current request was resolved, Cloudflare range status with a Refresh link, and a clearly marked legacy switch restoring the old behavior.
• Detection of an undeclared public-address proxy with one-click trust or dismiss. While undeclared, the automatic IP-keyed rules pause so every customer is not treated as one address; blacklists, allowlist, and all non-IP rules keep working.
• IPv6 support in every IP list and CIDR match.

Full details in CHANGELOG.md.

v1.6.0 — Decline clustering, auto-ban, allowlist, bundled disposable list, monitor mode

Added

• Repeated payment failures (decline clustering). Failed payments are counted per visitor over a rolling 24 hours, under the checkout session and the customer IP stored on the order. From 5 failures a non-dismissible admin notice appears. Optionally, further checkouts from that visitor are refused before they reach the gateway, on the classic checkout and the Block Checkout alike. Failures are counted, never orders.
• Temporary auto-ban. When the failure limit refuses a checkout, the IP can be banned for a configurable time. Bans expire on their own, never touch allowlisted IPs, and are listed on the Lists tab with Unban links.
• IP allowlist (CIDR supported). Bypasses every check, never flagged, never banned.
• Bundled disposable-domain list. 8,714 known throwaway domains from the public-domain disposable-email-domains project, plus your own additions.
• Monitor mode. Suspicious orders are flagged, noted, and reported by email, but their status is never changed and nothing is reported to AbuseIPDB. Recommended for new installs.
• Registration protection (off by default): banned or blacklisted IPs, blacklisted or disposable emails, per-IP hourly limit.
• "Block this customer (Antifraud)" in the order-screen Actions dropdown.
• REST protection self-test button on the Detection Rules tab.
• Pre-payment checks (blacklists, bans, failure limit) now also run on the Block Checkout through the Store API.

Changed

• Post-payment rules judge an order by the customer IP stored on the order, not by the IP of the request running the analysis (which is often a gateway webhook).
• REST hardening's error code is now wcaf_rest_forbidden.
• The "Blacklists" tab is now "Lists".

Full details in CHANGELOG.md.

v1.5.1 — Skip attribution rules when Order Attribution is off

Fixed

• On stores where WooCommerce's Order Attribution feature is turned off, no order carries attribution meta, so the unknown-origin rule and the Store API bot check flagged every genuine order as fraud. Both rules are now skipped when the feature is off, and the settings screen shows a note next to "Unknown origin blocking" saying the rule is inactive until Order Attribution is enabled (WooCommerce > Settings > Advanced > Features).