Server-side tracking for Chargebee
The Chargebee server-side build turns on one distinction most integrations get wrong: fire on payment_succeeded, not invoice_generated. An invoice generated is a bill you sent; a payment succeeded is money you received, and in any business with dunning the gap between them is large. Beyond that, the identifier has to live on the customer or subscription so it survives a trial longer than any browser cookie.
Free30 minutesNo obligation
Chargebee server-side · what breaks
What goes wrong on Chargebee
- 01
Trial-to-paid conversions happening with no browser present
The moment a business actually starts earning is invisible to anything that fires from a page.
- 02
Dunning retries counted as revenue
A failed payment retried four times can produce four invoice events for one billing period.
- 03
Signups optimized instead of paid conversions
Free-trial signups attract people who like free trials, and no budget fixes that.
- 04
Upgrades and downgrades never reflected
The recurring amount changes and reported value does not.
Chargebee server-side · the fix
What changes — Chargebee server-side
Trial-to-paid as the acquisition conversion
Sent from the first successful payment, not from the signup.
Value based on expected lifetime
Monthly recurring revenue times your own average tenure, documented.
Failed payments and dunning excluded
An invoice created is not an invoice paid.
Chargebee server-side · architecture
What Chargebee exposes to a server container
The server-side build on Chargebee specifically.
- 1
Fire on payment_succeeded, not invoice_generated
An invoice generated is a bill, not money. This single distinction fixes most Chargebee revenue discrepancies.
- 2
Store the identifier on the customer or subscription
It has to survive a trial period longer than any browser cookie.
- 3
Distinguish first payment from recurring
They are different events with different destinations and the webhook tells you which is which.
- 4
Handle dunning explicitly
Retries must not each count. Key on the billing period, not the attempt.
- 5
Wire cancellation and downgrade
Both change what the customer is worth and both are usually ignored.
Chargebee server-side · diagnose
Where Chargebee 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
Compare Chargebee revenue to reported revenue for a closed month
The gap is the renewal and trial blind spot.
- 02
Check whether the identifier is on the customer or only on the signup
If it did not survive the trial, trial-to-paid cannot be attributed.
- 03
Check whether the event fires on invoice or on payment
Invoice-based firing counts money you have not received.
- 04
Look for dunning retries counted more than once
Four attempts for one period is common and it inflates everything downstream.
- 05
Measure trial length against every import window
Before assuming an offline upload is even possible.
Chargebee server-side · prove
The QA evidence — Chargebee server-side
Run on Chargebee specifically, on a live conversion rather than in preview mode.
Source of truth
Chargebee's subscription and invoice records — paid invoices by payment date, net of refunds and failed payments
- A test subscription taken through trial to first payment, with exactly one conversion firing at the payment.
- A dunning sequence confirmed to produce one conversion, not one per retry.
- A cancellation confirmed to reverse at each destination that accepts one.
- Chargebee paid invoices reconciled against reported revenue for a fully closed month.
- The lifetime value model shown as a calculation from your own churn data.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Chargebee server-side · free audit
What we check in the free audit
- Compare Chargebee revenue to reported revenue for a closed month
- Check whether the identifier is on the customer or only on the signup
- Check whether the event fires on invoice or on payment
- Look for dunning retries counted more than once
- Measure trial length against every import window
Checked against
Chargebee's subscription and invoice records — paid invoices by payment date, net of refunds and failed payments
Free30 minutesNo obligation
Chargebee server-side · when not to buy
When you don't need this on Chargebee
Worth reading before you buy anything, from us or anyone.
- If your trial is longer than 90 days, offline upload of the first payment cannot work against the original click. We will tell you that before quoting.
- If Chargebee revenue and reported revenue already agree within a few percent, this is working.
- If you have no paid acquisition, the reporting fix matters and the ad-platform work does not.
- If your churn history is too short to model lifetime value, use a conservative figure and say it is conservative.
Chargebee server-side · what we deliver
What the server-side build gives you on Chargebee
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from Chargebee's paid invoices
Chargebee's paid invoices are the authoritative revenue record. Note the distinction between invoice date and payment date — they differ, and comparing one against the other produces a gap that looks like a tracking bug.
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 Chargebee's subscription and invoice records — paid invoices by payment date, net of refunds and failed payments. 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
Chargebee server-side questions, answered
You need a server-side event source, which Chargebee's webhooks already are. A container earns its place when several destinations are fed from one point; for one destination a webhook handler is simpler.
On the Chargebee customer or subscription as a custom field, set when the subscription is created. Storing it only against the signup form means it does not survive the trial, which is exactly the period it needs to survive.
Not on its own — it is a different origin. It has to be passed into the hosted page's parameters or set on the subscription server-side when you create it. The second is more reliable.
The recurring amount varies per period, so the lifetime value model has to use an average from your own data rather than a plan price. Say in the report that it is an average.
Free · 30 min
Move Chargebee events off the browser
WhatsAppFree30 minutesNo obligation
