Once tracking is live, two screens tell you whether it’s actually working: the payment-gateway accuracy report and the recent-events log. Both are built from your real order data.

The accuracy report

Open Home → Accuracy (or the Accuracy tab) to see, for each payment gateway over the last 30 days, how many paid orders were tracked and how many were missed. This is the quickest way to catch a gateway-specific gap, such as an off-site wallet that returns customers through a different flow than your card gateway.

When a row reports misses, it lists the specific order IDs involved (up to ten) so you can open those orders and look into them. Usually it’s a customer who declined consent, or an order placed before tracking was set up.

The recent-events log

The Recent events view lists the latest purchase events and how they were delivered to each destination. The status column has three states:

• Tracked. The event was recorded and dispatched to its destinations.
• Waiting for consent. Not an error. The order is held because the customer hasn’t granted consent (or has declined it), and it can still recover if consent changes later.
• Failed. The only state that’s a real, terminal failure worth investigating, typically a rejected server-side send. Browser tags aren’t marked failed here.

Each row also shows which client destinations (GA4, Google Ads, Meta Pixel) received the event, so you can confirm a given platform is getting data without leaving WordPress.

Cross-check at the source

For final confirmation, place a real test order and watch it appear in GA4 Realtime (Reports → Realtime) and in the Test events tab of Meta Events Manager. If an event shows as Tracked here but never reaches the platform, the cause is almost always a wrong ID or a consent block. See Troubleshooting.