Facebook CAPI on WordPress and WooCommerce is easier than on most platforms, because you have real server access. That same freedom is how people end up sending every purchase twice.
Here's the plugin route, the server-side route, and how to keep them from fighting.
Two routes, pick one
- A plugin, like the official Facebook for WooCommerce or a pixel plugin, which wires the pixel and CAPI with almost no code.
- Server-side GTM, where WooCommerce forwards events to your server container and a CAPI tag sends them on.
Both work. Running both at once is the classic mistake, because each fires its own Purchase.
The plugin route
- Install one Facebook or CAPI plugin, not three, and connect it to your pixel and a CAPI access token.
- Confirm it emits a shared event_id for the pixel and the server event, so they deduplicate.
- Map the WooCommerce order to a Purchase event with value and currency from the order total.
- Let it pass hashed customer email and phone from checkout for match quality.
The server-side route
For more control, forward WooCommerce events into server-side GTM and send CAPI from there. You get to shape the payload, add parameters, and keep the access token off the page.
It's more setup, but it's the cleaner long-term home, especially if you already run sGTM for GA4.
Where WordPress setups go wrong
- Two plugins, or a plugin plus sGTM, both firing Purchase, so conversions double.
- A caching plugin serves a stale page and the pixel misfires or skips the event_id.
- The order total includes or excludes tax and shipping inconsistently, so value doesn't match your store reports.
- Refunds never send back, so Meta's revenue stays higher than reality.
Check it
Place a real test order and watch Events Manager. You want one Purchase, from both sources, deduplicated, with the right value and a decent match score.
Handle caching and refunds
Caching is the WooCommerce-specific gremlin. A page cache can serve a stale confirmation page, so the pixel misfires or loses its event_id. Exclude the order-received page from cache, or move the Purchase event server-side where the cache can't touch it.
Refunds are the other blind spot. A WooCommerce refund should send a matching signal back, or Meta keeps counting revenue you gave back. Most plugins won't do this by default, so check it explicitly.
Value that ties out
Decide whether the Purchase value includes tax and shipping and match your accounting, because a store owner comparing Meta to their books notices a ten percent gap immediately. Coupons and partial payments complicate it further, so test an order with a discount, not just a clean one. A gift card or store-credit order is worth testing too, since it often reports a value of zero.
If your host runs an aggressive caching or optimization plugin, test after clearing the cache and again on a warm cache, because the two can behave differently and only one of them is what real visitors see.
On plugins, fewer is safer. One well-maintained integration that does both pixel and CAPI beats a stack of single-purpose plugins that each fire their own events. Audit what's installed before you add another.
What good looks like
A single deduplicated Purchase per order, the right value, a healthy match score, and refunds flowing back. If a discounted test order and a plain one both reconcile, your setup is trustworthy, not just wired.
Facebook CAPI on WordPress is a solved problem the moment you stop running two integrations at once. Pick the plugin or the server-side route, pin a shared event_id, and the double counting that plagues WooCommerce stores disappears.
Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.
