Paddle (Merchant-of-Record) + TrackLayer: tax-compliant subscription tracking

Paddle is useful in a tracking architecture for the same reason it is useful commercially: it sits at the legally meaningful point of sale. Because Paddle acts as merchant of record, it handles tax calculation, collection, invoicing, and payment processing across jurisdictions that would otherwise turn global SaaS into a compliance project. That means the billing payload already knows whether a customer paid, in what currency they paid, how much of the total was tax, whether a subscription is trialing or active, and whether a later adjustment reversed part of the revenue.

For TrackLayer, that is the difference between inference and truth. Browser tracking can tell you a checkout probably happened. Paddle can tell you whether the commercial event actually settled, what the financially recognized amount was, and whether that value later changed. For global SaaS teams sending conversion signals to Meta, Google, or warehouse models, that makes Paddle one of the best sources for post-checkout attribution because it combines subscription state, tax detail, and international currency context in one durable system of record.

The important design choice is to keep Paddle-specific webhook names at the ingestion edge and preserve canonical TrackLayer names everywhere else. That way billing can evolve without forcing your ad destinations, internal dashboards, and RevOps workflows to relearn the vocabulary every time Paddle changes a lifecycle detail.

The merchant-of-record benefit creates a measurement decision you should make deliberately: when Paddle bills 129 EUR and part of that total is VAT or sales tax, what value should the media platform learn from? In most SaaS cases, the safer optimization signal is net software revenue, not gross tax-inclusive revenue, because tax is not economic value created by the campaign. If you pass tax-inclusive totals into Meta, Google, or another bidder, you may teach the model that jurisdictions with higher indirect tax rates are intrinsically more valuable customers, which is not usually what finance or growth actually means.

The pragmatic pattern is to keep both fields. Let TrackLayer store `gross_value`, `tax_amount`, and `net_value`, then choose one stable primary `value` field per destination. For Meta purchase optimization, many teams send net value and keep gross for reporting only. If your internal revenue model truly evaluates on gross billed amounts, you can pass gross instead, but make that a conscious policy and use it consistently across first purchase, renewal, and refund adjustments.

Paddle supports multi-currency billing, which is useful for conversion rates but dangerous if your downstream systems silently collapse everything into one home-currency number. TrackLayer should preserve the customer-facing transaction currency exactly as billed, along with any normalized finance currency your warehouse uses later. Ad platforms generally expect a value plus currency pair. Give them the real billed currency from Paddle so the signal remains faithful to what the customer actually paid.

The mistake to avoid is mixing currencies at the event layer. Do not send some subscriptions in local currency and others after ad hoc FX conversion unless that rule is universal and documented. Keep event delivery in the original customer currency, perform consolidated FX analysis downstream, and use consistent refund handling in that same currency so optimization and reporting stay internally coherent.