How to Track Buy Now Pay Later (BNPL) Checkout Flows

The BNPL Tracking Problem

Buy Now Pay Later providers (Klarna, Afterpay/Clearpay, Laybuy, Zip) redirect users to the BNPL provider's website or app to complete the payment approval. The user leaves your checkout, the BNPL provider approves the financing, and the user is redirected back to your order confirmation page.

This redirect breaks standard GA4 checkout tracking in two ways: the GA4 session ends when the user leaves your domain, and the returning user starts a new session on the confirmation page with the referrer being the BNPL provider (appearing as referral traffic rather than the original marketing channel).

Challenge 1: Session Continuity

When a user is sent to Klarna and returns to your confirmation page, GA4 typically attributes the purchase to "klarna.com" as the referring source — even if the original acquisition was a Google Ads click.

Solution: add Klarna, afterpay.com, clearpay.co.uk, and other BNPL domains to your GA4 Referral Exclusions (Admin then Data Streams then your web stream then More Tagging Settings then List Unwanted Referrals). This tells GA4 to ignore these referring domains and maintain the original session attribution.

Challenge 2: Purchase Event Reliability

The order confirmation page purchase event should fire reliably on return from BNPL. Potential issues:

• BNPL redirect may strip URL parameters that your confirmation page uses to populate transaction data
• Server-side session handling may not correctly associate the returning user with their cart data
• Transaction data may not be available in the page on initial load (loaded asynchronously)

Solutions:

• Do not rely on URL parameters for transaction data — read from server-side session or database lookup using an order token in the URL
• If transaction data loads asynchronously, wait for the data before firing the purchase event (fire in the callback/promise resolution, not on page load)
• Consider Measurement Protocol as a backup: fire the purchase event from your server when the BNPL webhook confirms payment, not from the browser

The Webhook + Measurement Protocol Approach

The most reliable BNPL tracking approach is server-side:

1. When the BNPL provider confirms payment (via webhook to your backend), your backend fires a GA4 Measurement Protocol purchase event
2. This fires regardless of whether the user successfully returned to your confirmation page
3. Use the stored GA4 client_id (captured at checkout initiation) for user attribution

This approach captures ALL BNPL conversions even if the user closes the browser before returning to your confirmation page.

add_payment_info for BNPL

Track BNPL as a payment type in your add_payment_info event:

dataLayer.push({
  event: "add_payment_info",
  ecommerce: {
    currency: "GBP",
    value: 89.00,
    payment_type: "Klarna",  // or "Afterpay", "Clearpay"
    items: [...]
  }
});

This enables analysis of which payment methods are selected and which complete to purchase — valuable data for deciding which BNPL providers to prioritise.

Summary

BNPL tracking requires two fixes: add BNPL provider domains to Referral Exclusions to preserve channel attribution, and use server-side Measurement Protocol to fire purchase events from the BNPL payment webhook rather than relying solely on the browser-side confirmation page. This combination captures all BNPL conversions with correct attribution.

See our Enhanced Ecommerce Tracking service for BNPL tracking implementation.

Need BNPL checkout tracking set up? Contact Adslytics.