Six redirects off your site that can lose the order source

Tabby and Tamara are the usual suspects because they're the most used. The problem isn't them though, it's the redirect itself: any hop that takes a shopper off your domain and back can end the session that was carrying their source.

Six redirects that can break a session

1. Instalment providers. The single biggest cause in the Saudi market, purely on volume.
2. 3-D Secure card verification. The bank's verification page is a different origin. A shopper who spends a minute hunting for the SMS code can come back on a fresh session.
3. Wallets and bank transfer. Anything that hands the shopper to a banking app and returns them through a deep link.
4. Hosted payment pages. If your provider hosts checkout on its own domain instead of embedding it, every order takes a hop.
5. In-app browsers handing off to the system browser. A shopper who opens your link inside Instagram, then taps "Open in Safari", starts a new session at that moment, and the click ID stays behind in the in-app browser.
6. Login and identity providers. Single sign-on, or a verification step hosted somewhere else.

The first four touch the order directly. The fifth is the one most stores have never thought about, and it hits paid social traffic hardest, which is exactly the traffic you review every week.

Card payments go through the same mechanism via 3-D Secure, just less often, because the hop is shorter and the return is faster. The cause is the redirect rather than the store platform, so what happens on Salla happens on Zid.

What breaks is the chain that holds the source

Payment itself works fine. Something else breaks.

The shopper arrived with a click ID in the URL and a first-party cookie holding the session. The hop and the return can look like a new visit: the referrer is now the gateway, the cookie may not be readable in the return context, and the click ID isn't in the new URL.

So the order gets written with the gateway as its source, or with no source at all. It lands in "direct", or in a row named after the payment provider, and the channel that paid to bring that customer in gets nothing.

Why the damage lands on certain channels

Instalment use isn't evenly spread. It skews toward larger baskets and younger buyers, which is the same group your paid social campaigns target.

The result is systematic rather than noise: the channels most affected are the ones most often accused of not working. In a lot of accounts, correcting it moves the reported return for those channels by a wide margin rather than a point or two.

The expensive part is the decision built on the incomplete picture. You cut a working channel and shift its budget to one whose reported return looks better only because its customers pay by card. A month later total orders are down and nobody can explain why.

How to tell whether it's happening to you

Put two numbers side by side over the last six months: the share of orders sitting in "direct", and the share paid by instalment. If both grew together and nothing else changed in that period, that's your cause.

There's a faster check too. Open ten orders paid by instalment and look at the source field. If they all say "direct" or carry the gateway's name, you have your answer.

The fix is a configuration change, not new budget

Treat gateways as a pass-through step inside the journey. The source is written onto the order server-side at checkout, from the resolved identity before the hop, rather than rebuilt afterwards from whatever referrer the browser presents on return.

None of that needs extra spend. You aren't buying more traffic, you're correctly labelling traffic you already paid for.

What doesn't help here is adding UTMs. A UTM lives in the URL, and the URL is exactly what the redirect throws away.

The fifth case, the in-app browser, isn't fully solved the same way, because the new session starts before the shopper reaches checkout. What reduces it is keeping the purchase journey inside the in-app browser rather than pushing people to open it elsewhere, and storing the click ID on arrival rather than only at checkout.

In Flowfy, gateway pass-through is live and the source is written server-side at checkout, so a redirect through an instalment provider or a 3-D Secure step doesn't erase it. Past orders aren't changed, because their source was never captured.

The check to run this week

Run the check this week: the "direct" share against the instalment share over the last six months. If they moved together, move source writing to the server at checkout before you reallocate any budget.