TL;DR
A shopper who leaves your store to pay and comes back can hand the purchase to the payment host in GA4, but only some Magento payment flows leave the domain, and the symptom depends on whether the session timed out. Read the two reports, map your flows, list the hosts you saw, and wait out the lookback window before judging. The PRO server-side purchase follows the session the browser holds on the success page, so it moves with the fix.
Key Takeaways
- A new traffic source in the middle of a session doesn't start a new session [2], so a quick PayPal return can only show up in event-scoped attribution (Model comparison, key event paths) and leaves Traffic acquisition alone [3].
- A return after 30 minutes of inactivity, the default session timeout [4], starts a new session that a payment host can own in Traffic acquisition.
- In Magento Open Source 2.4.9, Skip Order Review Step ships as Yes but only applies to buyers who picked PayPal at the checkout payment step [9]; check your own setting under the PayPal Express configuration.
- Braintree's 3-D Secure guide launches the challenge as "the iframe challenge" [8], so card-network and bank hosts don't belong on the list unless your reports show them.
- Listing a host adds
ignore_referrer=trueto matching events as they're collected [1], so sessions already processed keep their label. - The PRO purchase normally fires from the success page after a short delay that gives the page view time to fire (v1.12.1, v1.15.3) [6].
Read two reports before you change any setting
Where a payment return shows up depends on how long the shopper was away, and Google's session rule decides it: "Each session is associated with only one campaign or traffic source and a new session is not started when Google Analytics encounters a new campaign or traffic source" [2]. A traffic source that arrives in the middle of a session is kept with the events it came in with and used for event-based attribution, but it doesn't touch the session [2].
So a shopper who clicks a Google ad, pays at PayPal and comes back within a few minutes keeps the ad as the session source. If the return page carries PayPal as its referrer, the purchase that follows can still be credited to PayPal in the event-scoped reports, which Google surfaces "in the Model comparison and Key event paths reports" and attributes data-driven by default [3].
A shopper who takes longer is a different case. Sessions end "after 30 minutes of user inactivity" by default [4], and a slow bank step, a forgotten PayPal password or a checkout left open over lunch can cross that line. The return then starts a new session, and with no campaign values on the return page, the referrer "may set dimensions when no other campaign or traffic source fields have been set" [2]. That's the version that shows in Traffic acquisition.
Two reads, then:
- Traffic acquisition, with Session source / medium as the dimension. A payment host in that table means returns that started a new session.
- Model comparison, under Advertising, with Source / medium for the purchase key event. A payment host there with no matching row in the first report means mid-session returns taking the credit.
Hosts that show up in either read go on the list. Hosts that show up in neither don't, however familiar the name. You've probably had a campaign report and the acquisition report disagree about the same week's orders; this is one of the reasons they can.
If the purchase is missing altogether rather than mis-credited, a payment redirect may have moved your success page, which our guide to tracking custom and one-page checkouts covers. If it arrives with no channel at all, start with our guide to purchases landing as Unassigned.
Which Magento payment flows actually leave your domain?
Adobe describes the classic PayPal Express workflow as a redirect to PayPal, after which "The customer is redirected back to the checkout page in your store to review the order" [5]. In Magento Open Source 2.4.9, the shopper comes back through Magento's PayPal return address, and Magento then shows the Order Review page, or places the order and opens the success page [9].
| Flow (In-Context off unless the row says otherwise) | Leaves your domain? | First store page after payment |
|---|---|---|
| PayPal chosen at the checkout payment step, Skip Order Review Step = Yes | Yes | The success page, order already placed |
| PayPal chosen at the checkout payment step, Skip Order Review Step = No | Yes | The Order Review page |
| PayPal button on the product page, mini cart or cart | Yes | The Order Review page, whatever Skip Order Review Step says [9] |
| In-Context Checkout Experience switched on | PayPal opens over the store; test it | Review or success page, opened from your own page [9] |
| Braintree card payment with a 3-D Secure challenge | No: "the iframe challenge" [8] | The same checkout page |
| Braintree local payment methods | Yes, back through "the fallback Braintree page" [7] | Your store |
| Third-party module with a hosted payment page or bank redirect | Yes, by design | Whatever page the module returns to |
The shortcut-button row comes from Magento's own code. Adobe's page tells you that "To allow the customer to complete the transaction from the PayPal site without returning to your store for Order Review, set Skip Order Review Step to Yes" [5], and the configuration reference scopes the setting to the website [10]. Neither page says the setting only covers part of your PayPal buyers. In Magento Open Source 2.4.9 the setting ships as Yes, and it only applies when PayPal was started from the checkout page; a buyer who started from a PayPal button on a product page, the mini cart or the cart comes back to the Order Review page every time [9]. Adobe lists those entry points too: PayPal Express "allows the customer to check out at the beginning of the usual checkout workflow from the product page, the mini cart, and the shopping cart" [5]. Those buyers also skip the checkout steps, so a closed funnel like the one in our guide to building a GA4 checkout funnel won't include them.
Skipping the review step doesn't hide the return, either. With the review skipped, the first store page after PayPal is the success page, so whatever referrer the return carries would land there instead. Check it rather than trusting it: open the success page's page_view in DebugView after a sandbox PayPal order and read page_referrer.
For the In-Context row, Adobe's line is that "Customers never lose sight of your store" [5], and Magento moves the shopper on by script from your own page once PayPal approves [9]. Whether PayPal ever appears as a source on that setup is something your two reports answer, so check them before you add a host you may not need.
Add only the hosts you saw to the GA4 referral exclusion list
Google names this exact case. Its unwanted referrals page lists "Third-party payment processors: An ecommerce site that uses a third-party payment processor, and users return to your site after checking out on the third-party domain" [1], and its traffic-source page says you'll "still want to configure referral exclusion for any third-party services or gateways that you employ on your website(s)" [2].
The path is Admin > Data collection and modification > Data streams, then your web stream > Configure tag settings > Settings > Show all > List unwanted referrals [1]. Add one condition per host you found in the two reports. You need the Editor role, and the list holds a maximum of 50 unwanted referrals per data stream [1].
Don't paste in every bank, card network and wallet you've heard of. A host that never appears in your reports gains nothing from being listed. Keep your own store domains out of this pass too; they're a separate question with separate rules.
What does the PRO server-side purchase do here?
It follows the session and it carries no referrer of its own, so it neither causes the payment host label nor removes it. v1.12.1 (May 30, 2023): "Adjusted the triggering of the Server-Side Purchase event to ensure it happens on the Success Page and not beforehand for increased compatibility with 3rd-party payment solutions" [6]. v1.15.3 (June 20, 2025): Measurement Protocol purchase events "now feature a small delay to ensure the Success Page has had time to load completely before the event is fired", so "the client-side Page View event has had time to trigger" [6]. An order the success page didn't send goes out later by cron with the values stored on the order: since v1.15.7 (September 2, 2025) the module "stores the payload from the frontend Purchase event in the DB and uses it when pushing the Purchase via the included cron functionality", and v1.17.5 fixed "the stored GA session id being sent as 0 on refund and purchase events, including purchases pushed later by cron" [6].
Normally, the result is a purchase that joins the GA session the shopper's browser holds when checkout completes and the success page loads. If the return from PayPal started a new session credited to PayPal, the server-side purchase is credited there too. Once the host is listed, it follows the corrected session. The server-side purchase is a PRO feature (see our Standard vs PRO comparison).
Since v1.17.4 (September 1, 2026), with Require Visitor Consent for Server-Side Events switched on, that purchase is sent only when the shopper's Consent Mode v2 choice allows it, judged on the consent stored with the order [6]; our guide to server-side events and consent covers the option.
When can you trust the numbers again?
Not the next morning. Listing a host makes GA4 append "the ignore_referrer parameter with a value of true to every event that matches the conditions" [1], and a session whose referrer is ignored "is processed as direct traffic" [2]. For a shopper who timed out at PayPal, that's the outcome you want, because "A direct-traffic visit that follows a referred visit will never override an existing referrer" [2]: the new session is credited to the source the shopper arrived with.
None of that rewrites history. Google's unwanted referrals page has a section on "Why returning users from excluded domains still appear in your reports", and its answer is the attribution model: "Because of the last-non-direct-click attribution model, this second session is also attributed to Domain B" [1], where Domain B is the excluded host in Google's example. A shopper whose earlier visit was credited to PayPal can keep producing PayPal sessions for a while after you list it.
So date the change, then re-read both reports once your key event lookback window has passed since that date [1]. Compare the share of purchases credited to each payment host in Traffic acquisition and in Model comparison, against the same span before the change. If a host is still there after the window, check that the condition matches the exact host in your reports, and check that you edited the stream your store sends to.
FAQ
Does the WeltPixel GA4 extension exclude payment referrers for me?
The unwanted referrals list is a GA4 data stream setting, so you configure it in GA4 [1]. The extension's job is to send the purchase, normally from the success page, where it joins whatever session the browser holds [6].
Will setting Skip Order Review Step to Yes fix PayPal attribution?
No. It moves the first store page after PayPal from the review page to the success page, and in Magento Open Source 2.4.9 it doesn't apply to shortcut-button buyers at all [9]. The listing in GA4 is the fix.
Will listing paypal.com clean up last month's reports?
Past sessions keep their label, because the parameter is added to events as they're collected, and returning users from a listed host can still appear under it because of the last non-direct click model [1].
Send the purchase from the success page with the Magento 2 Google Analytics 4 extension, list the payment hosts your reports show in GA4, and re-read both attribution reports after the lookback window. The current release is v1.17.5, September 16, 2026 [6].
Sources
- [GA4] Identify unwanted referrals, Google Analytics Help, retrieved October 14, 2026, https://support.google.com/analytics/answer/10327750
- Campaigns and traffic sources, Google Analytics Help, retrieved October 14, 2026, https://support.google.com/analytics/answer/11242841
- Scopes of traffic-source dimensions, Google Analytics Help, retrieved October 14, 2026, https://support.google.com/analytics/answer/11080067
- About Analytics sessions, Google Analytics Help, retrieved October 14, 2026, https://support.google.com/analytics/answer/9191807
- PayPal Express Checkout, Adobe Commerce Admin User Guide, Adobe Experience League, last updated October 8, 2026, retrieved October 14, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/paypal/paypal-express-checkout
- WeltPixel Google Analytics 4 User Guide and Change Log (v1.12.1, v1.15.3, v1.15.7, v1.17.4 and v1.17.5 entries), retrieved October 14, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- Braintree, Adobe Commerce Admin User Guide, Adobe Experience League, last updated October 8, 2026, retrieved October 14, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/braintree
- 3D Secure: Step by Step Integration (JavaScript v3), Braintree developer documentation, retrieved October 14, 2026, https://developer.paypal.com/braintree/docs/guides/3d-secure/step-by-step-integration/javascript/v3/
- Magento Open Source 2.4.9 source, PayPal module, GitHub magento/magento2, retrieved October 14, 2026, https://github.com/magento/magento2/tree/2.4.9/app/code/Magento/Paypal
- Sales > Payment Methods > PayPal Express Checkout, Adobe Commerce Configuration Reference, Adobe Experience League, last updated October 8, 2026, retrieved October 14, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/config/sales/payment-methods/paypal-express-checkout