Klaviyo only tracks Placed Order events when your WooCommerce order status is “processing.” If your store uses custom order statuses, holds orders for payment verification, or processes subscriptions differently—those orders never appear in Klaviyo. Your revenue reports diverge, your segments become inaccurate, and your abandoned cart flows miss the customers you need most.
This isn’t a bug. It’s how the integration was designed. Here’s why Klaviyo shows fewer orders than WooCommerce and what you can actually do about it.
The Order Status Problem
Klaviyo’s WooCommerce integration watches for orders that reach the “processing” status. When WooCommerce marks an order as processing, Klaviyo fires a Placed Order event. Makes sense for standard flows.
But WooCommerce stores rarely follow standard flows.
Custom order statuses—”awaiting payment,” “pending verification,” “subscription-pending”—never trigger Klaviyo’s Placed Order event. The order exists in WooCommerce. The customer paid. But Klaviyo doesn’t know about it because the status name doesn’t match what Klaviyo expects.
If you use WooCommerce Subscriptions, payment gateway holds, or any plugin that introduces custom statuses, you’re systematically undercounting revenue in Klaviyo.
The Started Checkout Gap
Klaviyo’s abandoned cart functionality depends on the Started Checkout event. To trigger this event, a customer must view the checkout page AND enter their billing email. Both conditions must be met.
Single-page checkouts often bypass this entirely. Express payment methods—Apple Pay, Google Pay, Shop Pay—skip the traditional checkout flow. Buy-now buttons take customers directly to payment without passing through the checkout page Klaviyo monitors.
Started Checkout requires customers to view the checkout page AND enter their email address. Single-page checkouts, express payments, and buy-now buttons bypass this requirement entirely.
The result: your abandoned cart flows miss exactly the customers using your most convenient checkout options.
You may be interested in: Your Caching Plugin Is Breaking WooCommerce Conversion Tracking
The JavaScript Dependency
Klaviyo’s WooCommerce tracking runs primarily through Klaviyo.js—JavaScript that executes in the visitor’s browser. This creates several vulnerability points:
Caching plugins can serve cached pages that don’t include fresh Klaviyo tracking code. Page caching, object caching, and fragment caching all introduce opportunities for Klaviyo.js to be served incorrectly or not at all.
JavaScript minification can corrupt Klaviyo’s tracking code. Aggressive optimization plugins sometimes break the script’s functionality while producing no visible errors.
Security software blocks Klaviyo’s integration attempts. Klaviyo’s documentation specifically mentions that Cloudflare’s Bot Fight Mode blocks their integration. Sucuri, Wordfence, and other security plugins can similarly interfere.
Caching plugins and JavaScript minification can completely break Klaviyo tracking—users in the Klaviyo Community report days of lost data before discovering the issue.
Store owners in the Klaviyo Community forums describe exactly this frustration: “Today we had 5 orders but Klaviyo only tracked 2 started checkouts. The Total revenue value in the performance section is also totally wrong.”
What You Can Fix
Some of these issues have workarounds. Others are architectural limitations you’ll need to supplement rather than solve.
Fixable: Caching Conflicts
Exclude checkout and thank-you pages from page caching. Most caching plugins have URL exclusion settings—add your checkout URL and order-received pages. Disable JavaScript minification for Klaviyo scripts or exclude klaviyo.js from optimization entirely.
Fixable: Security Software Conflicts
Whitelist Klaviyo’s IP addresses in your firewall. If you’re using Cloudflare, disable Bot Fight Mode or add exceptions for Klaviyo’s integration requests. Check your security plugin’s blocked requests log for Klaviyo-related entries.
Partially Fixable: Order Status Issues
If your custom statuses eventually transition to “processing,” the orders will sync—just delayed. If they never reach “processing,” you’ll need custom development to hook into your specific status transitions and push events to Klaviyo’s API manually.
Not Fixable: Express Checkout Tracking
Customers who use Apple Pay, Google Pay, or other express methods bypass the checkout page Klaviyo monitors. There’s no plugin-side solution for this—Klaviyo simply doesn’t see these transactions until after the Placed Order event fires.
You may be interested in: The One-to-Many Architecture: Replace 6 Tracking Plugins with One Data Stream
The Architectural Limitation
Here’s what Klaviyo’s documentation and community forums don’t explain clearly: browser-dependent JavaScript tracking will always have gaps.
Ad blockers block Klaviyo.js. Privacy browsers restrict it. Cached pages serve stale versions. Security software intercepts it. Express checkouts bypass it. Every one of these scenarios is a customer whose transaction Klaviyo can’t track on the client side.
The only way to close these gaps completely is to capture order events at a different layer—your server, not the visitor’s browser.
Server-Side Closes the Gaps
Server-side tracking captures order events from WooCommerce hooks directly. When an order is created, the event fires from your server—regardless of what’s happening in the customer’s browser, regardless of caching configuration, regardless of JavaScript blocking.
Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures order events from WooCommerce hooks and sends them via API to your Transmute Engine server, which routes them to Klaviyo alongside GA4, Facebook CAPI, and other destinations simultaneously.
Server-side order events fire from WooCommerce hooks regardless of browser state, ad blockers, or caching configuration—filling the gaps that Klaviyo’s JavaScript can’t reach.
Key Takeaways
- Processing status only: Klaviyo Placed Order events only fire when orders reach “processing”—custom statuses never sync automatically.
- Started Checkout requires two conditions: Customer must view checkout page AND enter email—express payments bypass both.
- Caching breaks JavaScript: Page caching, JS minification, and fragment caching all create opportunities for Klaviyo.js to fail.
- Security software interference: Cloudflare Bot Fight Mode, Sucuri, and Wordfence can block Klaviyo integration requests.
- Server-side supplements gaps: Capturing order events from WooCommerce hooks bypasses all browser-side limitations.
Klaviyo’s Started Checkout event requires two conditions: the customer must view the checkout page AND enter their billing email. Single-page checkouts, express payment options (Apple Pay, Google Pay), and buy-now flows often bypass the traditional checkout page entirely. If customers don’t reach the checkout page or don’t enter their email before abandoning, Klaviyo has no way to identify them for abandoned cart emails.
Yes, caching plugins frequently break Klaviyo tracking. JavaScript minification can corrupt Klaviyo.js. Page caching can serve stale versions that don’t include tracking code. Klaviyo recommends excluding checkout and thank-you pages from caching, but many store owners don’t know this. Check if your caching plugin has JavaScript optimization enabled and disable it for Klaviyo scripts.
Klaviyo revenue totals will always be lower than WooCommerce if you have orders that never reach “processing” status, use express checkout methods, or have any JavaScript blocking. Ad blockers affect roughly 31.5% of users globally, and every blocked visitor represents a transaction that Klaviyo can’t track client-side.
Stop losing abandoned cart revenue to integration gaps. See how Seresa closes the tracking gaps Klaviyo can’t reach.
