A payment provider appearing as the source of WooCommerce sales is an attribution problem, not necessarily a missing-purchase problem. Verify the checkout return path, then configure unwanted referrals for the actual provider domain when appropriate. This does not repair duplicate purchases or recover missing campaign information automatically.
Follow one complete buyer journey
Use an approved test purchase with a known non-sensitive campaign marker. Record the landing page, checkout, provider-hosted step and return page. Note where the Google tag is present and what consent applies. Keep order keys, customer details and payment credentials out of screenshots and shared network exports.
Compare the storefront order with the analytics purchase identifier. Use a non-secret transaction identifier, not the WooCommerce order key. Record the source dimension you are investigating: session source, first-user source and event-attributed key-event reports answer different questions.
If GA4 counts two purchases for one order, first use the purchase deduplication guide. Excluding a referral cannot merge duplicate events.
Configure the verified provider domain
Google's unwanted-referral guidance identifies third-party payment processors as a common use case. In the relevant web data stream, open Configure tag settings, then List unwanted referrals, using Show all if needed. Add a narrowly appropriate domain rule and record the change time.
Use the domain observed in the buyer journey, not a copied list of every payment brand. Review the match type. A broad substring rule can suppress legitimate partners with similar names. Do not add your own separately owned storefront to this list as a substitute for correctly configured cross-domain measurement.
Scope: Verified provider domain. Identity: Non-secret transaction ID. Cohort: New tests versus old history. Count: No duplicate purchases. Explanatory checklist, not a customer test result.
Test collection and reports separately
Prepare a small worksheet with the test order ID, UTC start time, original campaign, payment route, return URL, consent state and purchase count. Repeat the journey in a fresh test session after the change. The objective is a valid purchase without the provider being introduced as a new acquisition source in the tested path.
Then check processed reporting using a consistent source dimension and date range. Historical attribution and returning-user history can still explain old provider referrals. Google specifically documents why a previously attributed referral may remain visible after exclusion; do not keep broadening the rule just to erase history.
| Result |
Meaning |
| Purchase missing entirely |
Investigate collection and checkout return |
| Purchase duplicated |
Investigate event producers and identifiers |
| Provider referral on new tests |
Review domain match and live tag configuration |
| Only older cohorts retain provider credit |
Separate historical attribution from new behavior |
Keep the change measurable
Annotate the reporting cutoff in your local marketing log and compare new cohorts rather than declaring success from a single Realtime view. Do not retroactively label all direct traffic as recovered advertising revenue. Lost source data remains lost unless another authorized system actually retained it.
For journeys between domains you operate, inspect the cross-domain linker path. HandL WP can trace the checkout attribution handoff using the redacted journey and transaction evidence, while keeping purchase-count verification separate.
References reviewed October 10, 2026. Examples are explanatory, not customer test results.