Why Payment Gateway Redirects Destroy Your Campaign Attribution
Your Meta campaign drove 400 purchases last month. GA4 credits it with 180.
The other 220 are sitting in direct / none, or attributed to a domain called razorpay.com.
This is one of the most common attribution failures in Indian ecommerce, it is invisible unless you look for it specifically, and the fix takes about five minutes once you know what you are looking at.
What Actually Happens
A buyer clicks your Meta ad, lands on your store, adds to cart, and proceeds to checkout. So far GA4 is tracking one session attributed to your campaign.
Then they pay. The browser leaves your domain for the payment gateway - Razorpay, Cashfree, PayU or opens a UPI app entirely. Payment completes. They return to your order confirmation page.
GA4 sees a visitor arriving from an external domain it does not recognise. So it does two things at once:
It starts a new session. One customer journey is now split into two or more sessions in your reporting.
It overwrites the traffic source. Under GA4's default attribution, the new session is credited to the referring domain, the payment gateway. Your purchase event fires inside that new session.
The result: the campaign that drove the visit gets credit for the add-to-cart and nothing else. The gateway gets credit for the sale.
Why This Hits Indian Brands Harder
Three reasons this is more damaging here than in card-dominant markets.
UPI means more round trips. A UPI payment typically leaves the browser entirely and opens a payment app. That is a harder context switch than an inline card form, and it produces a cleaner break in the session.
Multiple gateways run simultaneously. Many Indian stores route different payment methods through different providers. Each one is a separate domain, and brands who excluded one gateway often never added the others.
Checkout platforms add another domain. If you run GoKwik, Shopflo, Fastrr or a similar layer, the checkout itself may sit on a different domain from your store. That is a second break in the chain, before the gateway redirect even happens.
COD orders do not have this problem, which creates a misleading pattern: prepaid conversions appear to come from direct traffic while COD conversions retain their campaign attribution. Teams sometimes read this as prepaid buyers being more brand-loyal. They are not. Their attribution is just broken.
How to Diagnose It
Three checks, about ten minutes.
1. Look for gateway domains in your traffic report.
Go to Reports → Acquisition → Traffic acquisition. Set the primary dimension to Session source / medium. Scan for anything that is a tool rather than a traffic source — razorpay.com, cashfree.com, payu.in, checkout.shopify.com.
A useful threshold: more than ten sessions showing the pattern in thirty days is a real leak rather than noise.
2. Check your direct traffic share.
If direct / none is above 20–25% of sessions and climbing, gateway leakage is one of the likely causes. Direct traffic landing on an order confirmation page is particularly diagnostic, nobody types that URL from memory.
3. Compare GA4 campaign conversions against your ad platform.
Meta and Google will always claim more conversions than GA4 for structural reasons. But if the gap is unusually wide specifically for purchases, and your add-to-cart attribution looks fine for the same campaigns, the break is happening at payment.
Our guide to why Meta and GA4 never show the same number covers how to separate this cause from the structural ones.
The Fix
In GA4: Admin → Data Streams → [your web stream] → Configure tag settings → Show all → List unwanted referrals
Add each payment and checkout domain. GA4 then appends ignore_referrer=true to events from those domains, so the return visit is treated as a continuation of the existing session rather than a new one.
Domains to add
Payment gateways
razorpay.com
cashfree.com
payu.in
ccavenue.com
billdesk.com
instamojo.com
easebuzz.in
paytm.com
phonepe.com
Checkout platforms, if you use one
The domain your checkout layer runs on, check an actual order flow rather than assuming
International gateways, if applicable
stripe.com
checkout.stripe.com
paypal.com
adyen.com
Platform domains
checkout.shopify.com, if your checkout runs there
Only add what you actually use. There is a limit of 50 entries per data stream, which is generous but not unlimited.
Verify by walking the flow yourself. Place a real order through each payment method and watch which domains appear in the address bar. Gateways add subdomains and change URLs, and a list built from a blog post two years ago is probably incomplete.
Three Things the Fix Does Not Do
It is not retroactive. Historical data stays wrong. Your reports before the fix will continue showing gateway referrals, so set a clear date and treat it as a reporting boundary rather than trying to reconcile across it.
It does not solve cross-domain tracking. These are two separate settings and they get confused constantly. Referral exclusion stops a domain being counted as a traffic source. Cross-domain measurement keeps the same session and user identity across domains you control.
If your checkout runs on a different domain from your store, you need both. Configuring one and assuming it covers the other is a common and expensive mistake.
Last non-direct click still applies. If a user arrived via a gateway referral before you added the exclusion, and later returns directly, GA4's attribution model may still credit that earlier referral. Expect some tail in the data.
After the Fix
Three things to expect and verify.
Direct traffic should fall. If gateway leakage was significant, you will see direct / none drop within days as those sessions get correctly attributed.
Paid channel conversions should rise. Not because performance changed because the conversions were always there and were being credited elsewhere.
Your baseline shifts. Campaign-level conversion rates before and after the fix are not comparable. Set a new baseline from the change date.
Then put it on a schedule. Review your traffic acquisition report monthly for domains that look like tools rather than sources. Gateways add subdomains, you add payment methods, and a list that was complete in January may not be in June.
Why This Stays Broken for Years
It produces no error. Every system involved works correctly.
The payment goes through. The order appears in Shopify. The purchase event fires. GA4 records a conversion. Nothing anywhere reports a problem, the conversion is simply filed under the wrong source.
The only way to notice is to look for gateway domains in a report nobody opens, or to reconcile GA4 against your ad platforms and ask why the gap is wider than it should be.
This is the same pattern across most tracking failures we find: the damaging ones do not break loudly. They produce plausible numbers that lead confidently in the wrong direction. Our pre-CRO data audit guide covers the full set of checks.
What It Costs You
Attribution errors are not reporting inconveniences. They move budget.
If a Meta campaign appears to drive 180 purchases when it drove 400, its cost per acquisition looks more than twice as high as it is. That campaign gets defunded. Spend moves to a channel whose attribution happens to be intact often email or branded search, which were going to convert anyway.
So the fix is not about tidier reports. It is about not reallocating budget away from campaigns that were working.
For a brand running meaningful paid spend, this single configuration change frequently has more impact on budget decisions than a quarter of conversion rate optimisation.
Not sure whether your attribution is leaking at payment? Talk to FunnelFreaks, we audit the full chain from campaign click through to order confirmation, and fix what is breaking in between.