Many Indian Shopify brands replace the native checkout with a third-party one: GoKwik, Shiprocket Checkout, and similar tools that prefill addresses, offer COD controls and speed up payment. They often lift checkout conversion. They also move the most important step in the funnel to a surface your existing tags were not built for. The symptoms are familiar: GA4 shows fewer purchases than Shopify, Meta reports purchases with no value, revenue lands under direct or referral, or every order counts twice. This article explains why that happens and the fix I apply, which is to stop relying on the browser for the purchase and take it from the order.
Why third-party checkouts break purchase tracking
On a standard Shopify store, the checkout and thank-you page are controlled by Shopify, and its customer events system lets the Meta, Google and custom pixels see checkout steps and the purchase in a predictable way. A third-party checkout takes over at the moment the customer clicks buy. Depending on the provider and how it is installed, the checkout runs as a popup or overlay on your domain, a page on the provider's domain, or a flow that creates the order in Shopify through the API after payment. In each case, the events your theme tags expect, begin_checkout, add_payment_info and purchase, are either fired by the provider's own scripts, fired by yours with missing data, or not fired at all. The thank-you page the customer sees may not be Shopify's, so a purchase tag that lives there never loads. And if the provider redirects through a payment gateway on another domain, GA4 can record the return visit as a new session from the gateway, which is why revenue ends up credited to referral or direct.
The symptoms to look for
Before changing anything, compare three numbers for the same week: orders in Shopify, purchases in GA4, and Purchase events in Meta Events Manager. If GA4 and Meta are well below Shopify, purchases are being missed, usually because the purchase tag lives on a page that the new checkout bypasses. If Meta is higher than Shopify, you probably have two sources firing, for example the provider's built-in Meta integration and your own pixel or app, without a shared event_id. In GA4, look at purchase revenue by session source and medium. Payment gateway domains, or the checkout provider's domain, showing up as referral sources is the tell for cross-domain breakage. Also check the purchase event payload in GA4 DebugView or Meta's test events: missing transaction_id, value or currency, or items arrays that are empty, all point to events fired by a script that does not have access to the order data. Write down what you find, because the provider's support team will need specifics.
What the providers offer, and its limits
Most third-party checkout providers in India offer their own integrations with GA4, Meta and Google Ads, configured in their dashboard with your measurement ID and pixel ID. Use their documentation as the starting point, because the right setup depends on how their checkout is installed on your store. These integrations are useful, but they have limits I plan around. You depend on the provider's event mapping, which may not match the naming and parameters in your GA4 taxonomy. Browser-side events from the checkout are still subject to ad blockers and browser privacy restrictions. And if you also have a Shopify app or GTM setup sending purchases, you now have two sources with different event_ids, which is how double counting starts. My rule is one owner per event per destination: decide whether the provider, Shopify's native channel, or your own server container sends Purchase to each platform, then switch the others off for that event.
The fix: take Purchase from the order, server-side
The most reliable source of truth for a purchase is the Shopify order record, because every checkout provider ultimately creates one. I subscribe to Shopify's order creation webhook, or order paid or fulfilment updates for COD logic, and send it to a server-side GTM container or a small cloud function. That server event becomes the purchase for GA4 through the Measurement Protocol and for Meta through the Conversions API. For it to be attributed properly, the server needs identifiers from the browser session: the GA4 client_id and session_id, the Meta fbp and fbc cookies, and any gclid. Those must be captured before the customer enters the checkout and attached to the cart or order, typically as cart attributes that Shopify carries onto the order as note attributes. Many checkout providers pass cart attributes through to the order; test that yours does. With those identifiers on the order, the server-sent purchase joins the right GA4 session and matches to the right Meta user, regardless of which checkout UI the customer saw.
Deduplication and cross-domain hygiene
If you keep any browser-side purchase event, from the provider or your own tags, it must share an identifier with the server event. For Meta, set event_id to the Shopify order ID or a value derived from it on both sides, so the Conversions API and pixel events deduplicate. For GA4, use the same transaction_id, which GA4 uses to deduplicate purchases. If you cannot make the browser event carry the order ID reliably, turn it off and rely on the server event alone. For sessions, add payment gateway domains and the checkout provider's domain to GA4's list of unwanted referrals so a return from the gateway does not start a new session. If the checkout runs on a different domain, ask the provider whether it supports cross-domain measurement with your GA4 property. These are small settings, but they are the difference between revenue attributed to the campaign that drove it and revenue credited to a payment gateway.
How I validate the fix
After the change, I place test orders through each payment path: prepaid UPI, card, wallet and COD, on mobile and desktop. For each, I check that exactly one purchase reaches GA4 with the right transaction_id, value, currency and items, that Meta shows one Purchase with server as source and browser too if you kept it, deduplicated, and that the GA4 session source is the original campaign rather than a gateway. Then I watch the Shopify versus GA4 versus Meta comparison for two to three weeks. The numbers will not match exactly, because of consent, bots and attribution logic, but the gap should be small and stable rather than large and variable. If it drifts after a provider update, which happens, the comparison catches it within a week instead of a quarter. I put that weekly comparison in the reporting dashboard so nobody has to remember to run it.
FAQ
The purchase tag usually depended on Shopify's native checkout or thank-you page, which the third-party checkout bypasses. Sending purchase from the Shopify order via a webhook and the GA4 Measurement Protocol, with the client_id captured before checkout, restores it.
Two sources are sending Purchase, often the checkout provider's integration and your own pixel or app, without a shared event_id. Pick one owner per event, or make both carry the Shopify order ID as event_id so Meta can deduplicate.
It is a reasonable starting point, but I prefer a server-side purchase from the Shopify order as the source of truth, because it is independent of the checkout UI and of browser restrictions. If you keep the provider integration, deduplicate it against the server event.