Checkout Shield for WooCommerce – Stop Fake Orders, Spam Bots & Card Testing vs TrustSig Security

Checkout Shield blocks the scripted checkout submissions that CAPTCHA never sees. Card testing bots don’t fill out your checkout form. They hit your store’s checkout API directly, completely skipping any reCAPTCHA or hCaptcha you’ve set up. That’s why CAPTCHA alone doesn’t stop them. Your site signs a proof into the checkout page it serves. A submission that carries that proof loaded the page; one that doesn’t, didn’t. Submissions with no valid proof are stopped before WooCommerce processes the order. What this stops, and what it does not Being straight about this is more useful than a bigger promise. It stops anything that posts to your checkout without loading the checkout page first: curl scripts, direct Store API calls, replayed form posts, and the card testing runs that work this way. This is the large majority of automated checkout abuse, and it is the part CAPTCHA misses. It does not stop a bot that drives a real browser. Something that genuinely loads your checkout page receives a genuine proof, because that is exactly what the proof records. Once loaded, that proof stays valid for the life of the shopping session, so a script can reuse it. No proof of this kind can tell the second submission from the first, since the thing being proven is identical. For that tier you want a bot mitigation service in front of the site (Cloudflare Bot Fight Mode, Sucuri) alongside this plugin. What this plugin can do is show you when it is happening: the dashboard reports payments that failed repeatedly from a single checkout visit, which is what working through stolen card numbers looks like. In Pro it can also act on it. Once a visit crosses a failure limit you set, the source IP is banned for a while so it can’t just start a fresh visit and keep going, and the ban lifts itself, so a bad guess never becomes a permanent lock-out. A determined attacker can still rotate IPs, which is why the service in front of the site stays the front line, but for the common case this turns the pattern off at the source. Why Store Owners Choose This Plugin Catches what CAPTCHA misses: blocks bots hitting your checkout API directly, without asking shoppers to prove anything Works with any caching: LiteSpeed, Cloudflare, WP Rocket and W3TC, with no conflicts Nothing to configure: no rules to write and no thresholds to tune Never blocks your customers by mistake: it only starts once it has seen a real checkout on your store work, and if your theme ever stops carrying the proof it detects that, keeps letting real shoppers through, and tells you what to fix No external services: everything runs on your server, no subscriptions Adds milliseconds: the check is local, with no third-party call to wait on Features (Free) Automatic bot blocking: no rules to configure; it arms itself once it has seen one checkout on your store work 4 protection levels: Learning, Permissive, Balanced and Strict, so you choose how aggressive you want to be One place for everything: a dedicated Checkout Shield screen with a live “what’s protected right now” overview, plus your settings and logs Dashboard overview: see blocked vs verified orders at a glance with a 7-day chart Order status tracking: know which orders were flagged, passed, or blocked IP whitelist: let trusted addresses through, supports CIDR notation API key authentication: for headless and custom checkout setups Works with all checkout types: classic, block-based, and all payment gateways HPOS compatible: works with High-Performance Order Storage WooCommerce logging: full integration with WooCommerce Status logs Pro Features Pro is about two things: stopping more, and letting you see it happen. Live attack timeline: watch scripted attempts get stopped as they arrive, with the surface, reason, masked email, and IP for each one Test your protection: one button fires the real card-testing request at your own store and shows you it hit a wall, so you never have to wonder whether it’s working Auto-ban repeat offenders: when one visit keeps failing payment past a limit you set, its IP is blocked for a while and then released on its own, so it can’t just start over Registration protection: the same no-CAPTCHA proof on your sign-up forms, plus throwaway-email blocking and per-IP rate limiting, to stop the fake accounts that come before fraud Throwaway email blocking: reject checkouts using a known disposable inbox, with a domain list the plugin keeps up to date for you 3-level logging control: turn logging off, log blocked attempts only, or log everything Recent blocks feed: the last 50 blocked attempts with email, payment method, and reason Automatic CDN/proxy detection: identifies real visitor IPs behind Cloudflare, Sucuri, or Akamai Stronger permissive mode: tighter bot detection with referrer and user-agent checks Checkout details in logs: see which email and payment method bots tried to use Customer blocklist: block repeat offenders by email, name, address, phone, IP, or postal code, all managed from the Checkout Shield screen One-click order blocking: block a customer directly from any order screen Learn more about Pro features

TrustSig Security stops scripted bots and brute-force attacks on WordPress forms and API endpoints. There are no puzzles to solve and no “I am not a robot” checkboxes to tick, and you do not have to sign up for anything before it starts working. What exactly gets checked depends on the protection mode you pick, described below. Why TrustSig Covers the forms that matter out of the box: login, registration, comments, password reset, WooCommerce checkout, BuddyPress signup, Easy Digital Downloads, Elementor Pro forms, WPForms (including the Mesmerize and Materialis contact form), Contact Form 7, SureForms, plus any custom form via a shortcode. Locks out brute-force login attempts after repeated failures. Real visitors never notice it. The browser check runs on its own and finishes in about a second, with no images to click. Three protection modes: Monitor logs and never blocks, Challenge (the default) shows a short interstitial and retries, Enforce blocks outright. Nothing to configure. Activate the plugin and protection is live. The anonymous free tier needs no account. Works with caching plugins, WPML, multisite and most themes, because forms are signed server-side with a per-site secret. A developer API: the PHP helper trustsig_verify(), the REST endpoint /wp-json/trustsig/v1/verify, and filters and actions for custom forms. An optional guard for admin-ajax and the REST API on sites that need it. An optional scan-on-submit mode that runs the browser check only when a visitor actually uses a form, not on every page view. GPLv2, fully open source. How it works TrustSig loads a small browser SDK, signs every rendered form with a per-site secret, and checks submissions against the TrustSig Edge service. A real visitor passes the check in about a second without doing anything. A scripted client that never runs JavaScript produces no token and gets stopped. When a request arrives without a valid token, the plugin does not quietly wave it through. Depending on the mode, it either serves a short “please wait” page that re-verifies the browser and then continues the original request, or blocks it. No account and no API keys are needed; the anonymous free tier is the default. Connecting a TrustSig dashboard account is optional and only adds analytics and higher limits. Protection modes Monitor: verify and log only, never block. Good for a safe rollout. Upgrades also pin existing sites here, so behaviour never changes silently on update. Challenge (default for new installs): a missing or invalid token triggers the interstitial, which then continues or blocks. Enforce: a missing or invalid token is blocked immediately. What it protects Browser forms are covered automatically, no code needed: WordPress core: login, registration, comments, lost and reset password WooCommerce: login, registration, checkout, pay order, lost password BuddyPress: registration Easy Digital Downloads: login, registration Elementor Pro forms WPForms: contact and other forms, on by default (this also covers the Mesmerize and Materialis contact section) Contact Form 7: feedback submissions, on by default, guarded on the REST endpoint CF7 submits to SureForms: form submissions, on by default, guarded on the REST submit-form endpoint Anything else via the site-wide “protect all forms” option, the [trustsig_form] shortcode, or a hidden trustsig-response input On top of that there is an optional brute-force lockout for repeated failed logins, an opt-in guard for admin-ajax and the REST API, and a verification API for developers. For developers PHP: trustsig_verify( array( ‘token’ => $t, ‘action’ => ‘my_form’ ) ) returns pass, fail or challenge. Filters: trustsig_pre_verify, trustsig_result. Action: trustsig_blocked. REST: POST /wp-json/trustsig/v1/verify with { “token”: “…” }. Known limitations XML-RPC (xmlrpc.php) is deliberately out of scope and is not verified. If your site does not use XML-RPC, disable it separately. admin-ajax and the REST API are only guarded when you enable that in Settings. This is on purpose, so third-party integrations do not break the moment you install the plugin. File uploads and AJAX submissions cannot show the interstitial. In Challenge or Enforce mode a missing token on those is blocked. It is never silently allowed. External services This plugin relies on the TrustSig Edge service to decide whether a request comes from a human or an automated client. That verdict cannot be produced locally, so the service is required for the plugin to do its job. Service provider: TrustSig, https://trustsig.eu Remote script loaded in the browser: https://edge.trustsig.eu/trustsig.js loads on pages that contain a protected form, on the login screen, and on the verification interstitial. It runs the non-interactive browser check and produces a verification token. Data sent from the visitor’s browser or your server to https://edge.trustsig.eu/verify: the TrustSig verification token generated by the SDK in the visitor’s browser; your site’s host name (for example example.com) on the anonymous free tier, or the secret key you entered if you connect a dashboard account; as with any HTTPS request, the visitor’s IP address and standard request metadata such as the user agent are visible to the service. When data is sent: when the SDK loads on a protected page, when a protected form is submitted, and once per browser when the optional verified-session cookie is bootstrapped. Data stored locally on your site: TrustSig writes a verification log to your own WordPress database (custom tables) with visitor IP addresses, the action attempted, and the verdict. This log is not sent to TrustSig, and you can clear it at any time under Settings, TrustSig, Tools. By installing and activating this plugin you, the site administrator, consent to this data being sent to TrustSig so that requests can be verified. Inform your own visitors as your local privacy obligations require. Terms of Service: https://trustsig.eu/terms-of-service/ Privacy Policy: https://trustsig.eu/privacy