The Themehigh engineering team’s analysis of WooCommerce’s payment integrations spells out something most marketers haven’t connected to their analytics: Apple Pay and Google Pay express checkout deliberately bypass the standard WooCommerce checkout form. The popup or overlay is the entire UI. The standard checkout page never loads, which means begin_checkout, add_shipping_info, and add_payment_info never fire — even though the Purchase event on the thank-you page still does. BNPL volume on Black Friday 2025 hit $747.5M, up 8.9% year-over-year (eMarketer, 2025), with a growing share of it routed through mobile-wallet express checkout. From Smart Bidding’s perspective, those customers appear to convert without ever entering the funnel.
Why Apple Pay and Google Pay Are Quietly Corrupting Your WooCommerce Conversion Data
Express Checkout is a feature, not a bug. The whole point is to remove the form. Apple Pay reads the customer’s stored shipping and billing data from the device. Google Pay does the same. Stripe’s Express Checkout Element renders a popup overlay that collects only the essential order information — name, email, shipping, billing — and submits straight to checkout (Themehigh, 2025). The standard WooCommerce checkout form is never rendered, so nothing that depends on it firing happens either.
WooPayments — the payment gateway WooCommerce ships and actively promotes — enables Apple Pay and Google Pay together by default and doesn’t allow them to be enabled independently (WooCommerce documentation, 2025). Every WooPayments-enabled store inherits the funnel-skip pattern automatically. Stores that didn’t choose this behaviour are still subject to it.
The events that quietly disappear:
begin_checkout— fires when GTM4WP, FunnelKit, or Pixel Manager detects the standard checkout form rendering. Express Checkout doesn’t render that form.add_shipping_info— fires when shipping is selected on the checkout form. Apple Pay reads it from device storage; the WooCommerce shipping selector never opens.add_payment_info— fires when payment method is selected. The customer tapped a Pay button; no payment-method radio button was clicked.
The Purchase event still fires correctly because it’s tied to the order-received page, which Express Checkout does redirect to. Your conversion count looks fine. Your funnel data is hollow.
The Hollow Funnel Problem
The algorithmic damage isn’t theoretical. Smart Bidding, Meta Advantage+, and TikTok Smart+ all train on the relationship between funnel-stage events and final Purchase events. When a meaningful share of your purchases shows up with no begin_checkout, no add_payment_info, no add_shipping_info, the optimiser has to interpret that pattern. Two interpretations are possible:
- Ad blockers ate the funnel events but the conversion was rescued by some other signal. The optimiser will downweight the cohort, treating those buyers as unreliable training data.
- These were direct-traffic buyers who didn’t go through a normal customer journey. The optimiser will misclassify mobile-wallet customers as low-priority audience and stop bidding on the lookalikes that actually convert through the same path.
Neither interpretation is correct. Express checkout customers are usually your highest-intent buyers — repeat customers who saved their card to Apple Pay, mobile-first buyers who skipped the desktop funnel entirely, and BNPL users converting in two taps. The bidding model is being trained to deprioritise exactly the cohort the store wants more of.
For why even the Purchase event timing can be wrong on top of this, see WooCommerce Conversion Timing Problem | Fix Missing Orders.
How Big Is the Gap?
You can measure the corruption in five minutes. Run this in GA4:
begin_checkout count ÷ purchase count, over the last 30 days.
For a healthy WooCommerce store with a working funnel, this ratio sits anywhere from 1.5 to 4.0 depending on cart abandonment rate. If your ratio is below 1.2, or — alarmingly — below 1.0, you have purchases firing without a corresponding begin_checkout. That’s express checkout volume registering as conversions but not as funnel entries.
Mobile share in this ratio is usually the smoking gun. Segment the same calculation by device. If mobile begin_checkout ÷ mobile purchase looks broken while desktop looks normal, you’ve confirmed it: Apple Pay and Google Pay on mobile are funnelling customers around your tracking, not around your store.
The gap is widening, not stabilising. Mobile wallet integrations now enable in-store BNPL without QR codes — Afterpay (via Block) is integrated with both Apple Pay and Google Wallet in 2026 (eMarketer, 2026). Klarna Card on Apple Pay hit critical mass in Q1 2026. Every increment of mobile-wallet adoption adds another customer to the cohort your bidding algorithm is misreading.
You may be interested in: Payment Gateway Breaks WooCommerce Tracking
The Fix Is in PHP, Not JavaScript
The pixel-and-tag-manager approach to tracking assumes the customer interacts with a rendered form. Express Checkout broke that assumption permanently. The architectural answer is to stop relying on form interactions entirely and capture funnel events from WooCommerce’s own action hooks instead.
WooCommerce exposes the right hooks for this. woocommerce_before_checkout_form fires when the standard form renders. woocommerce_checkout_create_order fires whenever an order is being created, including from express checkout. woocommerce_payment_complete fires when payment finishes successfully, every time, every checkout method. From these hooks, the equivalent of begin_checkout, add_shipping_info, and add_payment_info can be reconstructed server-side from real order data instead of being inferred from form interactions that may never happen.
Transmute Engine™ is a first-party Node.js server that runs on your own subdomain — for example, data.yourstore.com — not a WordPress plugin. The lightweight inPIPE plugin attaches to those WooCommerce action hooks and sends a complete funnel sequence to your Transmute Engine server, which then transmits to GA4 (Measurement Protocol), Google Ads (Enhanced Conversions), Meta CAPI, and BigQuery. The customer who tapped Apple Pay produces the same funnel signal as the customer who clicked through the standard form. Smart Bidding sees one cohort, not two.
For a related GA4 visibility gap, see GA4 Has No Idea Which Payment Method Your Customers Use.
Key Takeaways
- Apple Pay and Google Pay express checkout deliberately skip the standard WooCommerce checkout form (Themehigh, 2025). It’s a UX feature, not a tracking bug — but it makes
begin_checkout,add_shipping_info, andadd_payment_infostop firing for those buyers. - WooPayments ships Apple Pay and Google Pay enabled together by default and they cannot be enabled independently (WooCommerce, 2025). Stores using WooPayments inherit the funnel-skip pattern automatically.
- The hollow funnel corrupts Smart Bidding training. Optimisers misclassify express-checkout cohorts as ad-blocker losses or low-priority direct traffic, and stop bidding on lookalikes that actually convert.
- The audit takes five minutes. Divide
begin_checkoutcount by purchase count in GA4 for the last 30 days. A healthy ratio is 1.5–4.0. Below 1.2 means express checkout is corrupting your funnel data. - The fix is server-side from WooCommerce action hooks (
woocommerce_before_checkout_form,woocommerce_checkout_create_order,woocommerce_payment_complete), not form-interaction triggers.
Frequently Asked Questions
<!– wp:yoast/faq-block {"questions":[{"id":"faq-question-b7faae71-9ea2-4469-bb6c-6de285aee61c","jsonQuestion":"Why are my Apple Pay and Google Pay purchases missing from my add-to-cart and initiate-checkout events?","jsonAnswer":"Apple Pay and Google Pay express checkout are designed to skip the standard WooCommerce checkout form — they render a popup or overlay that collects only essential order information directly from the device wallet (Themehigh, 2025). Most pixel and tag-manager plugins firebegin_checkout and add_payment_info from interactions on the standard checkout form. When the form never loads, the events never fire, but the Purchase event still does because it’s tied to the thank-you page.”},{“id”:”faq-question-f337d5d0-cff6-454b-b347-5349e2a2b9cc”,”jsonQuestion”:”Does Apple Pay express checkout fire begin_checkout in GA4?”,”jsonAnswer”:”Not in standard WooCommerce tracking setups. begin_checkout is fired by GTM4WP, FunnelKit, Pixel Manager, and most other pixel plugins when the standard checkout form renders. Express Checkout — Stripe Express Checkout Element, WooPayments Apple Pay/Google Pay buttons — bypasses the form rendering entirely, so the trigger never fires. The fix is to fire begin_checkout from a WooCommerce server-side hook instead, so it triggers regardless of which checkout UI the customer used.”},{“id”:”faq-question-d1d2f5b9-02f6-4e6e-98d7-d1ad4837759b”,”jsonQuestion”:”Will Apple Pay tracking gaps hurt my Smart Bidding optimisation?”,”jsonAnswer”:”Yes, and the damage compounds as mobile-wallet adoption grows. Smart Bidding, Meta Advantage+, and TikTok Smart+ train on the relationship between funnel events and Purchase events. Express-checkout buyers convert without firing begin_checkout or add_payment_info, so the optimiser interprets them as ad-blocker loss or low-quality direct traffic and downweights the cohort. The lookalike audiences the optimiser builds will then exclude exactly the high-intent mobile-wallet buyers the store wants more of.”},{“id”:”faq-question-ff277958-fd4a-417a-a75b-a47180237da4″,”jsonQuestion”:”Why does my GA4 funnel show purchases without preceding checkout events?”,”jsonAnswer”:”Most likely cause: a meaningful share of your customers used Apple Pay or Google Pay express checkout, which renders a popup overlay instead of the standard WooCommerce checkout form. Pixel plugins fire funnel events from form interactions on that page, so when the form is skipped, the events are skipped too. Run this check in GA4: divide begin_checkout count by purchase count over the last 30 days, segmented by device. A mobile ratio below 1.2 with a healthy desktop ratio confirms it.”},{“id”:”faq-question-052b9ba6-69fa-4ca5-bd93-e47241b5e98d”,”jsonQuestion”:”How do I fire add_payment_info for express checkout in WooCommerce?”,”jsonAnswer”:”The reliable approach is server-side: hook into woocommerce_checkout_create_order or woocommerce_payment_complete and emit add_payment_info with the actual payment method recorded on the order. This works for every checkout path, including Apple Pay, Google Pay, Shop Pay, and the standard form. Front-end JavaScript triggers can’t see Express Checkout reliably because the popup runs in a separate context and the form events the trigger watches for never fire.”}]} –>
Apple Pay and Google Pay express checkout are designed to skip the standard WooCommerce checkout form — they render a popup or overlay that collects only essential order information directly from the device wallet (Themehigh, 2025). Most pixel and tag-manager plugins fire begin_checkout and add_payment_info from interactions on the standard checkout form. When the form never loads, the events never fire, but the Purchase event still does because it’s tied to the thank-you page.
Not in standard WooCommerce tracking setups. begin_checkout is fired by GTM4WP, FunnelKit, Pixel Manager, and most other pixel plugins when the standard checkout form renders. Express Checkout — Stripe Express Checkout Element, WooPayments Apple Pay/Google Pay buttons — bypasses the form rendering entirely, so the trigger never fires. The fix is to fire begin_checkout from a WooCommerce server-side hook instead, so it triggers regardless of which checkout UI the customer used.
Yes, and the damage compounds as mobile-wallet adoption grows. Smart Bidding, Meta Advantage+, and TikTok Smart+ train on the relationship between funnel events and Purchase events. Express-checkout buyers convert without firing begin_checkout or add_payment_info, so the optimiser interprets them as ad-blocker loss or low-quality direct traffic and downweights the cohort. The lookalike audiences the optimiser builds will then exclude exactly the high-intent mobile-wallet buyers the store wants more of.
Most likely cause: a meaningful share of your customers used Apple Pay or Google Pay express checkout, which renders a popup overlay instead of the standard WooCommerce checkout form. Pixel plugins fire funnel events from form interactions on that page, so when the form is skipped, the events are skipped too. Run this check in GA4: divide begin_checkout count by purchase count over the last 30 days, segmented by device. A mobile ratio below 1.2 with a healthy desktop ratio confirms it.
The reliable approach is server-side: hook into woocommerce_checkout_create_order or woocommerce_payment_complete and emit add_payment_info with the actual payment method recorded on the order. This works for every checkout path, including Apple Pay, Google Pay, Shop Pay, and the standard form. Front-end JavaScript triggers can’t see Express Checkout reliably because the popup runs in a separate context and the form events the trigger watches for never fire.
Run the begin_checkout ÷ purchase ratio check today and segment by device. If mobile is broken, your bidding model is already learning the wrong lessons. See how Transmute Engine fires WooCommerce funnel events from server-side hooks instead of form interactions →



