You followed the guides. You installed the GA4 plugin or set up GTM. You checked that begin_checkout and purchase are firing. But add_payment_info and add_shipping_info never appear — not in your DebugView, not in your funnel exploration, nowhere. This isn’t a misconfiguration. It’s an architectural impossibility for client-side tracking on the WooCommerce Block checkout. And until it’s resolved, your GA4 funnel has a gap that makes checkout optimisation guesswork.
What the Block Checkout Changed
WooCommerce introduced the Checkout Block as the default checkout experience in version 8.3 — a significant architectural change for DOM-based event tracking (WooCommerce Documentation, 2024). In the classic shortcode checkout, form fields were rendered as traditional HTML elements. JavaScript could monitor DOM changes and detect when a customer interacted with the payment or shipping sections.
The Block checkout is a React-rendered component. It doesn’t expose the same DOM events. Payment method selection and shipping option choice happen within the React component’s internal state — state that client-side tracking scripts cannot observe from the outside.
The plugin developer behind WooCommerce’s own GA4 integration confirmed this directly on WordPress.org: “add_payment_info and add_shipping_info are not done yet — a general rule for them is tricky to find.”
Tricky to find, because the events the GA4 spec expects to observe don’t exist in the Block checkout’s DOM. It’s not that the tracking code isn’t watching. It’s that there’s nothing to watch.
Why Client-Side JavaScript Can’t Capture These Events
The classic checkout had a predictable moment: when a customer clicked a payment radio button, a DOM event fired. JavaScript could listen for that, grab the selected method, and fire add_payment_info. Clean, observable, trackable.
The Block checkout doesn’t have radio buttons in the classic sense. It uses controlled React components that manage their own state internally. When a customer selects a payment method, the state change happens inside the React component tree — invisible to external JavaScript that’s looking for DOM mutations.
Some GA4 plugins attempt workarounds: monitoring for specific class changes, using intersection observers, or triggering on any interaction near the payment block. These approaches are fragile. They break with plugin updates, theme changes, or WooCommerce Block component revisions. And they run in the browser — where 31.5% of global users have ad blockers that suppress tracking scripts entirely (Statista, 2024).
A tracking event that depends on DOM mutation in a React checkout is not just unreliable. It’s structurally unsound — because the signal it needs doesn’t exist in the DOM.
You may be interested in: Your GA4 Purchase Events Are Firing. The Revenue Values Are Wrong.
What Your GA4 Funnel Report Is Actually Showing You
Without add_payment_info and add_shipping_info, your GA4 checkout funnel has this shape:
view_itemorview_item_listadd_to_cartbegin_checkout- — (nothing) —
purchase
GA4 funnel exploration requires mid-funnel events to identify checkout drop-off — without them, funnel analysis shows only the entry and exit of the checkout process, with no visibility into where customers leave (Google Analytics Help, 2025). You can see that customers are dropping between begin_checkout and purchase. You cannot see whether they’re leaving at the shipping step or the payment step. You cannot test interventions against a specific step. You cannot attribute abandonment to a payment method or a shipping option.
73% of GA4 implementations have silent misconfigurations causing 30–40% data loss (SR Analytics, 2025). Missing funnel events are a major contributor — not because the tracking code is wrong, but because the expected data simply doesn’t reach GA4. The result is a funnel report that looks functional and is structurally incomplete.
You’re not optimising a funnel. You’re optimising a funnel with its middle removed.
What Correct Checkout Funnel Data Should Look Like
A complete GA4 ecommerce funnel for a WooCommerce store should include these events in sequence:
view_item— Product page viewedadd_to_cart— Item added to cartbegin_checkout— Checkout initiatedadd_shipping_info— Shipping method selected (withshipping_tier)add_payment_info— Payment method selected (withpayment_type)purchase— Order completed
With all six events present, you can identify the exact step where customers abandon. You can test whether a new payment option reduces abandonment at step 5. You can identify whether free shipping triggers more step-4 completions. You can calculate the conversion rate between every step — not just between the first and last.
67% of data professionals say they can’t trust their analytics data for business decisions (Precisely Data Integrity Trends Report, 2025). For WooCommerce stores running the Block checkout, missing mid-funnel events are a direct cause of that distrust — and of the optimisation decisions that can’t be made confidently because the funnel data isn’t complete.
You may be interested in: GA4 Revenue Keeps Changing After You Report It
The Fix: WooCommerce Hook-Based Server-Side Capture
WooCommerce hooks are the architectural layer that the Block checkout does expose cleanly. When a customer selects a shipping method, WooCommerce fires a server-side hook. When they choose a payment method, another hook fires. These hooks are reliable, consistent, and Block-checkout-compatible — because they operate at the WooCommerce application layer, not the browser DOM layer.
Server-side tracking that listens to WooCommerce hooks can capture add_shipping_info and add_payment_info with complete, accurate data:
add_shipping_info: Fires from the WooCommerce shipping rate selection hook — includes the shipping tier, order value, and cart contentsadd_payment_info: Fires from the WooCommerce payment method update hook — includes the payment type and cart total
Both events are sent to GA4 via the Measurement Protocol — server-to-server, bypassing ad blockers, independent of the React component state, and compatible with every version of the Block checkout.
The Transmute Engine™ captures both events from WooCommerce hooks and routes them to GA4 Measurement Protocol — no GTM required, no DOM observation, no fragile JavaScript workarounds. The result is a complete checkout funnel in GA4 that shows every step between begin_checkout and purchase, including which shipping options and payment methods customers actually select before converting or abandoning.
Key Takeaways
- It’s architectural, not configuration: The Block checkout renders as a React component. Client-side JS cannot observe payment and shipping selection from outside the component tree.
- Plugin workarounds don’t hold: DOM-based detection of React component state is fragile, breaks with updates, and fails for the 31.5% of users with ad blockers.
- The missing events break funnel analysis: Without
add_shipping_infoandadd_payment_info, you can only see where the funnel starts and ends — not where customers actually leave. - WooCommerce hooks solve it reliably: Server-side hook listeners capture both events cleanly, consistently, and Block-checkout-compatibly — because they operate at the application layer, not the DOM layer.
Because the WooCommerce Block checkout renders as a React component, and client-side JavaScript cannot observe payment method selection or shipping option choice from outside the React component tree. These events require DOM signals that the Block checkout doesn’t produce — making client-side capture structurally impossible for most tracking setups.
Not through standard client-side tracking. The Block checkout’s React-rendered architecture means the DOM events that GA4 pixels typically listen for don’t exist. Server-side tracking via WooCommerce hooks is the reliable alternative — capturing events at the application layer where the checkout state is accessible.
Use server-side tracking that listens to WooCommerce’s native hooks for shipping and payment selection. These hooks fire when customers choose a shipping method or payment type — regardless of Block checkout version — and the events can be sent to GA4 via Measurement Protocol without any browser dependency.
No. It’s a structural limitation of client-side tracking on the WooCommerce Block checkout. Even correctly configured GA4 plugins cannot capture add_payment_info or add_shipping_info reliably from the Block checkout, because the DOM signals required don’t exist. The fix requires a server-side approach, not a reconfiguration of existing client-side tools.
A GA4 funnel without add_payment_info and add_shipping_info can tell you that customers are abandoning checkout. It can’t tell you why — or at which step. Server-side tracking via WooCommerce hooks closes that gap, turning a two-point funnel into a complete six-step picture of checkout behaviour your optimisation decisions can actually use.
