Your Stripe dashboard tells you how much you earned. It cannot tell you which campaign earned it. Connecting Stripe joins the two: a payment arrives, and the dashboard already knows where that visitor came from.
What you get
Revenue beside your traffic, in the same date range and the same channels
Which channel brought the money — often not the one bringing the visitors
New and renewal revenue separately, so growth is not hidden inside recurring income
Refunds and chargebacks shown as they happen
Fourteen subscription goals with no code — trials started and converted, renewals, upgrades, downgrades, pauses, cancellations, churn, and warnings before a card fails or a trial ends. Each is usable as a filter. See the subscription goals.
Connecting
Create a restricted key
In TrueStat, open your site's Settings → Integrations and press Create a key in Stripe. The link opens Stripe with the eight permissions already ticked, so you only need to confirm and copy the key.
Seven are read-only. The eighth lets us register one webhook so payments reach us as they happen — it cannot change your prices, your products, or take payments.
Paste it back
Return to the Integrations tab and paste the key. We check every permission before saving; if one is missing, the screen names it.
Add two lines to your checkout
This is the step that makes attribution work. See below.
Linking a payment to a visitor
Without this, payments still appear — but under unattributed, because nothing connects the payment to the visit that led to it.
Our script stores a visitor id in a cookie. How you pass it to Stripe depends on how your checkout opens:
Two places, not one. Stripe copies metadata between related objects
nowhere, so the top-level metadata and subscription_data.metadata both
have to be set — the first reaches the checkout event, the second reaches
every renewal. The Checkout Session page covers this.
What the numbers mean
Revenue is what settled into your Stripe account. If a customer pays in euros and your account is in dollars, Stripe converts it and we record the converted figure — so the total matches your Stripe dashboard exactly.
Refunds are shown separately, not subtracted. A refunded payment still happened. Stripe lists revenue and refunds as separate lines and so do we.
Unattributed revenue still counts. It appears in the total with its own line, because a total that disagrees with Stripe is a total you cannot trust. The gap is usually checkout code missing the metadata above.
If you run a subscription business, you may want MRR here instead. Revenue answers "what came in this month" and swings with every annual prepayment; MRR answers "what are my live subscriptions worth per month". Both read this same connection — see What counts as revenue.
Your history comes with you
Connecting imports what Stripe already has. Your dashboard starts with your past rather than an empty chart — payments, refunds, subscriptions and the MRR curve, as far back as Stripe will serve them.
The import runs in the background and the panel says so while it works. Most accounts finish within minutes; a large one can take up to 24 hours, because we read your history a page at a time and deliberately stay well inside the rate limit on your own Stripe account.
Imported totals match Stripe exactly. Verified on a real account: 142 charges, $84,226.03 gross, $33,747.11 refunded and $49.00 MRR — the same four figures Stripe reports for the same period.
What imported payments can and cannot tell you
An imported payment counts towards your totals, your revenue chart, your MRR and your subscription goals. It does not appear in the channel, source, country or device breakdowns, and it never will.
The reason is not a limitation we plan to lift. Linking a payment to a campaign needs two halves: the visitor id in Stripe's metadata, and the visit itself recorded on our side. For a payment taken before you installed the script, neither exists. Putting those rows into a channel would mean inventing one, so they stay out of the breakdowns and the percentages there remain true.
Payments taken after you connect carry both halves and behave normally — they appear everywhere, attributed to the campaign that won them.
Re-syncing later
Site settings → Integrations → Re-sync history runs the import again. The button is disabled while an import is running and comes back with a summary of the last one: how many payments were imported, how far back they reach, and when it finished.
Two situations make it worth pressing:
The first import failed. The panel says so, and a revoked or under-permissioned API key is the usual cause. Fix the key, then re-sync.
The connection was broken for a while. Payments that arrived while the webhook was down were never recorded; re-syncing finds them.
Re-importing is safe to repeat. A payment already recorded is recognised and skipped, so pressing the button twice cannot double your revenue.
Reading revenue in another currency
In your site's Settings → Integrations, pick any currency for reporting. Amounts are stored in your account currency and converted at today's rate when the dashboard draws them, so the underlying figures never change.
The account currency stays the default, because it is the figure that matches Stripe.
Disconnecting
Your site's Settings → Integrations → Disconnect removes our webhook from your Stripe account and deletes the revenue collected here. Your Stripe data is untouched.
Reconnecting imports your history again, so the gap closes on its own — the payments taken while the connection was down are read straight from Stripe. What does not come back is the attribution for that period: a visit we never recorded cannot be linked to a payment afterwards, so those rows arrive unattributed.