Privacy policy

Everything on this page follows from one distinction, so it comes first.

• For a merchant’s own details — the account, the shop, the settings — we decide what is collected and why. We answer for that data directly.
• For a shopper’s details — a name, an email, a delivery address on an order — the shop decides. We hold and process it on the merchant’s behalf, under their instructions. The shop is who a shopper deals with, and the shop is who can change or remove it.

If you bought something from a shop that runs on Shopsy and want your details changed or removed, ask that shop. We are the software underneath; we cannot see or alter your order on their behalf, and their contact details are in their storefront’s footer.

• Your name, email address and phone number, and a password stored as an Argon2id hash — never the password itself.
• Your shop: its name, link, design, pages, categories, products, photographs, delivery areas, charges and offers.
• Your payment gateway keys, encrypted with AES-256-GCM before they are written down. No endpoint in the product returns a secret key, to you or to anyone.
• Sessions and their refresh tokens, so you stay signed in, and — if you turn it on — a two-factor secret and your recovery codes.
• If you sign in with Google rather than a password: the account identifier Google issues, your email address and whether Google has verified it, and your name and profile picture where Google provides them. Nothing else, and we never receive your Google password.
• A two-letter country code for your shop, used to pick your currency and dialling code sensibly when you sign up.
• Where an operator takes an administrative action on your shop, a record of who did it, what they did and why.

All of it exists so the product works or so an account can be recovered and secured. None of it is used to profile you or sold to anybody.

When somebody places an order, the shop needs enough to fulfil it, and that is the extent of what is collected:

• Their name, email address and phone number, and a delivery address where the shop delivers.
• What they ordered, what it cost, any note they left, and — for a shop that sells time — the slot they booked.
• The order’s payment status, and a reference from the gateway. Never a card number: card details are entered on the gateway’s own page and never reach us.
• Their email address, if they subscribe to a shop’s newsletter. Unsubscribing keeps the row and marks it withdrawn, deliberately — that is the only way a later re-import cannot start emailing somebody who asked not to be.

No account is required to buy, and none is created for somebody who only looked. A customer record exists because a purchase happened.

Order tracking asks for an order number and the email used on it. It answers identically whether the order does not exist or the email is wrong — that is not a bug, it is what stops somebody working through order numbers to find out who bought what.

A merchant needs to know how their shop is doing. Nobody needs to be followed around it for that to be possible, so the visits table has no column for an IP address, no device identifier and no fingerprint. What it holds is a hash: the address and browser, salted, with today’s date mixed in.

The date is the part that matters. A hash of an address is still a stable identifier and would follow one person across weeks perfectly well; adding the date means the same visitor is a different value tomorrow, so no one — including us — can join Monday to Tuesday. That is also why the dashboard counts a "unique visitor" as a visitor-day and says so, rather than overstating the number.

• Referrers are reduced to a host — instagram.com — never the full URL, because query strings routinely carry personal data.
• A coarse device class and a country code, both approximate, neither identifying.
• Which page was opened, and which product was viewed.

None of it uses a cookie, and none of it is shared with an analytics company, because there is no analytics company involved. See Cookies for what is and is not set in your browser.

When a merchant asks the assistant to draft a product description, the photographs of that product and the prompt are sent to Google’s Gemini API, which returns the draft. Only images the platform itself stored are ever read and sent — a URL supplied in a request that we did not issue resolves to nothing.

Nothing about a shopper is sent. No order, no customer record, no email address, no analytics. The assistant looks at product photographs and writes copy about them.

An operator can turn the feature off for the whole platform, and a shop that never uses it never sends anything anywhere.

The full list, with what each one is for. There is nothing on it for advertising, attribution or analytics, because none of those are used.

These providers operate in several countries, so data may be processed outside the one you are in. Each is used for the single purpose above and for nothing else.

Depending on where you live, you have rights to see the data held about you, correct it, have it deleted, object to how it is used, or take it elsewhere. Rather than describe a process, here is where each one already is:

• See and correct it: your account and shop settings in the dashboard hold everything we have about you, and it is editable.
• Take it with you: your catalogue exports to CSV from the products screen.
• Delete it: the danger zone in your settings. Resetting empties the shop and keeps your link and design; deleting removes the stores, the catalogue, the orders, the analytics and the account itself, in one transaction, at once.
• Anything else: write to support at the address in the footer. A person answers, and we do not require a form.

If you shopped at one of the shops rather than running one, those requests go to that shop. Where they ask us to act on your behalf, we do.

If you think we have handled your data badly, tell us first — we would rather fix it than read about it. You can also complain to the data protection authority where you live.

• Passwords are hashed with Argon2id. There is no way back from the stored value to your password, for us or for anyone who takes the database.
• Sessions live in cookies your browser will not let JavaScript read, so a scripting bug in a page cannot walk off with one.
• Gateway secret keys are encrypted with AES-256-GCM before they are stored, and no endpoint returns one.
• Payment webhooks are verified against the raw bytes with a timing-safe comparison and de-duplicated, so a forged or replayed callback cannot mark an order paid.
• Uploads are checked by their actual contents rather than their file name, and SVG is refused outright — it is a document format that can carry script.
• Sign-in is deliberately vague and constant-time about which part was wrong, so it cannot be used to find out whether an address has an account.

No system is beyond compromise. If one happens and it affects you, you will be told what happened, what was involved and what to do — promptly, and without waiting for it to be tidy.

The platform is for people old enough to enter a binding contract, and it is not directed at children. We do not knowingly collect anything from a child. If you believe a child’s data has reached us, write to support and it will be removed.

The date at the top is the date this text last changed. A change that affects what is collected or who receives it is announced in the dashboard and by email before it takes effect — not quietly, and not by editing this page and hoping.