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

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

FlxWoo is a WooCommerce infrastructure plugin. It adds a REST API layer, server-side checkout rendering, and Stripe Checkout integration on top of standard WooCommerce — without replacing WooCommerce’s core order, payment, or inventory systems. It is designed for agencies and developers who need full control over checkout presentation while continuing to rely on WooCommerce for order management, tax calculation, coupon handling, and payment record-keeping. What FlxWoo Is A REST API layer for WooCommerce checkout state (namespace: flxwoo/v1) A server-side rendering layer for checkout and product page templates A Stripe Checkout integration with server-side session management and webhook handling A fallback-safe product page rendering layer: falls back to native WordPress/WooCommerce templates when the Render service is unavailable or the product type is not supported An admin dashboard for operational monitoring: Overview, Settings, and System Status pages An infrastructure layer that extends WooCommerce without replacing it What FlxWoo Is Not Not a WooCommerce fork or replacement Not a page builder or visual checkout designer Not a payment processor — payment remains in WooCommerce and Stripe Not a headless CMS Not a replacement for WooCommerce’s admin, order management, or product system Who FlxWoo Is For Agencies building custom checkout experiences on WooCommerce Developers who need REST access to WooCommerce checkout state Projects requiring server-side rendered checkout templates Teams integrating Stripe Checkout while keeping WooCommerce as the order system Architecture FlxWoo registers a REST namespace (flxwoo/v1). Checkout state endpoints (cart, order, coupon, customer) return JSON. Render endpoints (/render/checkout, /render/thank-you) return server-side rendered HTML. Product pages are intercepted at the template layer and rendered through the external Render service, with automatic fallback to native WordPress/WooCommerce templates if the service is unavailable or the product type is not supported. WooCommerce remains authoritative for all order, cart, tax, and payment data. FlxWoo reads and writes through WooCommerce’s standard APIs without modifying its data structures or core behavior. Features REST API under the flxwoo/v1 namespace Cart and checkout state endpoints returning JSON Stripe Checkout integration — server-side session creation and webhook handling Duplicate order prevention at the checkout session level Concurrent submission guard Session-independent Stripe return flow (order identity carried via URL, not session state) Server-side HTML rendering for checkout and thank-you templates Product page rendering via external Render service, with automatic fallback to native WordPress/WooCommerce templates Product type gate: only simple products (including virtual) are routed to the Render service; variable, external, and unrecognized types use native templates Structured logging for checkout and payment events Operational event store tracking webhook failures, Stripe connectivity issues, and auth denials Health endpoint at GET /wp-json/flxwoo/v1/health for uptime monitoring Admin Overview page with operational health summary and last-payment/last-webhook signals System Status page with diagnostics across environment, Stripe, cache, webhooks, checkout failures, and database Automated data retention: scheduled cleanup for idempotency records, Stripe events, checkout sessions, and operational events with defined retention windows Preserve-by-default uninstall policy: data is retained unless explicitly opted out in Settings Cache and CDN Configuration FlxWoo endpoints are session-sensitive and stateful. They must not be served from a cache layer under any circumstances. Why This Matters FlxWoo checkout endpoints read and write live session, cart, and payment state on every request. If a caching layer returns a stale or shared response, the result is incorrect behavior — not a gracefully degraded experience. Common symptoms include stale cart totals, duplicate checkout attempts, broken Stripe sessions, and session data surfacing to the wrong customer. Any FlxWoo endpoint returning a cache HIT response header is a production defect. What Must Bypass Cache Three route groups must bypass cache at every layer — page cache, CDN, reverse proxy, and any optimization plugin that operates on HTTP responses: /wp-json/flxwoo/* — all FlxWoo REST API endpoints (cart, checkout, payment, webhook, health) /checkout* — the WordPress checkout page and all trailing-slash or query-string variants /thank-you* — the order confirmation page and all variants FlxWoo emits Cache-Control: no-store headers via PHP on both the REST API and the HTML pages. However, CDN-level rules such as Cloudflare’s “Cache Everything” can override PHP headers at the edge before they reach the browser. PHP-level headers alone are not sufficient — explicit CDN bypass rules targeting these paths are required. Common Systems That Require Configuration WP Rocket — Add /wp-json/flxwoo/, /checkout, and /thank-you to “Never Cache URL(s)” in the Cache settings tab. WP Rocket uses substring prefix matching, so these entries cover /checkout* and /thank-you* including trailing-slash and query-string variants. LiteSpeed Cache — Add /wp-json/flxwoo/, /checkout, and /thank-you to the “Do Not Cache URIs” list under Cache > Excludes. LiteSpeed URI exclusions also use prefix matching, covering /checkout* and /thank-you*. Cloudflare — Use Cache Rules to bypass cache for paths matching /checkout*, /thank-you*, and /wp-json/flxwoo/*. If using Automatic Platform Optimization (APO), verify that checkout and thank-you URLs are in the APO exclusion list. Cloudflare’s “Cache Everything” page rule must not apply to these paths. Nginx / FastCGI — Add fastcgi_cache_bypass map entries for /wp-json/flxwoo/, /checkout*, and /thank-you* at the server or location block level. Varnish — Add pass conditions in vcl_recv for /wp-json/flxwoo/*, /checkout*, and /thank-you*. Aggressive optimization plugins — Verify that no plugin is buffering, combining, or caching REST API responses or HTML responses for FlxWoo routes or page wrappers. What Is Safe to Cache Static assets (CSS, JS, images), non-dynamic pages, and REST endpoints that explicitly return Cache-Control: public. FlxWoo’s own endpoints never set public cache headers. Full Configuration Reference Detailed per-system instructions, verification commands, and symptom diagnostics are in docs/cache-configuration.md. Requirements WordPress 6.0 or later PHP 8.0 or later WooCommerce (active; declared as a required plugin) Stripe account with Checkout enabled (for payment features) MySQL 5.7+ or MariaDB 10.3+ Operational Notes Health endpoint: GET /wp-json/flxwoo/v1/health always returns HTTP 200 when the plugin is active. Suitable for uptime monitoring and deployment verification. Logging: Structured logging for checkout and payment events. Useful for incident response and debugging in production environments. Database setup: Required tables are created automatically on activation. Schema migrations run silently on upgrade — no manual steps required. Data on uninstall: Data is preserved by default when the plugin is deleted. To remove all FlxWoo data, enable Delete all data on uninstall in FlxWoo Settings > Data before deleting the plugin. Idempotency: Checkout idempotency is database-backed, making the system safe for concurrent requests and browser retries. Stripe return flow: Order identity is carried via URL parameters after Stripe redirect, not session state. This makes the return path resilient to session loss between payment and confirmation. Security All REST endpoints enforce WordPress capability checks before processing requests. Input is validated and sanitized at the API boundary and within the service layer. All PHP files include an ABSPATH guard to prevent direct execution. Database queries use prepared statements throughout. PHP CodeSniffer with WordPress Coding Standards and security sniffs is enforced as a release gate. Limitations Requires WooCommerce to be active. FlxWoo will not initialize without it. Stripe integration requires an active Stripe account with Checkout enabled. Server-side rendering requires a live PHP execution environment. Fully static deployments are not supported. All FlxWoo REST endpoints must not be behind a full-page or CDN cache layer. Product page rendering via the Render service is currently limited to simple products (including virtual). Variable, external, and other product types fall back to native WordPress/WooCommerce templates.