Server-side tracking for Klarna
The whole Klarna server-side build exists to remove one dependency: the customer coming back from Klarna's approval flow to your confirmation page. A meaningful share do not, and the order is real either way. Fire from your store's order record instead, decide deliberately whether you count at authorization or capture, and tag the payment method so BNPL performance stops hiding inside the store average.
Free30 minutesNo obligation
Klarna server-side · what breaks
What goes wrong on Klarna
- 01
The customer redirects away and does not return
Klarna approves, the order is placed, and the confirmation page never loads. The sale is real and the conversion does not exist.
- 02
Authorization and capture are separate moments
Counting at authorization risks orders that never capture; counting at capture delays the signal.
- 03
Klarna orders under-reported and blamed on the campaign
The channels that skew toward BNPL users look worse than they are.
- 04
Returns higher on BNPL
Pay-later carts return at a higher rate in many stores, and unreversed returns overstate revenue.
Klarna server-side · the fix
What changes — Klarna server-side
Orders sent from the store's own record
Server-side, so the redirect stops mattering.
A deliberate decision on authorization versus capture
Written down, so the number means one thing.
Returns reversed
Which matters more here than on card orders.
Klarna server-side · architecture
What Klarna exposes to a server container
The server-side build for Klarna orders.
- 1
Fire from the store's order webhook
Not from the confirmation page the customer may never see.
- 2
Decide authorization or capture and document it
Then use the same point on both sides of every reconciliation.
- 3
Measure the return-from-Klarna rate
The gap between checkouts started and confirmation pages loaded is the size of the problem.
- 4
Tag the payment method on the conversion
So BNPL performance is visible rather than hidden inside the average.
- 5
Wire returns as reversals
More important here than on card orders.
Klarna server-side · diagnose
Where Klarna tracking breaks, in diagnostic order
Each check rules out a class of cause, so by the last one there is usually a single explanation standing.
- 01
Count Klarna checkouts started against confirmation pages loaded
The gap is the share of BNPL orders your browser-side setup cannot see.
- 02
Check whether the conversion fires from the order or the page
If it is the page, you have found the cause.
- 03
Compare store orders paid with Klarna against reported conversions
Per order, for a closed window.
- 04
Check whether the return rate on BNPL differs
In most stores it does, and unreversed returns then overstate BNPL revenue specifically.
- 05
Confirm no double counting for customers who did return
Both the page tag and the server event may fire.
Klarna server-side · prove
The QA evidence — Klarna server-side
Run on Klarna specifically, on a live conversion rather than in preview mode.
Source of truth
Your store's order records for orders paid with Klarna, cross-checked against Klarna's own settlement reports
- A Klarna order completed with the browser closed at the redirect, confirmed to still report.
- A Klarna order where the customer did return, confirmed to report exactly once.
- A return confirmed to reverse at each destination.
- Store orders paid with Klarna reconciled per order against each platform for a closed window.
- The authorization-versus-capture decision documented before anything was sent.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Klarna server-side · free audit
What we check in the free audit
- Count Klarna checkouts started against confirmation pages loaded
- Check whether the conversion fires from the order or the page
- Compare store orders paid with Klarna against reported conversions
- Check whether the return rate on BNPL differs
- Confirm no double counting for customers who did return
Checked against
Your store's order records for orders paid with Klarna, cross-checked against Klarna's own settlement reports
Free30 minutesNo obligation
Klarna server-side · when not to buy
When you don't need this on Klarna
Worth reading before you buy anything, from us or anyone.
- If Klarna is a very small share of your orders, measure the share before commissioning anything — it may not move a decision.
- If your conversions already fire from the order record rather than the confirmation page, this is largely working.
- The checkouts-started against confirmations-loaded count is free and takes ten minutes. Do it first.
- If your BNPL provider is different, the same shape applies — the redirect is the problem, not the brand.
Klarna server-side · what we deliver
What the server-side build gives you on Klarna
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from your store's Klarna-paid orders
Your store's order list is authoritative for what was sold. Klarna's settlement report is authoritative for what you were paid, which is net of their fee and arrives later. They are different numbers answering different questions.
Deduplicated at every destination
On a shared event ID, verified before any existing path is removed.
Consent enforced before dispatch
A denied destination receives nothing, verified by capture rather than configuration.
Written guarantee
95%+ tracking accuracy
Measured against Your store's order records for orders paid with Klarna, cross-checked against Klarna's own settlement reports. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies the browser-side setup you already have, on a live conversion. Honest about its ceiling on this platform.
- Root cause fixed, not worked around
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Money events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, with monitoring so the next break surfaces in days.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring on every destination
FAQ
Klarna server-side questions, answered
You need the conversion to fire from the order record rather than the page. Most store platforms give you an order webhook that does this directly; a container is worth it when several destinations are involved.
Only if it is deduplicated against the server event, because the customers who do return would otherwise count twice. Simpler is to remove it and let the order webhook own the purchase event.
Read it from the order record and send it as a parameter. It costs nothing and it makes BNPL performance visible instead of hidden inside a store-wide average.
Reverse it. That is the trade for counting at authorization, and the reversal path is the same one you use for refunds.
Free · 30 min
Move Klarna events off the browser
WhatsAppFree30 minutesNo obligation
