Server-side tracking for Paddle
Paddle is the merchant of record, so the transaction record lives in Paddle rather than your database — and the checkout is an overlay that never navigates. Both facts push you to the same place: source the conversion from the transaction.completed webhook, and pass the click identifier in as custom data when you open the checkout, because nothing else carries it across.
Free30 minutesNo obligation
Paddle server-side · what breaks
What goes wrong on Paddle
- 01
Paddle is the merchant of record, not you
The transaction lives in Paddle's system. Your database may have no record of the money at all.
- 02
Overlay checkout with no page navigation
Nothing navigates, so anything expecting a thank-you page load never fires.
- 03
Renewals billing with no browser
The same structural problem every subscription business has, and Paddle gives you good webhooks for it.
- 04
Tax-inclusive pricing confusing every comparison
What the customer paid, what Paddle remitted and what you received are three different numbers.
Paddle server-side · the fix
What changes — Paddle server-side
Transactions sent from Paddle webhooks
Server-side, so the overlay checkout stops being a dependency.
A stated definition of value
Gross, net of tax, or your payout. Chosen once and used on both sides of every comparison.
Renewals reported and acquisition optimized
Kept apart deliberately.
Paddle server-side · architecture
What Paddle exposes to a server container
The server-side build on Paddle specifically.
- 1
Source from transaction.completed
Not from the overlay's JavaScript callback, which the customer can interrupt.
- 2
Pass the identifier as custom data at checkout open
It is the only reliable way to get it into Paddle's record.
- 3
Pin the value definition first
Paddle's tax-inclusive model means gross, net and payout genuinely differ. Decide which you report.
- 4
Separate first transaction from recurring
The webhook payload distinguishes them.
- 5
Wire refunds and chargebacks
Paddle exposes both and both are real reductions in revenue.
Paddle server-side · diagnose
Where Paddle 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
Open a Paddle transaction and check its custom data
If the identifier is not there, the join is broken at the source and nothing downstream fixes it.
- 02
Compare Paddle transactions against reported conversions
Per transaction, for a closed window.
- 03
Check whether the overlay callback is the only trigger
If so, every interrupted checkout that still completed is missing.
- 04
Confirm currency is sent per transaction
Paddle is global by design; an account default will be wrong constantly.
- 05
Check whether refunds reverse anything
Usually not, and Paddle exposes them clearly.
Paddle server-side · prove
The QA evidence — Paddle server-side
Run on Paddle specifically, on a live conversion rather than in preview mode.
Source of truth
Paddle's transaction records — completed transactions by date, net of refunds and chargebacks
- A test purchase completed with the identifier confirmed present in the Paddle transaction's custom data.
- A purchase where the overlay was closed immediately after payment, confirmed to still report.
- A refund confirmed to reverse at each destination.
- Paddle transactions reconciled per transaction against each platform for a closed window, at the agreed value definition.
- Currency confirmed correct on a transaction in a non-default currency.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Paddle server-side · free audit
What we check in the free audit
- Open a Paddle transaction and check its custom data
- Compare Paddle transactions against reported conversions
- Check whether the overlay callback is the only trigger
- Confirm currency is sent per transaction
- Check whether refunds reverse anything
Checked against
Paddle's transaction records — completed transactions by date, net of refunds and chargebacks
Free30 minutesNo obligation
Paddle server-side · when not to buy
When you don't need this on Paddle
Worth reading before you buy anything, from us or anyone.
- If you sell a single one-off product in one currency with no subscriptions, Paddle's own reporting may be all you need.
- If Paddle's numbers and your ad platform numbers already reconcile within a few percent, this is working.
- Decide gross versus net yourself first — a surprising share of these discrepancies end there with no code change.
- If you are not running paid media, fix the reporting definition and skip the ad-platform work.
Paddle server-side · what we deliver
What the server-side build gives you on Paddle
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from Paddle's transaction records
Paddle's transaction list is authoritative for what customers paid. Your payout report is authoritative for what you received, and the two differ by tax and Paddle's fee. Say which one a number refers to every time.
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 Paddle's transaction records — completed transactions by date, net of refunds and chargebacks. 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
Paddle server-side questions, answered
For interface behaviour, yes. For the conversion event, no. The callback runs in a browser the customer controls; the webhook fires because a transaction completed. Only one of those is a fact about your business.
You need a server-side handler for the webhooks. A container is worth it when several destinations are involved; otherwise a direct handler is simpler and just as reliable.
Send the transaction's own amount and currency, every time. Paddle prices differently by market by design, so a catalog price is wrong for most customers and an account-default currency is wrong for most transactions.
Paddle exposes them and they are real revenue reversals. Wire them the same way as refunds — most setups handle neither, and the reported figure then only ever rises.
Free · 30 min
Move Paddle events off the browser
WhatsAppFree30 minutesNo obligation
