TL;DR
The most expensive tracking failure on Magento 2 is also the most boring one. A store swaps in a faster checkout, everything works, orders flow, and GA4 stops recording purchases because the success page is no longer at the URL the tracking layer watches. Nothing errors. The fix is configuration rather than code: list your real checkout and success paths in the extension's settings, then verify each layer separately, because the client-side per-step events and the server-side Measurement Protocol events fail for different reasons. This piece walks where events die on a non-default checkout, what the path override actually does, and the two checkout variants that behave differently even when your paths are right.
Key Takeaways
- Magento's default paths are
checkout/index/indexfor checkout andcheckout/onepage/successfor the success page. Tracking is built around those, and a custom checkout usually replaces at least one [1]. - Checkout Page Paths and Success Page Paths are configuration fields where you list the real paths, so transaction data still reaches Google Analytics [1].
- Client-side tracking covers each checkout step on both tiers: billing address, shipping address, shipping options, and payment options [1].
- PRO adds server-side Measurement Protocol coverage for Begin Checkout, Add Payment Info, Add Shipping Info, and Purchase, which do not depend on the checkout's front end at all [1].
- Hyvä Checkout is supported on the PRO tier [1], and Hyvä compatibility ships as two composer modules with no configuration options of their own [1].
- Magento's multi-shipping checkout generates several orders from one session, and PRO sends a purchase event per generated order, a capability added in v1.12.7 in July 2023 [1].
- Server-side purchase tracking is the reason a broken checkout front end costs you reporting rather than revenue data, since the event originates from the order.
The failure looks like nothing at all
A merchant replaces the default Magento checkout. The new one converts better, the launch goes fine, and everyone moves on. Three weeks later somebody notices GA4 revenue for the month is a fraction of what Magento reports, and the investigation starts in the wrong place: the GTM container, the measurement ID, the consent banner, the tags.
None of those are broken. The tracking layer is waiting for a page that no longer exists at that address.
This is worth naming precisely, because the symptom pattern is distinctive. Sessions look normal. Product views look normal. Add-to-cart looks normal. Then the funnel drops to near zero at checkout, or purchases vanish while everything upstream is healthy. If your GA4 funnel has a cliff exactly at the checkout boundary and Magento's sales reports look fine, stop debugging tags and go look at the URL of your success page.
The related symptom, missing transactions with a checkout that was never changed, has a different set of causes entirely, covered in the writeup on missing transactions and revenue in GA4.
Why a path assumption exists in the first place
Magento's checkout has a defined route. The checkout page lives at checkout/index/index and the order confirmation page at checkout/onepage/success [1]. (Magento's own checkout runs on the onepage route; what changes here is a replacement one-page or one-step checkout.) Client-side ecommerce tracking has to know which page is which, because the purchase event fires on the success page and only on the success page. Firing it anywhere else would produce a transaction per page view.
So the tracking layer holds an assumption about your URL structure, and a replacement checkout breaks that assumption without breaking anything else. The order is created. The confirmation renders. The customer is happy. The one thing that did not happen is the event.
This is a configuration problem rather than a compatibility problem, and the difference matters when you are evaluating options. There is no per-checkout integration to wait for. There is a path to declare.
The setting that fixes it
Two fields, both under General Configuration in the extension's admin [1]:
-
Checkout Page Paths. For stores whose checkout page path differs from the default
checkout/index/index, list the real path here so checkout tracking applies to it. -
Success Page Paths. For stores whose success page differs from the default
checkout/onepage/success, list the real path so transaction data is sent to Google Analytics.
The option for custom checkout page paths arrived in v1.12.1 on May 30, 2023, added specifically to cover checkout solutions that change or alter the default Magento checkout page path [1]. The success-page side is older: v1.11.1, on April 25, 2022, added support for custom success page URLs [1]. Tracking transactions on custom success page URLs is a STANDARD-tier feature; server-side Measurement Protocol coverage of the checkout funnel is the part that requires PRO [1]. A STANDARD-tier store with a replaced checkout is not stuck.
If your success URL contains a dynamic segment (an order ID, a payment provider's reference), the field accepts an asterisk as a wildcard so one entry covers every order [1]. That release note is the reason: the wildcard exists specifically for third-party payment methods that build a per-order URL.
Three practical notes on filling these in, because the fields are simple and the mistakes are repetitive.
Get the paths from your live store, not from documentation or memory. Complete a real order and copy what is in the address bar, dropping the domain and any query string.
Check every store view. A multi-store instance can route store views through different checkout implementations, and a path that is right for one is silently wrong for another.
Re-check after every checkout change, including ones you did not make. A payment provider's redirect flow can move the confirmation page, and nobody sends an email about it.
And because the extension generates its GTM container JSON from your Magento configuration, changing these settings means re-generating, re-importing, and publishing the container before the change is live on the storefront [1]. An imported workspace is still a draft.
Where the event dies, layer by layer
A custom checkout can break tracking at three different depths, and each one has its own tell.
Layer one, the storefront checkout steps. Client-side tracking covers each step of the checkout process: billing address, shipping address, shipping options, and payment options [1]. These events come from the storefront, so a checkout that renders its own front end and never triggers the extension's step tracking loses them. The tell is a GA4 funnel where add-to-cart is healthy and everything from the checkout page onward, begin_checkout included, is empty.
Layer two, the success page. Covered above. The tell is purchases missing while everything before them is present.
Layer three, the server. On PRO, the Measurement Protocol sends Begin Checkout, Add Payment Info, Add Shipping Info, and Purchase from Magento itself [1]. This layer does not care what your checkout front end looks like, because the event is built from the order. That is the strategic point of this article: a store on a heavily customized checkout gets more value from server-side purchase tracking than a store on the default one, because the server-side path has no front-end assumptions to break. The tell here is different too, since a missing server-side purchase points at the Measurement Protocol configuration or an order status exclusion rather than at anything in the checkout.
Run the three layers in reverse. Confirm the server-side purchase first, since that is the number your business actually reports on, then work back up to the client-side steps, which are diagnostic detail. The general server-side setup is covered in the Magento 2 GA4 server-side tracking setup guide.
Two checkout variants that behave differently
Hyvä Checkout. Hyvä Checkout is supported on the PRO tier [1], and Hyvä compatibility ships as two composer modules, weltpixel/module-hyva-ga4 and weltpixel/module-hyva-ga4-csp, with no configuration options of their own [1]. Since the Hyvä theme went free and open source effective November 10, 2025 [3], this is one of the few custom checkout situations where the answer is an install rather than a path declaration. The theme-side story is covered in the older writeup on GA4 compatibility with the Hyvä theme.
Multi-shipping checkout. Magento's multi-shipping flow produces several orders from a single checkout session, which breaks the one-checkout-one-purchase assumption that most tracking is built on. The extension triggers a purchase event for each generated order, client-side and through the Measurement Protocol, on the PRO tier, added in v1.12.7 on July 26, 2023 [1]. Add Payment Info compatibility for the same flow followed in v1.12.9 on September 5, 2023 [1]. If you sell to customers who ship to multiple addresses, verify this specifically, because a partial capture here understates revenue in a way that looks like a general shortfall rather than a flow-specific one.
How do you verify a non-default checkout is tracked?
The sequence that isolates the layers, in order:
- Place a real order. Test mode and simulated checkouts frequently skip the exact page transition that matters.
- Copy the paths. Record the checkout URL and the success URL from the address bar during that order, then compare them character for character against what is configured.
-
Check the server side. With file logging enabled, confirm a purchase payload was written to
var/log/ga4.log, then confirm the order carries the marker in the order grid's Measurement Protocol column, which is filterable [1]. - Check the client side. Use GTM preview mode during a second order to see which tags fired and which triggers matched. This is where a path mismatch shows up as a trigger that never evaluated true.
- Check GA4. Confirm the purchase arrived with the right transaction ID and value, and that you have one purchase rather than two.
Most stores find their answer at step two. When steps three and four disagree, that disagreement is the diagnosis: server-side present with client-side absent means the front end never fired, and the reverse means the Measurement Protocol configuration or an order status exclusion is the problem. For stores that have not set the foundation yet, how to add Google Analytics 4 to Magento 2 is the earlier step.
One thing to settle before it becomes urgent: whoever owns your checkout should tell whoever owns your analytics when a checkout path changes. That is a process, not a setting, and it is the only defense against rediscovering this article every eighteen months.
FAQ
What are the default Magento 2 checkout and success page paths?
checkout/index/index for the checkout page and checkout/onepage/success for the order confirmation page. The extension's Checkout Page Paths and Success Page Paths settings exist for stores where either has been replaced [1].
Does a custom checkout require a code change to track properly?
Usually no. The documented mechanism is configuration: list the real checkout and success paths in the extension settings, then re-generate and re-import the GTM container so the change is live [1].
Does the STANDARD version support custom success page URLs?
Yes. Tracking transactions on custom success page URLs is a STANDARD-tier feature; server-side Measurement Protocol coverage of the checkout funnel is the part that requires PRO [1].
Which checkout events does the server side cover?
On PRO, the Measurement Protocol sends Begin Checkout, Add Payment Info, Add Shipping Info, and Purchase. These originate from Magento rather than the browser, so they are unaffected by a custom checkout front end [1][2].
How does multi-shipping checkout get tracked?
Magento's multi-shipping flow creates one order per shipping destination, and PRO sends a purchase event for each generated order, on the client side and through the Measurement Protocol. Support arrived in v1.12.7 and was extended with Add Payment Info in v1.12.9 [1].
If your Magento store runs a checkout that is not the default one and GA4 has been quiet about purchases ever since, the WeltPixel Google Analytics 4 PRO extension covers both halves of the fix: the path settings for the client side, and Measurement Protocol purchase tracking that never looks at your checkout's front end in the first place. Copy your real success URL out of the address bar before you change anything else.
Sources
- WeltPixel Google Analytics 4 User Guide, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- Google Analytics, "Recommended events" (GA4 ecommerce events), https://developers.google.com/analytics/devguides/collection/ga4/reference/events
- Hyvä, "Hyvä is going Free & Open Source", November 6, 2025, https://www.hyva.io/blog/news/hyva-is-free-open-source.html