Skip to content
Storefront Ninja

Privacy

What Storefront Ninja stores, why it needs each piece, where it is kept and how to have it removed.

Who runs this

Storefront Ninja is a product of mixtape.works, run by Human Hygiene Kft., 1163 Budapest, Datolya utca 40., Hungary (company registration number 01-09-464537, EU VAT number HU12087783; full details at mixtape.works/imprint). Write to support@mixtape.works about anything on this page.

Sellers and shoppers

A seller who opens a shop here is our customer, and everything below is about them. A shopper who buys from one of those shops is buying from the seller, not from us: the seller decides what to ask a shopper for, and we hold it for them, on their instructions, so their shop can work.

What is stored, and why each piece

  • The shop: its name, the address it answers on (yourshop.storefront.ninja), the language it is written in, the currency it prices in, its country and time zone, its plan, and how it can be paid: whether it takes a card payment through its own Stripe account, whether it takes cash on delivery, and the account holder and IBAN it asks shoppers to transfer to and what it wants written as the reference, and how a shopper reaches the seller: the shop’s contact e-mail address, telephone number and business address. If the seller has uploaded a logo or a tab icon, the file each is stored as is kept here too, and so is the home-screen icon we draw from the tab icon, in the three sizes a phone needs, and so are the accent colour they chose and whether they made the shop always light or always dark. All of it is public: it is what a shopper sees on the pages of the shop. Without these there is nothing to serve at that address, no way to know what the shop costs, and no way for a shopper to pay the seller.
  • Who may open a shop's admin: the id of their mixtape account, the e-mail address that account has confirmed, and whether they own the shop or work in it.
  • A signed-in browser: the random token that is in its cookie, the mixtape account it belongs to, that account's e-mail address and name, the language it chose, and when the session began, was last used and expires. Signing in is done by your mixtape account at account.mixtape.works, the one login for every mixtape product, so Storefront Ninja never sees or keeps a password.
  • The mixtape account of everybody who has signed in here: its id, the e-mail address it has confirmed, the name it carries, and when it first and last signed in. The first date is how we know how long you have been with us, and the account is what a shop's admin is tied to.
  • A sign-in that is in progress: the random values that tie the answer coming back from account.mixtape.works to the sign-in your browser started, and nothing about you. The row is deleted the moment you come back, and in any case within fifteen minutes.
  • What a shop sells: its item number, its price and sale price (as a whole number and a currency code), its weight when the seller has typed one, how many are in stock, whether it is shown in the shop, and when it was put up and last changed. This is the seller's own catalogue, held for them so their shop can work.
  • A product's words, one set per language the seller writes in: its name, its short and long description, the Google title and description the seller may write for it, and the address it answers on inside the shop. Written by the seller, read by shoppers.
  • A product's photos: the file each one is stored as and the order they are shown in. The seller uploads them, and they are public, because they are what a shopper sees on the product's page.
  • How a shop sends things and what it charges: for each delivery method the countries it serves, and its pricing - either one flat price and the order value from which it is free, or a set of tiers by order value or by weight (see shipping_method_bands) - as whole numbers and a currency code. Written by the seller and read by shoppers at checkout. A shop with no delivery method takes its orders for collection.
  • A delivery method's name, one per language the seller writes in. Written by the seller, read by shoppers.
  • The tiers of a delivery method priced by order value or by weight rather than one flat price: each tier's boundaries and what it charges within them, as whole numbers and a currency code. Written by the seller, read by shoppers at checkout.
  • The VAT rate you set for each country that has its own (for example Germany at 19%). It holds no personal data.
  • The tax classes you name (for example Books at 5%) and their default rate. They hold no personal data.
  • The rate you set for a tax class in each country that has its own. It holds no personal data.
  • Invoices issued before invoicing was taken out of the product: the number and the day of each one, the storno of a cancelled order, and the PDF kept for each. Nothing in the product reads or sends them now, and no new invoice is issued.
  • An order somebody placed in one of those shops: its number, the shopper's e-mail address, name and phone number, the delivery address, any note they left, the language they ordered in, how they chose to pay, what it came to (as whole numbers and a currency code), the discount code they used and what it took off, how it was sent (the delivery method's name as it read that day, and what delivery cost), where it stands, when it was placed, and the random token in the shopper's own link to it. When the shopper's first add to their basket carried a campaign tag (utm_source, utm_medium, utm_campaign, such as a newsletter link or a paid ad), that tag is kept on the order too, so a seller can see which channel its revenue came from; an order with none is one nobody tagged, or one typed in by hand. The shopper gave all of this to the seller, not to us; we hold it for the seller so their shop can work. Billing details the shopper chose to add at checkout - a billing name and address, a company name and a tax or VAT number - are kept on the order too. For a business buyer with an EU VAT number, we also keep whether the sale was reverse charge (no VAT on it) and the day a VIES check said the number was valid. The number is sent to the European Commission’s VIES service, which answers only whether it is a valid VAT number; nothing else about the buyer is sent to it, and its answer is kept in memory for an hour, never in our database. When a card payment on it is disputed by the shopper's own bank, we keep what Stripe told us about the dispute: its reason, the amount in dispute, the deadline Stripe gave to respond, and whether it was later decided in the seller's favour or lost as a chargeback. When the owner marks it shipped, the carrier's tracking number and link they typed are kept on the order too, and shown to that shopper.
  • What is on an order: which product and which combination of it (size, colour) it points at, and the name, the combination, item number, unit price, quantity and line total exactly as they read at the moment it was placed. They are copies on purpose, so a price the seller changes afterwards cannot change an order that has already been made.
  • Where an order has been: every status it has taken (new, paid, sent, cancelled), when it took it, and the e-mail address of the shop person who moved it there, or nothing at all when it was the shopper’s own press. It is how a seller can answer "when did you post it?" and how we can tell what happened if an order is ever disputed.
  • Every message the product sends about an order, and every notice we send a shop's own owner about the shop itself - a payment on its plan failing, a yearly plan about to renew, its closing, a nudge to add its first product, or its weekly numbers e-mail: which kind it was, the address it went to, the address a reply goes back to, its subject line, which of our own addresses it was sent from, when it was sent and whether the delivery worked. That last part is whether our mail service took it and, when it tells us afterwards, whether the receiving mail server accepted it or refused it (with the reason it gave) and whether the person it went to marked it as spam. The message itself is not kept, only the fact of it, and it is what lets a seller see that a shopper was told about their order - or an owner told about their shop - rather than having to hope.
  • How a seller groups their products, and how those groups nest one level deep: the order they are shown in, which one is inside which, the seller's own picture for it, and when each was made and last changed. This is the seller's own catalogue, held for them so their shop can show it.
  • A category's name and its own words above and below its page, one set per language the seller writes in, and the address it answers on inside the shop. Written by the seller, read by shoppers.
  • Which of a seller's products are in which of their categories - a product can be in several at once. Set by the seller, read by shoppers browsing a category.
  • The options a seller sells a product in, such as size or colour, and the order they are shown in. Part of the seller's own catalogue, held for them so their shop can show it.
  • An option's name, one per language the seller writes in, such as Size and Méret. Written by the seller, read by shoppers.
  • The values of an option, such as S, M and L, and the order they are shown in. Part of the seller's own catalogue.
  • The word for each value, one per language the seller writes in, such as Red and Piros. Written by the seller, read by shoppers.
  • Each combination of a product's options that can be bought, with the seller's own item number for it, its stock, how much more or less it costs than the product, and when it was made and last changed.
  • Which values make up each combination, such as size M with colour red. Nothing else is stored here.
  • Which blocks your front page is made of, in the order you set, and how each is set up: its type, its size and shape, the sort of its products, the addresses it links to and the pictures it shows (as the names of files you uploaded). No words are in it: those are kept apart, one row per block and language. All of it is public: it is what a shopper sees on the front page of your shop. One row per shop.
  • The words you wrote for your front page's blocks (a headline, a line of text, a button label, a description of a picture, a block of text, a heading), one row for each block and each language you wrote them in. Written by you, read by shoppers in their own language.
  • A seller's own pages, such as an About or a returns policy: each page's web address, whether it is published, the order the pages are listed in, and when each was made and last changed.
  • The title and the text of those pages, one set per language. Written by the seller, read by shoppers once the page is published.
  • A seller's discount codes: each code, whether it takes off a percentage or an amount, the smallest basket it works on, the last day it works, how many times it can be used, whether it is turned on, and when it was made and last changed.
  • One random key for each day, used only to scramble visitors for the visit counts described next. A day's key is deleted as soon as the next day's is made, so at any moment there is one key, and nothing that could recognise a visitor from an earlier day.
  • A count of what visitors did in a shop, for the seller's analytics page: for each day, which of four things a visitor did (looked at a product, put something in the basket, opened the checkout, placed an order) and when it first happened that day. On a visitor's first counted step of a day, the host of the site that sent them (such as google.com, never the full address) and any campaign tags on the address they landed on (utm_source, utm_medium, utm_campaign) are kept too, so a seller can tell which channel its shoppers come from; a later step the same day keeps none of this. A visitor is only a scrambled code made from the shop, the visitor's internet address and browser type, together with that day's key. Once the day is over the key is deleted, so the code can no longer be turned back into an address or matched with the same person's code on another day. The address itself, the pages looked at and what was in the basket are not kept.
  • A message a visitor sent through a seller's own contact-form page: their name, their e-mail address, the subject and the message itself, which page it was sent from, the language they wrote it in, when it arrived, and whether the notice we send the seller about it was delivered.
  • Your shop's subscription, when it is on one: Paddle's own ids for the subscription and for you as its customer, its status (active, past due, paused or cancelled), which plan and billing period it pays for, when the period currently paid for ends, and any change already due at the next renewal (an upgrade, a downgrade or a cancellation). Not what was bought in your shop, and not a card number: Paddle takes the payment itself and keeps those details, as the merchant of record for it (see where it is, below).
  • Every billing event Paddle has sent us, once, so a message it sends twice changes nothing twice: the event's own id and what kind it was, which shop it was about, and when it happened.
  • One line about our own daily check against Paddle, for every subscription a missed message of theirs could have left out of date: when it last ran, and the one error it hit, if any. Nothing about a shop or a person - this is only whether the check itself is working.
  • The one checkout a shop has open with Paddle while it chooses a plan: Paddle's own id for that unpaid checkout and when it was opened. Nothing about the person who opened it - the shop is the only link, and the next checkout replaces the row.
  • Every billing event Stripe has sent us about a seller's own connected Stripe account, once, so a message it sends twice changes nothing twice: the event's own id, which connected account it was about (never our own platform account), what kind it was, and when it happened.
  • A refund made on a card order, through the seller's own Stripe account: which order it was for, Stripe's own id for the refund, the amount and the currency Stripe reports it in (not always the shop's own currency), its status, the reason given for it, and when it happened.
  • What went wrong, grouped by what kind of thing it was, where it happened (a page's own address pattern, never a shopper's actual link) and why: how many times, when it was first and last seen, and whether a founder has acknowledged it. If a page breaks in your own browser - a script error, a picture that fails to load, a request that never comes back - it tells us which page and what broke, the same way. No IP address, no browser identity, no e-mail address and nothing a visitor typed is ever in it. Kept for 90 days after the last time it happened.
  • For each failure below, how many times it happened on a given shop and when it last did, so the page can name that shop. No personal data: only the shop it happened on.
  • A file you uploaded to bring in or update products, categories, redirects, customers, coupons or gift cards, or a backup of your shop: what it contained (a customers file holds e-mail addresses, names and addresses), how its columns were matched, and what the import did or refused. Deleted automatically 24 hours after you uploaded it, whether or not you ran it.
  • A photo address, or a file name matched to a ZIP of photos you uploaded alongside the catalogue file, while it is being fetched or read: the address or name itself, which product it belongs to, and either the file it was stored as or why it could not be used. Deleted along with the catalogue file it came from (see below), 24 hours after you uploaded it; the ZIP itself is deleted the same way, or sooner, once every photo in it has been used.
  • A catalogue import running in the background: how many of its rows are done, and what it added, updated or refused so far. Deleted with the catalogue file it belongs to, 24 hours after you uploaded it.
  • What an import needs to be undone: a copy of every product, category, redirect, customer's details, coupon and gift card as it was before the import changed it, and which ones it created. Deleted with the file it belongs to, 24 hours after you uploaded it.
  • A category picture a categories file named (an address, or a file name matched to a ZIP of pictures uploaded with it) while it is being fetched or read: the address or name, which category it is for, and the file it was stored as or why it could not be used. Deleted with the file it came from, 24 hours after you uploaded it.
  • What a shop owner brought in about a customer from a customers file (moving from another shop platform, for example): the e-mail address, and any name, phone, delivery and billing address, company, tax number and notes the file held. Never a password, never newsletter or marketing consent. Kept until the shop deletes it, anonymises the customer, or closes.
  • Which of your own products or combinations have fallen to or below the stock line you set in Settings, and have not yet been told about in a low-stock e-mail: no personal data, only which item and when it crossed the line. Cleared the moment that e-mail actually goes out, or the moment the setting is turned off.
  • An invitation an owner has sent someone to join a shop's admin: the address invited, who sent it and when, and the random invitation link's own hash - never the link itself. Deleted 30 days after it expires or is used.
  • A record of who changed what in your shop's admin and when - the member's address at the time and what they did (a product saved, an order moved, a setting changed, and so on), never a card number, a token or a secret. It is append-only and checked every night for tampering. If a customer is anonymised, their e-mail address is scrubbed from this record too, without breaking the check. Kept for 2 years.
  • When a shop's whole data was downloaded as one file - only the moment of each press, so a shop cannot ask for more than a few a day. Nothing about what was in the file is kept.
  • A review you wrote of something you bought: your rating, your text and the name you chose to show, tied to the order it came from - kept until you delete it, or until the product or the shop itself is.
  • A little label an owner made up for their own products ('New', 'Sale') and its colour - never a fact about a shopper, held for as long as the shop exists.
  • The word on one of those labels, in one language - an owner's own writing, never a shopper's, held for as long as the label exists.
  • Which label sits on which product, nothing more - held for as long as both exist.
  • An owner's own hand-picked list of 'you may also like' between two of their products - never a fact about a shopper, held for as long as both products exist.
  • An address that asked to be told when a sold-out product or size is back: which one, which language, and the random link that cancels it - never shown to anyone at the shop beyond the one count 'N waiting for this'. Deleted the moment the one e-mail it ever earns goes out, or after 90 days unanswered, whichever comes first.
  • A shopper who has signed in here with an e-mail link: the address, the language they read in, and when they first and last signed in. Made the moment a link is actually used, never when one is only requested.
  • A sign-in link in flight: the address it was sent to, the language it is written in, and the random link's own hash - never the link itself. Deleted a day after it expires or is used.
  • A shopper's own signed-in browser: the random token in its cookie, which shopper it belongs to, and when it began and expires. Deleted the moment it expires.
  • An address a shopper has saved to their own account here, so checkout can fill itself in next time: a name, a phone number, the address itself, and which one is the default. At most 10 per shopper. An order placed with one keeps its own copy forever, unaffected by a later edit or delete of the saved one.
  • The products a signed-in shopper has saved to their own wishlist, and when - kept for as long as the shopper's own sign-in is (24 months since they were last seen), then deleted with it.
  • A reusable property an owner made up for their own products ('Material', 'Waterproof') and its type - never a fact about a shopper, held for as long as the shop exists.
  • The word for one of those properties, in one language - an owner's own writing, never a shopper's, held for as long as the property exists.
  • One choice of a 'pick from a list' property ('Red', 'Summer') - an owner's own writing, held for as long as the property exists.
  • The word for one of those choices, in one language - an owner's own writing, never a shopper's, held for as long as the choice exists.
  • Which value an owner gave one of their products for one of their own properties - never a fact about a shopper, held for as long as both exist.
  • A hand-picked (or, later, rule-based) group of a seller's own products - 'Gift ideas', 'Summer sale' - with its own page, in the owner's own order. Never a fact about a shopper, held for as long as the shop exists.
  • A collection's name, its own words above the products, its SEO title and description, one set per language the seller writes in, and the address it answers on inside the shop. Written by the seller, read by shoppers.
  • Which of a seller's products are in which of their collections, and the order the owner put them in - a product can be in several at once. Set by the seller, read by shoppers browsing a collection.
  • A seller's own ways to be paid - PayPal, Revolut, cash at a market stall - beyond cash on delivery, bank transfer and card: whether each is switched on and the order they are shown in. Set by the seller, read by shoppers at checkout.
  • One of the seller's own payment methods' name and instructions, one set per language the seller writes in - 'Send to anna@yourpaypal.com', say. Written by the seller, read by shoppers.
  • The seller's own words above and below the order summary in the confirmation e-mail, one set per language the seller writes in. Written by the seller, read by shoppers.
  • The old address of a renamed product, category, collection or page, so an old link keeps working - how many times it has been used, and when it was last used. Deleted along with the thing it used to point to.
  • The seller's own Google title and description for their shop's home page, one pair per language the seller writes in. Written by the seller, read by search engines.
  • An old address the seller has chosen to send on to a page of their own, how many times it has been used, and when it was last used. Kept until the seller deletes it.
  • The seller's own quantity discounts on a product - from how many pieces, and how much that is off - never a fact about a shopper. Kept for as long as the product exists.
  • A gift card a seller has issued: its code, currency, the balance it started with and what is left of it, the recipient's e-mail address and name, the seller's own message, its last day if any, and whether it has been turned off. The recipient's e-mail and name are kept for as long as the card exists, which is for as long as the seller's shop is.
  • Every use of a gift card: when its balance was issued, spent, given back, changed by hand, turned off or back on, by how much, and - when a seller's own team member did it - which one.
  • A seller's own announcement bar: its colour, its optional link, the dates it shows between, and whether it is turned on. It carries no shopper's information at all.
  • The words of an announcement bar, per language it is written in: the text itself and the word on its link, if it has one.
  • A seller's own popup: its optional picture and button link, how it opens and how often it may show again, the dates it shows between, and whether it is turned on. It carries no shopper's information at all.
  • The words of a popup, per language it is written in: its heading, its text and the word on its button, if it has one.
  • The third-party analytics or advertising tools a shop owner has connected, if any (Google Analytics 4, a Meta Pixel, a TikTok Pixel) - their ids, and which products a shopper viewed, added to their basket or bought, but never their name, e-mail, address or phone.
  • A seller's own switch for selling gift cards in their shop: whether it is on, the fixed amounts offered and how long a bought card lasts. Set by the seller, read by shoppers at /gift-card.
  • Who bought a gift card and who it is for: the amount, the recipient's name and e-mail, the buyer's own message, and the sender's name. Kept for as long as the order itself is, which is for as long as the seller's shop is.
  • When an owner closes their own shop, the optional one-click reason and note they are asked for: why, and anything they wanted to tell us. If that shop is later deleted, the note is deleted with it and the row no longer names any shop - only the reason, the day, how long the shop had existed and how many products and orders it had are kept, for us to learn from.
  • The one file behind a product sold as a download: its original name, its size and a checksum of its bytes, so a changed file is never mistaken for the one a shopper paid for. The bytes themselves sit outside the database, never served at a guessable address.
  • A paid order's own private download link: a random token nobody could guess, how many times it has been used and how many it is allowed, and when it expires or was revoked. Deleted 30 days after it expires or is revoked - never the token a stranger could later find in an old e-mail and still have it work.
  • A seller's own blog posts: each post's web address, whether it is published and when, its cover picture, and when it was made and last changed.
  • The title, excerpt and text of those posts, one set per language. Written by the seller, read by shoppers once the post is published.
  • Which of a seller's own products are shown under which of their blog posts, and the order the owner put them in - a product can be under several posts at once. Set by the seller, read by shoppers reading the post.
  • What a seller tells shoppers about their business on the shop's own legal pages: its registered name, its registration and tax numbers, whether each of its terms, privacy notice and returns page uses our template or its own words, and when that last changed.
  • A seller's own words for their terms, privacy notice or returns page, one text per document and language, when they chose to write their own instead of our template. Written by the seller, read by shoppers.

The founders' own keys

Not in the database: the platform's own keys to Paddle and to Stripe, each kept in one file that only the running app can read, never in an environment variable or in code. Paddle's lets us bill a shop's own subscription and verify its webhook; Stripe's lets a shop take card payments straight into its own Stripe account and verifies that webhook. Neither file holds a password, a card number or anything about you or a particular shop.

Cookies

Every cookie we set is our own, and each one only does a job you asked for. lang remembers which language you picked, for a year. On storefront.ninja itself: sn_a holds a sign-in while it is under way, for 15 minutes; sn_s keeps you signed in to a shop's admin, for 30 days; mx_account notes, for 400 days, that this browser has signed in with a mixtape account before, so that a later visit can sign you in again without asking, and mx_silent notes, until you close the browser, that this has been tried once; sn_demo opens the public demo admin, for 2 hours, and sn_demo_refused lets the next page say, for 2 minutes, that the demo did not save a change; sn_preview lets the Appearance editor show a shop owner their unsaved changes in their own browser, for 2 hours. In a shop: sn_cart remembers what you have put in that shop's cart (which shop, which products and how many of each, signed so that nobody else can rewrite it, and never a price) and, if you followed a tagged campaign link to add the first thing to it, which campaign that was (never which pages you visited); sn_coupon and sn_giftcard remember a discount code or a gift card code you typed, until you order or remove it (only the code: what it is worth is worked out again on the server every time); sn_ck and sn_gcbk each hold one random number that ties the checkout form, or the form for buying a gift card, to your own browser, so that a form cannot be posted from somewhere else and a second press of the button cannot order the same thing twice; sn_compare remembers up to 4 products you want to put side by side, until you clear it or press Remove on all of them; each of these lasts 30 days at most and is never sent anywhere else. sn_shopper keeps you signed in to your account at that one shop, for 30 days, and is never sent to another shop; sn_view remembers whether you list products as a grid or a list, for a year. All of these are strictly necessary, and none of them is shared with anybody. A shop's own owner may connect Google Analytics 4, a Meta Pixel and a TikTok Pixel (Settings → Tracking); when they have connected any of these, that shop's own pages show you a cookie banner naming exactly the ones they use, and nothing from any of them loads until you press Accept. That choice is remembered in a cookie named sn_consent, for 180 days, together with which tools it covers - connect another one later and you are asked again. "Cookie settings" in that shop's own footer reopens the banner at any time, and pressing Reject there deletes sn_consent and whichever of these cookies that shop had set: Google Analytics' own, Meta's _fbp and _fbc, and TikTok's _ttp. None of these is shared with anybody but the tool it belongs to, and only once you accept. A shop's own popup, when it has one, remembers in your browser's own storage rather than a cookie - under one key named sn_popup_closed - the id of the one you last closed there and the time you closed it, so it is not shown to you again for as long as the seller chose (never again, or again after 7 or 30 days); this is never sent to our server. A shop's page can carry a video block: nothing loads from it until a shopper presses play, and pressing play loads the video from YouTube (youtube-nocookie.com), which may then set its own cookies. The same rule holds for a shop owner choosing a plan: nothing from Paddle loads on /admin/plan until the owner presses Choose Pro or Choose Max, and pressing it loads Paddle's own checkout script (cdn.paddle.com), which may then set its own cookies or hold its own data in the browser for that checkout and for its fraud checks - Paddle's own privacy policy, not ours, says what and for how long. What a shop's owner sees about visits is counted by our own server as the pages are served, with no cookie and without keeping your address (the two analytics tables above say exactly what is kept), which is why nothing here asks you to accept cookies.

Visits to our own pages

We count how many times each of our own public pages (this one, the front page, pricing, terms and refunds) is opened each day, which site a visit came from (by that site's name only), the country it came from (as our network provider Cloudflare names it, in two letters) and whether it was a phone, a tablet or a computer, and we share those counts with mixtape.works's own Studio. To tell how many different people come each day, our server turns your IP address and browser type into a code, using a random key that changes every day and is then deleted. The address and browser type are not stored, and the code cannot show who you are or link your visits on different days. No cookie is used and nothing is stored on your device; the legal basis is our legitimate interest in knowing how our pages are used (GDPR Art. 6(1)(f)). This is never a shop's own pages, whose visits are counted separately for that shop's owner (the two analytics tables above say exactly what is kept).

Our newsletter

If you subscribe to Storefront Ninja’s newsletter at the foot of our pages, the mixtape account service keeps your e-mail address, the list you chose, your language and the dates you confirmed or left, to send you that list’s news, and mixtape news too if you ticked that box. Nothing is sent until you confirm with the link we e-mail you, every mail carries a link to leave, and the mails go out through Amazon SES in the EU (Amazon Web Services EMEA SARL). When you leave, we keep only the note that you left, so you are never mailed again.

The support chat

Where a page offers it, you can ask our AI assistant about Storefront Ninja. What you type, the address of the page you ask from and its language go to Anthropic (Anthropic, PBC, USA), whose AI model writes the answer; Anthropic processes them for us under its commercial terms, which include the EU standard contractual clauses for the transfer, and does not train its models on them. We keep no transcripts: the conversation stays in your browser tab until you close it. Our server keeps only daily counts (chats, messages and what they cost) and, in memory for a day at most, your IP address and a random number your browser keeps, to limit how many messages one visitor can send. If you choose to send the conversation to a person, it is e-mailed to support@mixtape.works with your e-mail address, so we can reply. The legal basis is our legitimate interest in answering questions about our products (GDPR Art. 6(1)(f)) and, for a hand-off, your request (Art. 6(1)(b)).

How long it is kept

A session ends on its own, and signing out ends it at once. A shop that closes - because its own owner closed it, or because we closed it by hand - is kept for 30 days, so it can be reopened, and is deleted after that. When it is, any note its owner left us on the way out is deleted with it; only the reason they gave, the day, how long the shop had existed and how many products and orders it had are kept, with no name attached. Ask us to delete a shop sooner and we will. Visit counts are kept for about a year and then deleted.

Where it is

In one database file on a server rented from Hetzner Online GmbH (Industriestr. 25, 91710 Gunzenhausen, Germany), in their data centre in Finland, inside the EU. Cloudflare carries the traffic to it. The e-mails about an order are delivered by Amazon Web Services (Amazon Web Services EMEA SARL, from its data centres in Frankfurt, Germany, inside the EU), so the address, the name and what was ordered reach them. When AWS cannot take a message, Resend (Plus Five Five, Inc., United States) delivers it instead, and only then do those leave the EU; apart from the support chat above, nothing else does. A shop that takes card payments connects its own Stripe account (Stripe Payments Europe, Limited, Ireland): a shopper's card details go straight to Stripe, never to us, and the money settles directly into the seller's own Stripe account. A shop on a paid plan is billed by Paddle.com Market Limited, which sells the subscription as merchant of record: its own ids for the subscription and for you as its customer reach them, nothing about a sale in your shop does. Nothing is sold, and nothing is passed to anybody who is not needed to run the service.

Your rights

You can ask for a copy of everything held about you, have a mistake corrected, or have it deleted. Write to support@mixtape.works and we will act on it. If you bought something from a shop here, ask that shop first: what you gave them is theirs. If you signed in to a shop here with your own e-mail link, you can download or delete that account yourself, on the shop's own site.

Last updated November 4, 2026.