A shopper buys a $120 item with a 20 percent contribution margin, so the order should contribute $24 before BNPL ever enters the picture. Route that same order through a Buy Now, Pay Later provider charging a merchant fee near the high end of what the Consumer Financial Protection Bureau's own supervisory data documents, 3.84 percent of order value, and roughly $4.61 of that $24 contribution is gone before shipping or a single return. Nothing on the order page, the GA4 report, or the margin dashboard shows that fee by default. The order looks identical to a card payment that cost less to process.
That gap is not a rounding error. It is the first of two things Buy Now Pay Later quietly changes about an order the moment a shopper taps "Pay in 4," and most Buy Now Pay Later ecommerce tracking setups were never built to catch either one.
- BNPL checkouts route the shopper off-site to the provider and back, the same redirect pattern that breaks attribution for PayPal and other hosted gateways, and most GA4 setups never account for it.
- The Consumer Financial Protection Bureau's own supervisory data puts merchant discount fees in the 2.5 to 3.8 percent range on average, and individual providers charge more, a real cost that rarely appears in a contribution margin model.
- BNPL lending volume grew from 19.8 million loans in 2019 to 335.8 million in 2023, according to a 2026 Federal Reserve Bank of Richmond brief citing CFPB data, so this is not a niche payment option to deal with later.
What actually happens during a BNPL checkout
Klarna, Afterpay, and Affirm are not just another button next to "Pay by card." Stripe's own documentation for each one describes a multi-step handoff: the shopper selects the provider, gets redirected to that provider's own site or app to log in or create an account, picks a payment plan, authorizes it, and is only then returned to the merchant's site to see the order confirmation.
Stripe's Affirm integration guide states this plainly: "On desktop, the customer is redirected to Affirm's site... On mobile, the customer is redirected to the Affirm app if they have it installed, or the Affirm site." Stripe's Afterpay and Clearpay guide describes the identical pattern, with the shopper getting up to three hours to complete authorization before being sent back.
Every one of those steps is a place a browser-based tracking setup can lose the thread. A session cookie expires during the wait. A UTM parameter attached to the original ad click does not survive the round trip through a different domain or app. A shopper who completes the purchase inside the Affirm app and simply closes it never generates the page load most GA4 implementations rely on to fire the purchase event at all.
Where the attribution actually lands
When the purchase event does fire, it usually lands correctly from a revenue standpoint, since most integrations still read the order total from the store platform once the shopper returns. The part that breaks is the channel. If the referring campaign parameters did not survive the redirect, GA4's default channel grouping has nothing to match against, and the sale gets filed under Direct or (not set), the same failure mode that already distorts reporting whenever a hosted payment gateway interrupts a session. A full ecommerce audit or a dedicated tracking setup build that reconciles purchase events against server-side order data, rather than trusting whatever survives the client-side round trip, is the fix most teams eventually need once they notice the Direct channel creeping up after adding a BNPL option.
The margin number nobody is modeling
The attribution problem gets attention because it shows up as a weird channel spike. The margin problem is quieter, because the order total looks completely normal everywhere it is reported.
The CFPB's 2022 market report, built from data the agency collected directly from five of the largest BNPL lenders under its supervisory authority, aggregates merchant discount fees as a share of gross merchandise value across all five providers: 3.39 percent in 2019, 2.91 percent in 2020, and 2.49 percent in 2021. A separate figure in the same report, the effective rate charged specifically to partnered merchants rather than blended across the lenders' other acquisition channels, ran higher: 3.84 percent in 2019, falling to 3.08 percent by 2021.
Those are averages across lenders with declining rates over the period studied. Individual providers today, and products within the same provider, vary, so the exact percentage is less important than the mechanism.
None of it shows up automatically in a dashboard built to read "order total" straight from the store platform. The fee is deducted at settlement, after the order already recorded its full gross value everywhere else.
A store running contribution margin per order as its core profit metric, which is the right instinct, is silently overstating margin on every BNPL order unless the fee is pulled into the model as its own line item, the same way shipping, processing fees, and return rates already are.
Fixing both halves without guessing
The tracking half and the margin half need two different fixes, and neither one is solved by the other.
For attribution, the reconciliation discipline is the same one that catches any platform revenue mismatch: pull the BNPL provider's own settlement or payout report, which lists every order it processed and the fee taken from each one, and compare it against what your store platform and GA4 both report for the identical date range. That is the same comparison a GA4 and Shopify revenue mismatch audit already runs for every other payment method; BNPL just adds one more report to the reconciliation stack.
For margin, the fee needs to become a per-order cost input, not an assumption. Pull a month of BNPL orders from the provider's settlement report, calculate the actual fee percentage your store is paying today, and apply it as a deduction in whatever model currently computes contribution margin. If that number is more than a point or two away from a plain card transaction's processing cost, the gap is big enough to change which products are actually profitable to promote with BNPL turned on.
Deciding what to do with what you find
Once both numbers are visible, the decision is straightforward. If the attribution gap is small and the fee is modeled and acceptable against the conversion lift BNPL brings, leave it running and keep the reconciliation part of the regular reporting cadence.
If the fee is eating a meaningful share of margin on specific low-margin SKUs, the fix is not removing BNPL everywhere. It is restricting it to products where the math still works, the same per-SKU logic already used for any other variable cost. Either way, the decision is only as good as the two numbers it is based on, and right now most stores are making it without either one.
If you are not sure which side of that line your store is on, a reporting build that pulls BNPL settlement data into the same warehouse as everything else turns this from a quarterly guess into a number the margin dashboard shows every morning.
