Track UTMs Through Payment Gateway Redirects

Your best campaign shows no revenue, and your payment gateway shows plenty.

The sales are real. The campaign credit is gone. Somewhere between the checkout button and the thank-you page, the visitor left your site, paid, and came back as someone your analytics no longer recognises. The purchase lands under "direct", or under the gateway's own domain.

This post covers why it happens, how to confirm it, four ways to fix it with honest trade-offs, and how to test the fix. New to the topic? Start with what web attribution is.

Why do purchases lose their campaign at checkout?

Payment-redirect attribution is keeping a visitor's campaign credit intact when a payment gateway or 3D Secure step sends them away from your site and back, often in a new tab.

The credit usually breaks in one of three ways. The exact behaviour depends on your gateway and your setup, so treat these as common patterns rather than rules:

• New tab or window. Some payment, wallet or 3D Secure steps return the visitor in a new tab. Session storage belongs to a single tab, so the new tab can start without the campaign data the first tab held.
• New domain. If the gateway page sits on another domain, anything stored for your domain is out of reach while the visitor is there, and the return trip can look like a fresh visit.
• Referrer overwrite. When the visitor lands back on your thank-you page, the referrer can be the gateway. Analytics that read the referrer then credit the gateway, or treat the visit as direct.

The UTM parameters (utm_source, utm_campaign and the rest) were only ever on the landing URL. Once the visitor navigates away and returns without them, nothing carries the campaign forward unless you stored it somewhere that survives.

This is the same family of problem as the budget misallocation covered in our piece on the hidden cost of inaccurate mobile attribution. On a website it shows up as purchases with no source.

How do you confirm you have the problem?

You can check this with data you already have.

• Look at where purchases are credited. If a large share sits under "direct" or under the gateway's domain as a referrer, that is the signature.
• Compare against the ad networks. Compare the purchases your analytics credits to a paid campaign with the conversions the ad network reports for the same period. A persistent gap that grows when checkout goes through a redirect is a strong hint.
• Split by payment method. If card payments with no extra step look fine but wallet or 3D Secure payments look worse, the redirect is the likely cause.
• Look at the order of events. If the campaign appears on the landing page view and disappears by the purchase event, the data was lost in between.

For a view of which metrics to compare, see metrics that matter for eCommerce. Channel profitability only means something if purchases carry their source.

What are the four ways to fix it?

Most teams need more than one of these. Each has a cost.

1. Store attribution where a new tab can read it

Save the campaign data in local storage, with an expiry, as soon as the visitor lands.

• Good: works across tabs on the same domain, needs no gateway cooperation.
• Trade-off: needs a window (a fixed lifetime) or old campaigns will outlive their usefulness. It also does not help if the return lands on a different domain.

2. Pass attribution through the gateway

Where your gateway allows it, attach the campaign data to the payment as metadata, or add it to the return URL.

• Good: the data travels with the payment itself.
• Trade-off: it depends on what each gateway supports, adds build work per gateway, and puts campaign values in URLs, which needs care.

3. Send the purchase from your backend

Record the purchase on your server, once the payment is confirmed, with the stored attribution attached. This is server-to-server tracking applied to the purchase event.

• Good: does not depend on the visitor returning to your page, and is less exposed to ad blockers and closed tabs.
• Trade-off: you need to store the attribution against the order or user before the redirect, and your team has to build and maintain it.

4. Exclude the gateway as a referrer

Many analytics tools let you exclude referrer domains from counting as a traffic source.

• Good: quick, and stops the gateway taking credit.
• Trade-off: it only stops the wrong credit. It does not restore the right one, so the purchase usually falls back to "direct" unless another fix is in place.

Fix 4 is a clean-up step. Fixes 1 and 3 do the real work, and fix 2 fills the gaps where the gateway supports it.

How does Linkrunner's Web SDK (beta) handle it?

Linkrunner is a mobile and web attribution platform, and its Web SDK (beta) is built with this redirect in mind. The documented behaviour is:

• Last-touch UTMs are kept in sessionStorage and localStorage for 24 hours from the campaign click. Because localStorage is shared across tabs on your domain, a payment gateway or 3D Secure return in a new tab keeps the credit.
• Last-touch click IDs are kept for 90 days.
• First-touch UTMs and click IDs are kept until the visitor's browser storage is cleared, and never change.
• A reload, the back button or an internal link is not a new touch, so returning from the gateway does not overwrite the source on its own. Only a later tagged visit can become the new last touch.

For payments and other sensitive state changes, you can send the event from your backend through the Event Capture and Revenue Tracking APIs rather than relying on the browser. That is fix 3 above, and it is the more reliable route for anything you cannot afford to lose.

Tech Explainer: why 24 hours for UTMs? The 24 hour localStorage copy exists so last-touch UTMs survive a new-tab return from a payment gateway or 3D Secure. Click IDs are kept for 90 days. If a visitor pays more than 24 hours after the click, last-touch UTMs will have expired.

Setup details are in the Web SDK (beta) docs, and the product overview is on the web attribution page (beta). If you also measure an app, the same project covers it, so purchases on the site and installs in the app sit side by side.

How do you test it end to end?

Run this on staging or with a real small-value order before you trust any report.

1. Click a tagged link. Open a campaign link with UTMs in a clean browser profile. Note the exact UTMs.
2. Browse and add to basket. Confirm the landing page view carries the campaign.
3. Pay through the gateway. Use a payment method that triggers the redirect, and if possible one that triggers 3D Secure. Use your gateway's test mode where it has one.
4. Return in whatever way the gateway returns you. If it opens a new tab, stay in that tab.
5. Check the purchase. Confirm it is credited to the campaign from step 1, not to direct or the gateway.
6. Repeat with a wallet and on a mobile browser, since behaviour can differ.
7. Confirm the backend event. If you send purchases from your server, check that the event carries the same campaign.

Agree UTM naming first, or the test will pass and the reports will still be messy. Our guide to UTM naming conventions that scale covers it.

What edge cases should you watch?

3D Secure and wallets

• Some banks and wallets open a separate window or app and return you by a different route. Test each payment method you offer, not just cards.
• Assume behaviour varies by gateway and bank, and check your own flow.

Shopify and Shop Pay

• Shopify stores track through a checkout custom pixel (Web SDK (beta) v0.1.17 or later), with about 30 minutes of setup from the Shopify admin. Shop Pay is supported through a cart attribute.
• Steps are in the Shopify docs. Web attribution is in beta, so check the docs for current behaviour.

Checkouts that run past 24 hours

• Last-touch UTMs expire 24 hours after the campaign click. If a visitor clicks an ad, leaves and pays two days later, the last-touch UTMs are gone and the SDK does not claim to recover them.
• Click IDs last longer (90 days), and first-touch data stays until storage is cleared, so you still have some signal (first vs last touch). That is a different attribution question, closely related to the attribution window you choose.
• Where long consideration is normal, such as high-value orders, store the attribution against the user or order on your side and send the purchase from the backend.

Cleared storage and private browsing

• If the visitor clears storage or uses a mode that blocks it, local storage will not help. Backend attribution is the fallback.

FAQ

Why do my purchases show as direct after the payment gateway? The visitor usually leaves your site, pays, and returns in a new tab or from the gateway's domain. The campaign data held in the first tab is not available there, and the referrer can be the gateway, so the purchase is credited to direct or to the gateway. Storing attribution somewhere a new tab can read it fixes most of this.

How long does Linkrunner keep last-touch UTMs? In Linkrunner's Web SDK (beta), last-touch UTMs are kept for 24 hours from the campaign click. Last-touch click IDs are kept for 90 days, and first-touch data is kept until the visitor's browser storage is cleared.

Does this affect Shop Pay or wallet payments? It can, because wallets and Shop Pay may return the visitor by a different route. On Shopify, Linkrunner's web attribution (beta) tracks through a checkout custom pixel and supports Shop Pay through a cart attribute. For other wallets, test the flow end to end.

Should purchases be tracked in the browser or from the backend? Use both where you can. The browser captures the visit and campaign, and the backend confirms the payment. For payments and sensitive state changes, Linkrunner supports sending events from the backend through the Event Capture and Revenue Tracking APIs, which does not depend on the visitor returning to your page.

How do I test it? Click a tagged link in a clean browser, pay through the gateway with a method that triggers the redirect, return in whatever tab it opens, and check the purchase is credited to the original campaign. Repeat with a wallet and on mobile.

If you measure both your app and your website, Linkrunner handles mobile and web attribution in one place, with the web side in beta. To see how purchases carry their campaign on your own checkout, request a demo.