Skip to main content

Revenue

Revenue integrations

Connect the payment provider you already use, and see which channel brought each sale.

Your payment provider tells you how much you earned. It cannot tell you which campaign earned it. Connecting one joins the two: a payment arrives, and the dashboard already knows where that visitor came from.

Stripe

Restricted key, eight permissions, pre-ticked by the link we give you.

Paddle

API key with three permissions. Attribution survives a history import.

LemonSqueezy

API key and a store ID. Check the Test/Live switch before creating the key.

Polar

Access token with five scopes. Attribution survives a history import.

One provider per site. A site connects to one, and connecting a second means disconnecting the first — which deletes the revenue collected so far from that site's dashboard. Your provider's own data is never touched.

If you genuinely sell through two providers at once, use two sites.

What stays the same whichever you pick

The dashboard does not change shape when you change provider. The same questions get the same answers, from the same screens.

  • The same goals. subscription_started, trial_converted, subscription_upgraded and the rest are ours, not any provider's — no payment processor sends an event by those names. Each provider's events are translated into them, so your filters and your history keep working.

  • The same money rules. Amounts include tax; fees are recorded but not subtracted; an upgrade's difference counts as renewal revenue rather than a new customer.

  • The same MRR arithmetic. A yearly plan enters as its monthly equivalent, trials count as pending until they convert, and a subscription stops counting the day it actually ends rather than the day a cancellation is scheduled.

What differs, and why

Two goals exist on Stripe and cannot exist anywhere else. The reason is the providers', not a gap in the integration:

GoalStripePaddleLemonSqueezyPolarWhy
trial_will_endOnly Stripe sends anything before a trial ends
payment_action_requiredThe others handle 3-D Secure inside their own checkout and report only the outcome

A declined card still arrives as payment_failed on all four.

One thing works better on Paddle and Polar. Attribution survives a history import: both return your visitor id on the listed object, so a payment imported from a year ago still knows which channel brought it.

Stripe keeps checkout metadata on an event, and those expire after 30 days. LemonSqueezy returns no checkout metadata on a listed order at all. So on those two, imported payments appear in your totals but not in your channel breakdowns, and attribution begins with the first payment after you connect.

Moving from one to another

Disconnect the first, connect the second. The second import brings that provider's history with it, so the dashboard fills in again rather than starting empty.

What does not carry over is the first provider's payments — they are deleted when you disconnect, because leaving them would mean summing two providers' revenue into one figure that matches neither dashboard.

Your traffic is never affected. Pageviews, sessions, channels and your own custom goals stay exactly as they are through any provider change. Only the payments, the subscription state and the subscription goals are removed.

Asking for one that is not here

All four are connectable today. If you sell through something else, tell us — the shape of the integration is the same each time, and knowing which one you need moves it up the list.

Was this page helpful?

Last updated September 9, 2026

Revenue integrations | TrueStat | NookDocs