Connecting your payments
Stripe, Polar, Lemon Squeezy, Paddle and Dodo, or anything at all through the API.
Why this is the important step
Visitor counts rank your channels by volume, which is almost never the order you care about. The channel that sends a thousand people and no customers should lose to the one that sends forty and eight. Connecting payments is what turns the whole product from a traffic report into an answer.
If you sell more than one thing
No payment provider lets you scope a credential to a single product. A Dodo API key covers every product in the business. A Polar webhook endpoint is registered against an organisation and receives every product in it. A Lemon Squeezy webhook belongs to a store and fires for every product in the store. Stripe and Paddle keys cover the whole account.
So if you sell three things from one payment account and connect it to one website, all three products' money would be counted as that one website's revenue. Nothing errors; the totals simply read high. Under each connected provider in Settings, then Integrations, there is a Products list — tick the ones this website sells.
| Provider | What one credential covers | How the product list is filled |
|---|---|---|
| Dodo | Every product in the business | Fetched from your account |
| Stripe | Every product in the account | Fetched from your account |
| Polar | Every product in the organisation | Learned from payments as they arrive |
| Lemon Squeezy | Every product in the store | Learned from payments as they arrive |
| Paddle | Every product in the account | Learned from payments as they arrive |
Leaving every product ticked is the default and imports everything, which is what a connection did before this existed. Polar, Lemon Squeezy and Paddle store a signing secret rather than an access token, so there is no way to ask them for a product list — theirs appear as payments arrive, which is also how you find out another product has been posting into this website.
Choosing products changes what is imported from now on. Payments already recorded stay in the website they landed in, so re-import after narrowing the list if you want the existing numbers rebuilt.
Polar, Lemon Squeezy and Paddle
Open Settings, then Integrations. Each provider shows a webhook URL to copy, the exact list of events to subscribe to, and a box for the signing secret. Paste the URL into your provider, choose a signing secret there, then paste that secret back into Termind. The secret is encrypted before it is stored and never shown again.
| Provider | Events to send |
|---|---|
| Polar | order.paid, subscription.created, subscription.canceled, refund.created |
| Lemon Squeezy | order_created, order_refunded, subscription_created, subscription_cancelled, subscription_payment_success |
| Paddle | transaction.completed, subscription.created, subscription.canceled |
Every webhook is signature-checked, and a request older than five minutes is refused even if the signature is valid — otherwise one captured payment event could be replayed forever to inflate revenue.
Customers are matched to the people you already track by email address. A payment from an address Termind has never seen is still recorded as revenue; it simply has nobody attached until that person identifies.
How annual plans are counted
A yearly subscription is divided by twelve for monthly recurring revenue. Counting the whole charge in the month it arrives makes MRR spike and then appear to collapse for the next eleven months, which describes an accounting artefact rather than your business. Weekly and daily plans are converted the same way.
Amounts are held as whole minor units — cents, pence — end to end. No stage of this touches a floating-point number, which is how a revenue report ends up three cents out and never gets believed again.
Anything else
await termind.revenue({
personId: "user_123",
amountMinor: 4900, // whole cents, never 49.00
currency: "EUR",
plan: "Growth",
eventType: "payment_succeeded",
});