Privacy policy

Written from the product’s own security model and the decision records behind it, so every claim here corresponds to something in the code. It has not been reviewed by a lawyer.

Two relationships, and the difference matters. For your own account — your email, your sessions, your billing — Sellstamp is the controller. For the people who buy from a store running on Sellstamp, the merchant is the controller and Sellstamp is their processor.

If you bought something from a store and want to reach someone about it, that is the merchant, not us. Your order email has a link that reaches them directly.

An order needs an email address to deliver to, an amount, a currency and — where tax applies — the country the buyer declared. A licence needs something to bind to. A download needs a grant. That is the shape of nearly everything here.

• Merchants. Email address, name, workspace and role, sessions and their devices, audit records of what was changed, and billing records for what you pay us. At sign-up and each sign-in, a one-way hash of the browser’s fingerprint and of the network address, kept 90 days, used only to notice a new account on the device of a merchant Sellstamp suspended. Nothing raw is kept, and these hashes cannot be matched against any store’s customers. A match is a note for a person at Sellstamp to read, never an automatic refusal. A store’s own public text is read for signs of phishing when it publishes and when it changes. For what you pay Sellstamp, a one-way hash of the card the payment provider names, used to notice a referral reward or a theme or app payout going back to the payer.
• Customers of a store. The address the order was placed with, what was bought, what it cost, its tax facts, the country declared for tax, and — for a licence — the hashed value the licence binds to. Anything written to a store’s support, live chat included, is kept on the ticket so the store can answer it later, by email if nobody is online; the chat says so before the first message is sent.
• Never. No card number, anywhere. Every card method is the provider’s own hosted page, so there is no card data in this system to lose — not a brand, not a last four, not an expiry date.

Everywhere else in this product, what Sellstamp stores is the exhaust of completing a transaction. There are exactly two places where Sellstamp itself collects something in order to judge or to measure, and both are here because a policy that hides them is not a policy. What a merchant can add on top — third-party tracking on their own store — is the next section.

Fraud signals at checkout. A fingerprint the browser computes from standard properties, and the address the request arrived from. Both are HMAC-hashed before anything reaches the database, under a key used for nothing else; neither raw value is ever written to a column, a log or a response. They feed five named rules that raise sentences on the merchant’s order page — no score, no model, no automated decision. A customer whose browser sends no fingerprint can still buy, and a customer with every flag raised can still buy. The legal basis is legitimate interest. Beside them, two coarse facts: the country of the browser’s time zone (never the time zone itself) and roughly how fast the checkout was sent, as one of five steps (never the exact time). They are kept and deleted with the hashes.

What the rules said about an order. For each paid order Sellstamp keeps a record of which rules fired, in the same sentences, with the counts behind them and the order’s size against the store’s usual order. It holds no hash, no email address and no network address. The merchant can also mark an order as fraud or as legitimate. Both exist only to check whether the rules are right, they change nothing about the order, and Sellstamp staff see them only as totals across the platform.

What the payment provider said about a payment. When the store’s payment provider reports a payment paid, Sellstamp keeps what that provider said about it: whether the card’s security code and postal code matched, whether 3-D Secure ran, the card’s country and type, and how many tries were declined before it. The card is kept only as a hashed fingerprint, under a key used for nothing else, never as a number. This is the merchant’s own provider describing the merchant’s own payment; Sellstamp sends it nowhere and calls no fraud service. A store that switched fraud signals off keeps none of it.

When a store asks you to confirm your email. A store may hold your download until you click a link sent to the address you bought with. Your receipt arrives either way. Only a fingerprint of that link is kept, never the link itself, and opening it is all it takes. A store may also hold delivery of an order for a person to check; the order page tells you so, and, when the store set a timer, until when.

Storefront analytics. Off until a visitor affirmatively accepts, revisitable from a persistent switch, and the store behaves identically either way. The identifier is an anonymous value the browser generated into session storage, which the endpoint refuses unless it is exactly 32 hex characters — an email or an order token cannot be written to that table by any caller. It dies with the tab. Merchants see totals and top-of-list figures; there is no per-visitor journey view, because there is no function anywhere that returns one.

No Radar, no Sift, no MaxMind, no hosted fingerprinting service, no advertising pixel of ours and no geolocation of any kind. There is no IP-to-country table in this product, so nothing here can say where somebody was.

Sellstamp does not add a third-party tracking script to a store by default. A store that has configured none of the tags below loads none of them — not even an empty one. But a merchant can enter an account id for any of them in their store’s settings, and from then on that vendor receives data about the store’s visitors directly, under the vendor’s own terms.

None of this is behind a consent banner. The banner described above governs Sellstamp’s own analytics and nothing else. A tag a merchant has switched on loads on a visitor’s first page, whether or not they accepted anything, and the server-side conversions below are sent the same way. A merchant who turns these on is responsible for any consent their visitors’ law requires; Sellstamp does not currently collect it for them.

• Meta Pixel, TikTok Pixel and the Google tag (Google Analytics 4 / Google Ads). Loaded on the store’s pages. Each reports a page view, and the order page reports a purchase with its amount, currency and order id. Each is the vendor’s own script, so it also sets and reads the vendor’s own cookies and sees what any script in the page sees — including the visitor’s address, browser and the page they are on.
• Microsoft Clarity. Heatmaps and session recording. Clarity’s script records mouse movement, scrolling and clicks across a visit — a broader capture than an ad pixel’s single event — and sets its own cookies.
• Server-side conversions to Meta, TikTok and Google Analytics 4. If the merchant also connects a platform’s server API, Sellstamp’s server sends each paid order to it: the amount, the currency, the order id, and the identifiers that platform’s own cookies hold in the buyer’s browser (Meta’s browser and click ids, TikTok’s browser and click ids, Google Analytics’ client and session ids).
• A hashed email, to Meta and TikTok only, and only if the merchant ticks a separate box. The buyer’s email address, lower-cased and SHA-256 hashed, so the platform can match the sale to one of its accounts. A hash of an email is still personal data to a platform that holds the same address. Google forbids this in its server API, so it is never sent to Google.

• Fraud signals: 90 days, swept hourly. Above the window the rules look back over and above the span most card disputes arrive in; below anything resembling indefinite. The honest cost is that a dispute landing on day 100 finds no device signal left.
• Fraud-rule records and fraud labels: 365 days, swept hourly. Longer than the signals because chargebacks arrive late, and a rule can only be checked against an outcome that arrives while its record still exists. They contain no hash or address, and erasing a customer deletes them at once.
• The payment provider’s result and the hashed card: 90 days, swept with the fraud signals, and deleted at once when a customer is erased.
• Storefront analytics: 90 days, on the same hourly sweep.
• Merchant sign-in hashes: 90 days, and what the platform noticed about a merchant: 365 days, both swept hourly and deleted with the account.
• API usage records: 90 days. Templated routes and counts — no URL, no query string, no body, no address. A meter, not a request log.
• Orders, invoices and licences: as long as the merchant is obliged to keep them. An erasure strips the identifying fields and leaves the amounts, statuses and timestamps, because transaction history is a legal obligation that survives a deletion request.

A customer of a store can do both themselves. No support ticket, no merchant in the loop, no Sellstamp account: a single-use, one-hour link to the address, exchanged once for a short session, and the request page answers identically for every address — so it cannot be used to test whether somebody has shopped somewhere.

• Export gathers everything that store holds about you and hands it over.
• Erasure takes two steps, never one. The link shows a summary; erasing needs a second explicit confirmation from a page that has already said in plain words what will be anonymised and what will be deleted. A forwarded or mis-clicked link cannot erase an order history.
• It is a hard delete. Notes, marketing consent and send history, portal credentials, support threads, reviews and fraud signals are deleted outright, not hidden behind a restore window. A test asserts that against the live schema, so a later change that made one of those recoverable would fail the build rather than quietly weaken the right.
• Partial erasure is impossible. It happens in one transaction, and the audit record keeps counts and the placeholder address — never the real one, because a compliance log must not become the last surviving copy of what was erased.

A merchant can also trigger an erasure on a customer’s behalf, for the real case where the request arrives by email. That path is gated by a fresh proof of identity rather than by a dialog, and it refuses the same way the customer’s own does while a subscription is still live — we will not cancel somebody’s billing at their provider off the back of a privacy request.

For your own merchant account, the dashboard exports everything and closing the account is yours to do.

The people you would expect from the shape of the product: your payment provider, which you chose and hold the account with; the email provider that delivers the order mails; the object storage the files live in; and the infrastructure it all runs on. Beyond those, this is the whole list.

• Meta, TikTok, Google and Microsoft, on a store whose merchant switched their tags on — what each receives is in the section on third-party tracking above.
• Cloudflare, on a store whose merchant turned on its CAPTCHA. Cloudflare Turnstile runs in the visitor’s browser on the places the merchant chose — store entry, checkout, sign-in — once a challenge is actually due, and Cloudflare sees what a script in the page sees, including the visitor’s address and browser.
• The store’s payment provider, again, when you dispute a payment and the merchant chooses to answer through Sellstamp. The merchant clicks to send the evidence pack: your email address, what you bought, when it was delivered and downloaded, licence activation dates and device names, the subjects of the store’s emails to you, and the terms you accepted. Never your IP address or a device identifier, which Sellstamp does not keep.
• Anthropic, when a merchant uses an AI feature — the store builder, a blog draft, SEO suggestions. It receives what the merchant typed and the store details the feature needs.
• Have I Been Pwned, when a password is set: the first five characters of the password’s SHA-1 hash, so a password known from a breach can be refused. The password, the full hash and the account never leave.
• Google or Apple, if you choose to sign in with them.
• Integrations a merchant connects — email marketing and CRM (Mailchimp, Kit, Klaviyo, HubSpot), Notion, Google Sheets, shipping labels (EasyPost), GitHub repository access, chat notifications (Slack, Discord, Telegram), Google Search Console and Bing, and apps installed from the marketplace. Each receives what it exists to carry — a customer’s email for a mailing list, a shipping address for a label, a GitHub username for repository access — and nothing until the merchant connects it.
• jsDelivr and Hugging Face, which serve the free background-remover tool’s model to your browser. The image itself never leaves the browser.
• Sellstamp’s own error tracker, which Sellstamp runs on its own infrastructure. When a page or a request fails, it receives a description of the failure: the route, the browser family and version, the release and a reference number. Email addresses, IP addresses, tokens, card numbers, cookies and anything typed into a form are removed before it leaves the server or the browser, and nothing is recorded about what is on the screen.
• Problem reports and security reports you send us stay with Sellstamp: our staff read them, and a security report only the few staff who handle security. A shopper's report does not go to the store.
• No data is sold. Sellstamp runs no advertising and shares nothing for advertising of its own; the ad platforms above receive data only from stores whose merchant switched them on.
• An AI connection a merchant authorises reaches only what they ticked, at one store, and licence keys come back masked. It can never reach another store, by any argument.
• Support staff acting as a merchant leave a record saying they did. Impersonation is not invisible.
• A webhook you configure sends your workspace's events to an address you chose — that is your integration, and where it goes is your decision.

• A session cookie when you sign in, and a short portal cookie when a customer proves an address. Both necessary; neither is a tracker.
• An attribution cookie if you arrive through an affiliate or marketing link, on that store’s own host, holding an identifier that resolves against that store and nothing else. Nothing about the person clicking is read — not the address, not the user agent, not the referrer.
• Third-party cookies, on a store whose merchant switched on Meta, TikTok, Google or Microsoft Clarity tags. Those are the vendor’s own cookies, set by its own script, and are not behind a consent banner — see the section on third-party tracking.
• Analytics consent is stored in the browser’s own local storage, per store, so one shop’s choice cannot follow you to another.

The contact page says who to write to for what, and is honest about the routes that do not exist yet. If you found a security problem, it is the place that tells you how to report it.