FlxWoo

Description

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 templates
• A Stripe Checkout integration with server-side session management and webhook handling
• 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) and operates exclusively in REST context. Its endpoints return server-side rendered HTML — not JSON UI fragments — keeping template logic server-side and reducing frontend coupling.

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
• 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 templates
• Structured logging for checkout and payment events
• Health endpoint at GET /wp-json/flxwoo/v1/health for uptime monitoring

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

All routes under /wp-json/flxwoo/v1/* must bypass cache at every layer: page cache, CDN, reverse proxy, and any optimization plugin that operates on HTTP responses. This includes cart, checkout, payment, webhook, and health endpoints.

Common Systems That Require Configuration

WP Rocket — Add /wp-json/flxwoo/v1/(.*) to “Never Cache URL(s)” in the Cache settings tab.

LiteSpeed Cache — Add FlxWoo REST routes to the cache exclusion list under Cache > Excludes.

Cloudflare — Use Cache Rules to bypass cache for requests matching /wp-json/flxwoo/v1/*. If using Automatic Platform Optimization (APO), verify that checkout routes are excluded. Cloudflare’s “Cache Everything” page rule must not apply to these paths.

Nginx / FastCGI — Add a no-cache bypass condition for the FlxWoo REST namespace at the server or location block level.

Varnish — Add a pass condition for /wp-json/flxwoo/v1/ in your VCL configuration.

Aggressive optimization plugins — Verify that no plugin is buffering, combining, or caching REST API responses for FlxWoo routes.

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