WooCommerce Purchase Event Missing After Stripe Redirect: Fix

The order is in WooCommerce. The money is in Stripe. GA4 shows nothing, or a purchase with value 0, or a number that matches the cart but not what the customer actually paid. The cause is almost always the same: your purchase tag depends on the customer's browser making the round trip back to your thank-you page with the right data in hand, and off-site payment breaks that trip.

This applies to Stripe-hosted checkout through the WooCommerce gateway and to any bank-redirect method (iDEAL, Bancontact, Przelewy24, local bank buttons). Standalone Stripe Payment Links behave differently, because they create no WooCommerce order at all - see the FAQ. I fix this setup for stores weekly. Here is what actually goes wrong and the pattern that survives.

Why thank-you-page scripts miss redirect returns

A purchase tag that lives on the order-received page only fires if the customer's browser loads that page. With off-site payment, a meaningful share of paying customers never do:

• They close the tab. Stripe's hosted page already told them the payment succeeded. The job is done in their head. With Payment Links on default settings, Stripe shows its own confirmation page and the customer may never be redirected to your site at all.
• 3DS detour. The bank's authentication step often pushes the customer into a banking app. They approve the payment there and go back to whatever they were doing. The original tab with the redirect chain is abandoned.
• Cross-device completion. The customer starts on desktop, confirms in a mobile banking app, and if they return at all it is on a different device with a different GA4 client ID. The purchase is attributed to a new user, or lost.
• Slow payment methods. Some bank transfers confirm minutes or hours later. There is no browser session left to fire anything.

Typical damage: 10-30% of purchases missing from GA4 and Meta, which quietly starves your ad optimization of the conversions it needs.

Why the localStorage total-scrape hack breaks

A common workaround: before the redirect, a script reads the checkout total from the DOM, stores it in localStorage, and reads it back on the return page. I remove this pattern from client sites regularly. It fails four ways:

• Storage does not follow the customer. Complete the payment on another device, in another browser, or in an in-app browser that opens the return link in the system browser, and the stored value is not there. The event fires with value 0 or undefined.
• NaN. The scraper parses a formatted string like 1 234,56 €. One locale change, one theme update to the totals markup, and parseFloat returns NaN. GA4 drops or mangles the value silently.
• Deposits and partial payments. The scraped number is the cart total at redirect time. If the customer pays a deposit, uses a gift card at the hosted page, or the amount changes at Stripe, your reported revenue is wrong. Wrong data is worse than missing data because nobody questions it.
• ITP and private mode. Safari purges script-writable storage after seven days without interaction, and private browsing keeps nothing. Delayed bank confirmations come back to an empty store.

The deeper problem: the browser is the wrong source of truth for money. The backend already knows the real total.

The fix: render the purchase push from the order object

WooCommerce's order-received URL contains the order ID and key. The server can load the full order and print a dataLayer push with backend numbers. No scraping, no storage, no guessing.

add_action( 'woocommerce_thankyou', function( $order_id ) {
    $order = wc_get_order( $order_id );
    if ( ! $order || ! $order->is_paid() ) {
        return; // do not fire for pending or failed redirects
    }
    if ( $order->get_meta( '_purchase_tracked' ) ) {
        return; // refresh guard: fire once per order
    }
    $order->update_meta_data( '_purchase_tracked', 'yes' );
    $order->save();
    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    dataLayer.push({
        event: 'purchase',
        transaction_id: '<?php echo esc_js( $order->get_order_number() ); ?>',
        value: <?php echo (float) $order->get_total(); ?>,
        currency: '<?php echo esc_js( $order->get_currency() ); ?>'
    });
    </script>
    <?php
} );

Three details carry the weight here:

• Value from the backend. $order->get_total() is what was actually charged, including deposits, coupons, and gift cards. It cannot be NaN.
• Refresh guard via order meta. Customers reload the thank-you page and click it from the order email days later. The meta flag makes the push render once. GA4 also deduplicates identical transaction_id values, but do not rely on that alone, and Meta needs an explicit event_id anyway.
• Paid-status check. Bank-redirect orders can land on the thank-you page while still pending. is_paid() stops you from reporting revenue on payments that later fail.

This fixes every case where the customer does return. For the customers who never come back at all, no on-page code can help. That class is solved server-side: the Stripe webhook confirms payment, and the server sends the purchase directly via GA4 Measurement Protocol and Meta Conversions API, deduplicated against the browser event by transaction_id and event_id. That is the setup I build for clients when the redirect losses are large.

How to verify it is actually working

Do not trust the plugin settings page. Run a real test order through the real off-site flow, 3DS included, and watch the wire:

• Tag Assistant: connect your domain at tagassistant.google.com, complete a test payment, and on the return to order-received check that the purchase event appears in the dataLayer and that your GA4 event tag fired on it. The Tag Assistant connection sometimes drops across the Stripe redirect - if it does, verify via the network tab instead.
• Browser network tab: on the order-received page, open DevTools, filter requests for collect. Find the POST to google-analytics.com containing en=purchase. Check epn.value against the order total and cu against the currency. If the request is absent, the tag never fired. If value is 0 or missing, your data source is broken.
• GA4 DebugView: with Tag Assistant connected (or debug_mode set), open Admin, then DebugView. Confirm the purchase arrives with transaction_id, value, and currency populated.
• Meta Events Manager: open Test Events, run the flow in the same browser, and confirm a Purchase with the correct value and a matching event_id on both the browser and server event so Meta deduplicates them.
• The gap check: compare purchases in GA4 against paid orders in WooCommerce for the last 7 days. A consistent 10%+ shortfall on a store with off-site payment is redirect loss, not "tracking noise".

Stop sessions collapsing to referral / stripe.com

Even when the purchase fires, GA4 can credit it to the wrong channel. The customer leaves your site for stripe.com or their bank's 3DS page and comes back. GA4 sees stripe.com as the referrer, starts a new session, and your paid or organic attribution is overwritten by referral / stripe.com.

The fix is the unwanted referrals list. In GA4: Admin, then Data streams, select your web stream, open Configure tag settings, choose Show all, then List unwanted referrals. Add stripe.com. If your acquisition reports also show bank or 3DS authentication domains as referrers, add those too. GA4 will then ignore these referrers and keep the original session source intact.

Check the result in Reports under Traffic acquisition: referral traffic from stripe.com should drop to zero for new sessions, and your purchases start attributing to the campaigns that actually earned them.