Privacy policy

Who this covers

This policy covers Paylytics: the account you sign in with and the payment accounts you connect to it. It is written for the person using the dashboard.

It is worth being clear about a second group from the start. The data you connect describes your own customers, so some of what we hold is information about people who have never heard of us. We hold it only to show it back to you, and the section on your customers below says exactly where that responsibility sits.

What we hold

• Your account: the email address you sign up with, an optional display name, and your password stored only as a bcrypt hash. The password itself is never written down anywhere, so it cannot be read back, by us or by anyone else.
• Your connected accounts: the access key for each one, encrypted; the provider and the account name; the picture the provider publishes for it; and the photo you upload for it, if you upload one.
• A copy of your payment data: orders, subscriptions, customers and products, as your provider returns them. The customer names and email addresses on those orders are encrypted before they are written, so the database itself does not hold them in readable form.
• The figures are not encrypted, and that is a deliberate limit rather than an oversight: amounts, dates, statuses and currencies are what every total, chart and date filter is computed from, and those sums are done by the database, which cannot add up something it cannot read.
• Your session: one cookie holding a random token, alongside the date it was issued and the date it expires.
• Your subscription, if you have one: identifiers issued by Polar, the status of the plan, and the date the current period ends. No card number, no billing address and no payment method ever reaches us — Polar holds those.
• Nothing else. There is no tracking, no advertising identifier, no profile of you or of anyone who bought from you.

The copy exists because merging is the whole product. Reading four accounts live on every page load would mean dozens of requests to your providers each time you changed a date range, so the data is mirrored once when you refresh and read locally after that. That is a design decision with a privacy cost, and stating it plainly is the point of this section.

Why we hold it

• To show you your own figures, merged across the accounts you connected.
• To keep you signed in between visits.
• To tell you when a sync failed, when a key stopped working, or when its permissions changed.

There is no fourth purpose. Your data is not used to train anything, not sold, not aggregated into a market report, and not used to build a picture of you or of your customers. The single figure computed across more than one business is the live board on the home page, which is set out in full further down this page, along with how to be left out of it. If that ever changes it becomes a different product, and you would be asked rather than told.

How it is protected

Rather than describe this as a posture, here is the actual list, so you can judge it instead of taking our word for it.

• Provider keys are encrypted with AES-256-GCM before they are written to storage. They are decrypted only on the server, in memory, for the moment a sync runs.
• Your customers' names and email addresses are encrypted the same way, per value, each with its own random nonce, so two orders from the same person do not even look alike in the database. Anyone reading the database directly — a leaked backup, a stolen dump, a console session — sees ciphertext where the people are.
• Grouping one buyer across several accounts still works because each address also carries a keyed fingerprint. It is an HMAC rather than a plain hash, which matters: a bare hash of an email can be reversed by hashing a dictionary, while this one cannot be computed at all without the same secret the encryption uses.
• A key is never sent to a browser, never returned by any endpoint, and never written to a log. The dashboard shows the last four characters only, so you can tell two keys apart.
• Passwords are hashed with bcrypt. There is no code path that reads a password back.
• Your session cookie holds a random token; the database holds only its SHA-256 hash. Someone reading the database still could not sign in as you. The cookie is HTTP-only and SameSite=Lax, so a script on another site cannot read it or ride on it, and it expires after thirty days.
• Every request travels over HTTPS.
• Ownership is the boundary, not the page. Every query is filtered by the account that owns the row, so a guessed or edited identifier in a URL returns nothing rather than someone else's order.

Read-only, and what that is worth

The single most important limit on all of this is that Paylytics has no way to write to your payment provider. There is no code in it that creates, refunds, cancels, edits or pays out anything, and a credential that could do those things is refused before it ever reaches the database.

What that refusal is worth differs by provider, so here it is per provider rather than as one sentence that flatters the weakest case.

• Stripe: only a restricted key is accepted. A full secret key is rejected on sight, because it could move money. This is a real boundary, enforced by Stripe.
• Polar: only an organization access token with read scopes is accepted. A personal access token is rejected, because it would carry your own permissions across every organization you belong to.
• Paddle: read and write are separate per-entity permissions, so a key granted only the four read permissions genuinely cannot write. This is the one case that is provable from our side.
• Dodo Payments: read-only is a checkbox at the moment the key is created, and a key created with write access looks identical to one created without it. We tell you to leave it unchecked, and we cannot verify that you did.

We do not share it

• It is not sold, rented or licensed to anyone, in any form, including aggregated or anonymised form.
• There are no advertising networks, data brokers, session recorders or third-party analytics scripts anywhere in the dashboard.
• No other user of Paylytics can see your accounts, your customers, or any figure attributable to you. The live board on the home page is the one exception, and the next section says exactly what is in it: whole-installation sums in which no individual business appears, or can be recovered by arithmetic. The per-account detail drawn beside those sums is the operator's own business and never yours.
• The only third parties involved at all are the infrastructure the service runs on: hosting, the database, and file storage for the pictures you upload. They hold the data in order to run the service, under contract, and for no purpose of their own.
• If you subscribe to the paid plan, Polar processes that payment as merchant of record and receives your billing details directly. We never see or store your card: what comes back to us is your email address, an identifier for your subscription and whether it is currently active. That is a separate relationship from any Polar account you may connect as a data source, and the two are never mixed.
• The public marketing pages count visits in aggregate, without cookies and without anything that identifies a person. That counting does not reach the dashboard and never touches your payment data.

If we ever received a legal demand for your data, we would comply only with a valid and binding order, give no more than it actually required, and tell you it had happened unless we were legally prevented from doing so.

The totals on the home page

The home page opens on a live dashboard rather than a mock-up: settled revenue, a monthly recurring figure, active subscriptions, connected accounts, and a chart of that revenue over time. It is read from the same database the product runs on, and it is the only place on this site where a figure is computed across accounts belonging to more than one business. Rather than leave that as a detail you have to notice, here is precisely what it is and what it is not.

• What it draws in detail — the chart and the account rows behind it — is only ever ours, and even there no business name is shown: each row is labelled "Account 1", "Account 2" and so on rather than the name we actually gave it. The board shows a per-account breakdown while every account connected to Paylytics is a business the operator runs, and it says so in plain words on the page. Your business is never drawn that way.
• The moment a second business is in those figures, the breakdown stops being published. From then on the page carries the totals and nothing else: no per-business row, no account name, no product, no country and no split by provider, and the chart goes back to an illustrative sample that is labelled as one.
• Between those two states nothing real is published at all. Pooled figures wait until enough separate businesses are connected that no single one's could be recovered from them by subtraction.
• Pooled money figures are rounded down, so what you see is a floor rather than an exact reading of anyone's book. The operator's own figures are published exactly, because they are ours to publish.
• Nothing about your customers is in it, in any form. Not a count, not a country, not a total. Nor is anything about ours: the buyers listed in the customers view carry an order count and an amount, and no name or address is sent to the page at all.
• It is never sold, licensed, exported or handed to anyone. It is a statement about the product, on the product's own home page, and it goes nowhere else.
• You can be left out of it. Ask us and your accounts stop contributing to every figure on the board, and stop counting towards the threshold that decides whether pooled figures are shown at all.

The worst case, said plainly

Most security pages tell you what a product does. Far fewer tell you what it looks like when that fails, which is the part actually worth knowing before you paste in a key. So here is ours.

Because everything here is read access, the ceiling on a breach is disclosure. Nothing that could be taken can move money.

How much would be disclosed depends on what was actually taken, and the two cases are genuinely different. Someone who got the database alone — the most common way this goes wrong, through a leaked backup or a stolen dump — would read your revenue, your orders, your subscriptions and your products, but the customer names and addresses would be ciphertext, and the keys with them. Someone who got the running server and its secrets as well as the database would be able to decrypt all of it, because that is where the key has to live for the dashboard to be able to show you anything at all.

What they could not do is take money out of your account, issue a refund, cancel or reprice a subscription, change a payout destination, charge one of your customers, or reach anything in your provider account beyond those four read scopes. Not because we would stop them, but because the software has no instruction that does any of it and the credentials it holds are the wrong type to try.

You can lower that ceiling yourself at any moment, and you do not need us to do it. Revoking a key at your provider ends our access immediately, whatever is happening on our side. Disconnecting an account here deletes our copy of its data.

If we notice something, we tell you

• A breach affecting your data is reported to you directly, by email, as soon as we understand what happened, rather than after a report has been polished. It will say what we know, when it happened, what it touched, and what to do about it, which will usually start with revoking your keys.
• There is an automatic one too. Every sync re-checks what your key can actually read, and the dashboard tells you when that changes. Losing a permission means those figures silently stopped updating. Gaining one means somebody edited the key, which is the closest honest signal available that write access may have been added to it.
• A failed sync, an expired key or a revoked key is shown on the account rather than hidden behind a stale number.

What you can do about any of this

• Disconnect an account at any time. Our copy of its orders, subscriptions, customers and products is deleted with it.
• Revoke a key at the provider at any time, without telling us. The connection simply stops working.
• Cancel the paid plan at any time, from the billing portal reached inside your dashboard. Nothing is deleted and no account is disconnected when it lapses.
• Ask us for a copy of everything we hold about you, and we will send it.
• Ask us to delete your account, and everything attached to it goes: your login, your connected accounts, the stored keys and the mirrored data.

On retention: mirrored data lives for as long as the account it came from stays connected. Sessions expire after thirty days. Nothing is kept as a shadow copy after a deletion, beyond whatever survives briefly in routine infrastructure backups before they rotate out.

If you are in the UK or the EU, the rights that come with the GDPR apply here in the ordinary way, and the list above is how they are exercised. Write to us and a person answers.

Your customers' data

The people who bought from you are your customers, not ours. You decide what happens to their data; we process it on your instruction, which in practice is the instruction to fetch it and show it back to you.

• We never contact them, market to them, or add them to anything.
• Their data is not combined with anyone else's, and never leaves your view of the dashboard.
• In data protection terms you are the controller and we are the processor. If your own privacy notice has to name the processors you use, that is us.

Cookies

One cookie, holding your session token. It is what keeps you signed in, it is strictly necessary for that, and there is nothing else to accept or refuse. That is why there is no consent banner on this site: a banner asking permission for a cookie you cannot decline while using the product would be theatre.

Changes to this policy

When this policy changes, the revised version is posted here with the date at the top. Anything that materially changes what we hold or who can see it will also be sent to you by email before it takes effect, rather than slipped in and dated quietly.

Asking a person

Anything on this page, anything not on it, or a request to see or delete what we hold: write to privacy@paylytics.app and a person will answer.