Testing and troubleshooting

Place one prepaid and one COD order before going live, and fix the handful of things that commonly go wrong.

Test before going live

Two test orders prove the whole path: one that should fire immediately, and one that should not.

Turn on Preview. Preview your web container, and your server container too if you have one.
Optional but useful: put a Meta Test Event Code in the Meta tag or Receiver, and enable the sGTM Preview header on the container page so you can watch /data in server Preview.
On WooCommerce, check you are not an excluded role.
PixelFly → Advanced Settings → Excluded Roles. If Administrator or Shop Manager is ticked, you get no events at all and the test will look like a broken setup. Untick while testing, or order from a private window while logged out.
Place a prepaid order.
Expect: your purchase tags fire exactly as they do today. Nothing about prepaid orders changes.
Place a COD order.
Expect: only PixelFly COD Protection (hold) fires — on the server it should read Succeeded. No Meta, GA4, Google Ads or TikTok purchase. The order then appears in COD Held Orders with its value, products and customer.
Approve the held order.
Expect: with sGTM, Preview shows a Data Client purchase firing your Meta / GA4 / Google Ads tags. With Receivers, the order's fire response lists each Receiver that accepted it.
Clean up and publish. Remove the Meta test code, disable the Preview header, then publish.

If step 3 fires a purchase tag, stop and fix that before going live — it means the hold is not blocking the tag. The first two troubleshooting entries below cover why.

Troubleshooting

The hold tag does not fire at all

The host or API key is still a placeholder — the tag deliberately does nothing until both are real. Otherwise the purchase is reaching sGTM without cod_hold set to true, which usually means the web container's PixelFly - COD Protection is still off, or your store is not marking the order as COD.

Purchase tags still fire on a COD order

Each tag that sends a purchase needs the COD hold trigger as an exception. Our ready-made containers already do this; in your own containers it is easy to miss one. Check every purchase tag, including TikTok and the PixelFly server-side tag.

“Missing order_id”, but Preview clearly shows a transaction_id

An Exclude parameters transformation is stripping it before the tag runs. Add the hold tag to that transformation's excluded tags. Preview's Event Data shows the event before transformations, which is why it looks fine there.

401 unauthorized

The wrong secret. Holding an order needs the API Key (pf_live_…); the webhook secret (pfwh_…) only confirms orders.

The order is held, but has no customer or products

Your purchase event uses different field names. Compare it with the expected purchase event.

WooCommerce counts COD orders at checkout anyway

The plugin's COD Order Protection switches itself off while the plugin holds an API key. Clear the plugin's API Key — with a PixelFly GTM container, the container sends the server-side events.

The order stays “approved” and never fires

Open the order — the fire response names the reason. The usual ones: quota_exceeded (your monthly limit is used up), no value or currency on the order, no Receiver accepted it, or no fire path chosen in the Power-up.

← Full walkthrough

API reference →