CAPI Purchase events firing for cancelled/unpaid orders — Meta for WooCommerce 3.6.0

[tonsvalleyshop]

Hi Meta Support,

I'm experiencing a critical issue with Meta for WooCommerce v3.6.0 on WooCommerce 10.6.1 / WordPress 6.9.4 where my Meta Ads conversion data is incorrect. Cancelled and unpaid orders are being reported as successful conversions in Ads Manager.

Site: tonsvalley.shop
Pixel ID: 271117514782530
Meta for WooCommerce version: 3.6.0
WooCommerce version: 10.6.1
WordPress version: 6.9.4
PHP: 8.3.30
Payment gateway: Razorpay

The problem:

1. When a customer initiates checkout but fails to complete payment (e.g. Razorpay payment abandoned), the order remains in "Pending payment" status.

2. WooCommerce's stock hold feature auto-cancels these unpaid orders after 30 minutes (this is standard WooCommerce behavior).

3. Facebook's own crawlers (user-agent: facebookexternalhit/1.1 and meta-externalads/1.1) are visiting the order-received (thank-you) URLs that contain UTM parameters from our ad campaigns. When these crawlers hit those pages, the CAPI fires server-side events including on order-received pages for orders that were never actually paid for.

4. The result is that Meta Ads Manager shows inflated purchase conversion numbers because CAPI events are being sent for orders that are cancelled/pending/failed — not just successfully completed orders.

Diagnostic evidence:

I installed a custom diagnostic logger and captured the following sequence on March 19, 2026:

• 21:13:53 — WooCommerce auto-cancel cron runs, cancels Order #17997 (Razorpay, ₹357, pending for 37 minutes)
• 21:15:01 — facebookexternalhit crawler visits /checkout/order-pay/16106/ — CAPI PageView fires
• 21:15:02 — facebookexternalhit crawler visits /checkout/order-received/16106/ — CAPI event fires on the thank-you page
• 21:15:03 — Another CAPI request fires for the same order-received URL

The CAPI requests are sent with partner_agent "woocommerce_7-10.6.1-3.6.0" confirming they originate from the Meta for WooCommerce plugin.

This issue likely started around March 10-12 when both WooCommerce updated to 10.6 and the Meta plugin updated to 3.6.0.

Requested fixes:

1. The plugin should check order status before firing any Purchase CAPI event — only orders with status "processing" or "completed" should trigger a Purchase event.

2. The plugin should not fire CAPI events when the request comes from Facebook's own crawlers (facebookexternalhit, meta-externalads). These are not real customer visits.

3. The plugin should not fire CAPI events on the order-received page if the order's payment status is not confirmed.

This is causing real financial damage as our ad optimization is training on false conversion data. Please escalate this.

Thank you.

[tonsvalleyshop]

Tagging the active maintainers for visibility: @carterbuce @devbodaghe @rithikb24 @sol-loup @ashiqursuperfly @iodic

This issue has been open for 5 days with no response. It's causing active financial damage to merchants running Meta Ads with async payment gateways (Razorpay, PayU, CCAvenue, etc.).

Update since filing: WooCommerce has now officially confirmed the root cause. Their Happiness Engineer confirmed that PR #58262 in WooCommerce 10.6 ("Fix auto-cancellation for unpaid checkout block orders") now auto-cancels block checkout orders for the first time. Previously, orders created via the Store API / Checkout Block (created_via: store-api) were silently excluded from the auto-cancel sweep. This means every WooCommerce store on block checkout with an async payment gateway is now having pending orders auto-cancelled — and Meta's plugin fires CAPI events on those order-received pages without checking order status.

This is not a new problem. It's the same fundamental flaw reported in:

• Dispatch Purchase event after the Order is in processing insted Order placed #583 — Purchase event dispatched based on order placement, not order status (filed 2019, closed without fix)
• CAPI purchase event not firing with orders from FB/Instagram app on iOS #2447 — CAPI purchase event not firing correctly with async payment flows / iOS (filed 2023, partially patched but core issue remains)

The plugin code in facebook-commerce-events-tracker.php even has a comment on the purchase tracking function that says "Get the status of the order to ensure we track the actual purchases and not the ones that have a failed payment" — but the actual implementation only checks a _meta_purchase_tracked transient flag, not the order's WooCommerce status. The order status check exists as a comment but was never properly implemented.

The two bugs in the current code:

1. inject_purchase_event() hooks into woocommerce_thankyou and fires when the order-received page loads, regardless of whether the order is in processing, completed, cancelled, failed, or pending status. It should only fire for processing or completed orders.

2. CAPI server-side events fire for Facebook's own crawlers (facebookexternalhit/1.1, meta-externalads/1.1) hitting order-received URLs. These crawlers follow UTM-tagged URLs from ad click chains and trigger server-side events that are indistinguishable from real customer conversions.

Suggested fix (minimal):

In inject_purchase_event(), before firing the Purchase event, add:

$order = wc_get_order( $order_id );
if ( ! $order || ! in_array( $order->get_status(), [ 'processing', 'completed' ], true ) ) {
    return;
}

And for the crawler issue, before any CAPI event on checkout/order pages:

$ua = $_SERVER['HTTP_USER_AGENT'] ?? '';
if ( stripos( $ua, 'facebookexternalhit' ) !== false || stripos( $ua, 'meta-externalads' ) !== false ) {
    return;
}

Impact: Every WooCommerce store using block checkout + async payment gateway + Meta Ads is affected since WooCommerce 10.6 (March 10, 2026). This includes a huge number of Indian merchants using Razorpay (India's largest payment gateway), plus any store worldwide using PayPal, Mollie, or other redirect-based payment gateways. Meta Ads Manager is showing inflated purchase conversions, ad optimization is training on false data, and merchants cannot trust their ROAS metrics.

Please prioritize this. Happy to help test a fix if a PR is opened.

[tonsvalleyshop]

UPDATE: Pixel data confirms false Purchase conversions at scale

I've exported my pixel data from Meta Events Manager (Feb 24 – Mar 24, 2026) and cross-referenced it against actual paid orders in WooCommerce. The numbers confirm this bug is causing significant false conversion data.

The data:

• Actual paid WooCommerce orders (status: processing + completed), March 10–24: 578
• Raw Purchase events recorded by Meta pixel for the same period: 1,262
• That's 2.18x more Purchase events than actual purchases
• CAPI (server_received) accounts for 808 of those events, browser pixel accounts for 454
• 74 CAPI-only events (server_received > 0 with browser_received = 0) — these have no browser-side pair and cannot be deduplicated. Meta counts every one of these as a real conversion.

Pre-update vs post-update comparison:

Period	Days	Raw Purchase Events	Daily Avg	CAPI/Browser Ratio
Feb 24 – Mar 9 (before WooCommerce 10.6)	14	948	67.7	1.66x
Mar 10 – Mar 24 (after WooCommerce 10.6)	15	1,262	84.1	1.78x

That's a 24.3% increase in raw Purchase signals after WooCommerce 10.6 enabled auto-cancellation for block checkout orders. My actual sales did not increase by 24%.

Why this matters beyond reporting:

Even if Meta's reporting layer deduplicates some browser+CAPI pairs, the raw event volume is what Meta's ad delivery algorithm optimizes against. My campaigns are training on an audience that includes people who abandoned checkout and never paid. This degrades ad targeting quality, inflates ROAS metrics, and causes budget misallocation.

Root cause confirmed by all parties:

• WooCommerce (Happiness Engineer Kav): Confirmed PR #58262 now auto-cancels block checkout orders for the first time. Orders that previously sat as "pending" indefinitely are now cancelled.
• The Meta plugin: inject_purchase_event() fires on woocommerce_thankyou page load regardless of order status. It does not check if the order is in processing or completed status before sending the CAPI Purchase event.
• Facebook crawlers: facebookexternalhit/1.1 and meta-externalads/1.1 are visiting order-received URLs and triggering CAPI events server-side for orders that were never paid.

The fix remains the same (two lines):

$order = wc_get_order( $order_id );
if ( ! $order || ! in_array( $order->get_status(), [ 'processing', 'completed' ], true ) ) {
    return;
}

Add this at the top of inject_purchase_event() in facebook-commerce-events-tracker.php.

This bug has been reported three times across four years (#583, #2447, #3890) and has never been properly fixed. Each time it's closed or partially patched without addressing the core issue: the plugin fires Purchase events based on page load, not payment confirmation.

I have the full pixel export CSV available if your engineering team wants to analyze it.

@carterbuce @devbodaghe @rithikb24 @sol-loup @ashiqursuperfly @iodic — please prioritize this.

[Carl-Gustaf]

We are experiencing a similar issue started yesterday

[elstr]

I'm experiencing the same issue. I have 90 custom CAPI and 362 extra purchase events

[PrashantPunter]

Facing the same issue for a week now and they have been no update on it.