Clarvivo

Free tool by Clarvivo · no login

Find campaign context that leaks before payment

Supply the public page and checkout destination on either side of your handoff. We compare observable URL context without adding items, starting a checkout, or placing an order.

Campaign page

Supply the two public URLs on either side of the payment handoff. We compare URL-level campaign continuity and never add an item, start checkout, or place an order.

This tool answers: Does campaign context disappear before a payment-provider handoff?

Enable JavaScript to run the check — the diagnosis itself is free and needs no account.

Why this happens

When checkout happens on a payment provider's domain, such as Stripe Checkout, PayPal or a hosted payment page, the visitor briefly leaves your site and comes back. If analytics isn't set up for it, the return visit starts a new session with the payment provider as its source, and the purchase is credited to paypal.com or checkout.stripe.com instead of the campaign that brought the buyer.

It's one of the most common reasons paid campaigns look unprofitable while referral traffic from payment domains looks like your best channel. The fix is well known (referral exclusions and preserving campaign context through the handoff), but it's easy to miss when a new payment method is added.

This checker compares the campaign context on your page with what reaches the payment provider's URL, so you can see whether campaign identifiers survive the handoff.

Next checks

These answer the questions this one tends to raise.

How this check works

So you can trust the result — and your developer can verify it.

  1. Paste the URLs on both sides of the handoff

    Your campaign page (with UTMs) and the payment step. We never add items, start a real checkout or pay.

  2. We compare URL-level campaign context

    We check which UTM parameters and click IDs from the starting URL are still present at the payment destination, and list any that were lost.

  3. We're explicit about what can't be seen

    A browser capture can't prove which referrer header or session metadata the payment provider received, so the result separates URL continuity from those limits.

Common causes and fixes

Payment domain not excluded as a referral
In GA4, add payment provider domains to the list of unwanted referrals so returning buyers don't start a new session from paypal.com or stripe.com.
Campaign context not carried through checkout
Pass campaign values into the checkout session (for example as metadata or client reference fields) so purchases can be attributed server-side.
Return URL drops parameters
If the success URL doesn't preserve the session, the return visit looks new. Keep a session identifier on the return URL.
New payment method added without testing
Each provider and wallet behaves differently. Test the full flow when adding one.

Frequently asked questions

Why do my sales show paypal.com or stripe.com as the source?
The buyer returned from the payment domain and analytics started a new session with that domain as the referrer. Add the payment domains to GA4's unwanted referrals.
Does the checker make a payment?
No. It only compares the public URLs you provide.
Can it see what Stripe or PayPal received?
No. It can see URL-level continuity, not the headers or metadata the provider received.
Is server-side attribution better for payments?
It's more reliable, because the order can be linked to the session that started it without depending on the return visit. That's how Clarvivo attributes revenue.
What should I check next?
The Cross-Domain Attribution Checker if your checkout is on another domain you control.

Make the handoff to payment measurable.

Clarvivo joins acquisition with payment truth even when customers move between domains and systems.

Connect campaigns to payment truth

What this tool reads, and what it keeps