GA4 records every purchase your WooCommerce store makes. It captures the transaction ID, the revenue, the items, the quantities. What it doesn’t capture—what it structurally cannot capture without custom configuration—is which payment method the customer used. PayPal processes roughly 30% of all WooCommerce transactions. GA4 has no idea whether those orders convert at a different rate, carry a different average order value, or generate more returns than Stripe orders. It never will, unless you explicitly send that data.

This isn’t a misconfiguration or a missed setting. It’s a gap in GA4’s ecommerce schema. The standard purchase event specification—transaction_id, value, currency, items array—contains no payment_method parameter. Not as a required field. Not as an optional one. It simply doesn’t exist in the spec. Every store optimising checkout based on GA4 data is working without one of the highest-leverage variables in their conversion funnel.

What You Can’t See Is Costing You Real Money#

Consider what a complete checkout analytics picture requires: conversion rate by payment gateway, average order value by payment method, return rate by payment type, and the downstream quality of conversions feeding your Google Ads Smart Bidding. Without payment method as a dimension, none of these questions have answers in GA4.

BNPL checkout integration can boost overall conversion rate by up to 30% and AOV by 45–85%. That’s well-documented across Klarna, Afterpay, and Affirm merchant data. But stores adding BNPL see aggregate uplift and cannot determine in GA4 whether Klarna outperforms Afterpay, whether one BNPL option converts better for orders above $150, or whether a particular gateway placement on the checkout page is driving the change.

The problem compounds with Smart Bidding. If 34–41% of BNPL users miss at least one payment—and BNPL orders are associated with higher return and chargeback rates than card transactions—then purchase events from BNPL customers are lower-quality conversion signals. Google Ads has no way to weight them differently because GA4 is sending identical purchase events with no payment method data attached. Your Smart Bidding campaigns are training on mixed-quality conversions with no signal to distinguish them.

You may be interested in: PayPal and Klarna Are Silently Breaking Your WooCommerce Tracking

WooCommerce Already Has the Data. GA4 Never Asks for It.#

Here’s the clarifying fact: WooCommerce records the payment method on every order. The order object exposes it directly via $order->get_payment_method()—available server-side at the moment of order confirmation, before any browser interaction. The data exists. GA4 simply never collects it.

The fix is a custom parameter on the purchase event. When GA4 receives payment_method: "klarna" or payment_method: "stripe" alongside the standard purchase fields, you can build a custom dimension in GA4 and then segment every ecommerce report by gateway. Conversion rate by payment method. Revenue per transaction by gateway. Return behaviour by payment type. All of it becomes available—but only if the parameter is sent, and only if it’s sent from the server side.

The client-side path is unreliable. JavaScript fires after the thank-you page loads, and payment redirect gateways—PayPal Standard, Klarna, Afterpay—frequently lose the browser session in the redirect back from the payment provider’s domain. A client-side event that fires on redirect return misses a meaningful share of transactions. A server-side event that fires from the WooCommerce woocommerce_payment_complete hook fires on every order, regardless of what happened in the browser.

What Payment Method Segmentation Actually Unlocks#

Once payment method is a dimension in your analytics, the questions that become answerable change the nature of checkout optimisation entirely.

Checkout order testing gets directional. If you move Klarna above Stripe in your gateway display order and conversion rate increases, GA4 can now tell you whether the lift came from Klarna specifically or from an overall checkout experience change. Without the dimension, you’re guessing which variable moved.

AOV analysis gets specific. Fashion retailers adding Klarna report an average AOV jump from $87 to $106—a 22% increase. But the store-level question is whether Klarna customers are spending more because BNPL enables higher spend, or because the customers choosing Klarna already intended to spend more. Payment method conversion data in BigQuery lets you run cohort analysis: same product category, different payment method, what’s the AOV difference?

Smart Bidding signal quality improves. With payment method as a custom parameter on purchase events, you can exclude or downweight BNPL conversions in your Google Ads conversion action—or create a separate conversion action for card transactions specifically. The global BNPL market is projected to reach $560.1 billion in 2025, a 13.7% year-over-year increase. As BNPL adoption grows, its effect on conversion signal quality is not a future concern. It’s a current one.

You may be interested in: BNPL Is Destroying Your WooCommerce Conversion Tracking

The Server-Side Solution and What It Enables Downstream#

A server-side event pipeline reading $order->get_payment_method() at order completion solves this cleanly. The payment method string—”stripe”, “paypal”, “klarna”, “afterpay”—is passed as a custom parameter on the purchase event and flows to every connected destination simultaneously.

In GA4, it becomes a custom dimension you register in the admin interface. In Google Ads Enhanced Conversions, it becomes a segmentation variable that lets you filter or weight conversion actions. In Facebook CAPI, it enriches purchase events with a field that Meta can use for audience modelling. In BigQuery, it becomes a column on every purchase row—enabling the payment method cohort analysis, return rate correlation, and Smart Bidding quality scoring that no standalone analytics platform can produce on its own.

67% of data professionals report they cannot trust their analytics data for business decisions. For WooCommerce stores, payment method is one of the clearest examples of data that exists in the system but never reaches the analytics layer. The WooCommerce order object has it. The question is whether your event pipeline is reading it.

The Transmute Engine™ reads $order->get_payment_method() server-side on every order and sends it as a custom parameter across GA4, Google Ads Enhanced Conversions, Facebook CAPI, and BigQuery in a single pipeline call. The result is payment method segmentation across every analytics and advertising platform your store uses—from one server-side hook, not four separate integrations.

Auditing Your Current Setup#

To check whether your store is currently sending payment method data, open GA4 DebugView, process a test order through each of your active gateways, and look at the purchase event parameters. If you see only the standard fields—transaction_id, value, currency, items—payment method is not being sent. If your custom dimension report in GA4 shows payment method data but at a lower transaction volume than your WooCommerce order count, you have partial capture—likely browser-side events that are missing redirect transactions.

The gap between what WooCommerce knows and what GA4 sees is not inevitable. It’s an architecture choice—and it’s one that determines whether checkout optimisation is informed by evidence or guided by aggregate numbers that hide the variable that matters most.