Privacy

Two different things happen here and the law treats them differently.

A shop’s clients. When a barber, tattooist, makeup artist or nail technician uses Wunderhand, they decide what to record about the people who book with them and why. That shop is the data controller for it; we are their processor and act on their instructions. Each shop’s data sits in its own compartment, enforced by the database rather than by application code, and no shop can read another’s.

The shop itself, and visitors. For the account a shop owner signs up with, and for anybody browsing the marketplace, we are the controller. That is Paradigm Shift Multimedia Ltd, company number 17048990, registered at 25 Wharf Street, London SE8 3GG, ICO registration C2025422.

If you booked an appointment and want to know what is held about you, the shop you booked with is the right first place to ask. Write to legal@wunderhand.com if that goes nowhere.

To make the booking

Name, email address, phone number. Email is required for a guest booking, because it is the only way to send a confirmation and a link to change or cancel.

The appointments

What was booked, with whom, when, what it cost, what was paid, and whether it happened. Counts of visits, spend and no-shows follow from that.

What the shop writes

Notes a shop keeps on a client, and a date of birth where the shop records one.

Replies to emails

A reply to a booking email is stored against that booking so the shop can read it in context, including the address it came from.

Consent forms

Where a shop uses them: what was agreed, when, and the exact wording as it read on the day rather than as it reads now.

Health answers

Where a service needs them — allergies, medication, skin conditions. Encrypted before they are stored, with a retention date, and every read is logged against the member of staff who made it.

Photographs

Portfolio and cover images a shop uploads. These are the shop’s own material; a client who appears in one should ask the shop.

Everybody who works in a shop and has a login — the owner and anybody they add — is somebody we hold a little about too. For this the shop is the controller, as it is for its clients.

Their login

Name and email address, a hash of the password, and whether they are an owner. Their hours and the services they do, as the shop sets them.

Email alerts

Whether they want an email when somebody books, moves or cancels with them. Each person has their own switch, on Shop → Your login.

Their phone

If they use the app and allow notifications, a code that lets Apple or Google deliver a notification to that phone. It is deleted when they sign out of the app.

What they are sent

Booking emails and notifications carry the client’s name, the service and the time. The copy of a reminder that goes to whoever the client is booked with adds the client’s phone number and, for a visit at the client’s home, the address.

A search that finds nobody offers to email you when somebody matching it is listed. For that we are the controller, and the only reason we hold anything is that you asked: the legal basis is your consent, given when you press the button in the confirmation email. Until then nothing but that one email is sent.

What is kept

Your email address, the search the alert is for — the trade, the distance, and the place as it was named (“Hackney”) — and the point searched from, rounded to about 100 metres.

What it is used for

Emailing you when a matching place is listed, and nothing else. It is not a mailing list, and the address is never given to the shops.

How long

An alert nobody confirms is deleted after seven days. A confirmed one is deleted 12 months after it was made, or at once when you press “Stop this alert”, which is in every alert email.

What stays behind

Our log of emails sent records alert emails without the address, under a scrambled code that only our own secret key can match to an address. The same code keeps count of sign-ups for a day, so the form cannot be used to flood somebody’s inbox.

When somebody signs a shop up, we keep a note of the link that brought them, if it was one of ours with a label on it: the page they pressed Start on, the name of a campaign we posted, or the invite link of another professional who sent them. We are the controller for this, and the reason is our own legitimate interest in knowing which of the places we tell people about Wunderhand actually lead to shops — and, for an invite, in giving both professionals the free month the invite promises.

What is kept

Against the shop’s account: the label on the link (for example “pros-mobile”, or a campaign name), the page first landed on, when, and the invite code if there was one, with which shop it belongs to.

What it is not

Nothing about anybody who does not sign up is kept on our side. There is no identifier for your browser, no record of the pages you read, and nothing is sent to anybody else.

Invites

A shop that invited you can see your shop’s name in its list of who joined through its link, whether you are on your free trial or paying, and whether its free month for inviting you has been credited. It is not shown what you pay, who works with you, your clients or anything else about your shop. If the shop switches its link off, a sign-up with it is not counted as an invite.

How long

For as long as the shop has an account with us, like the rest of the account’s records.

Card details. Payment is handled entirely by Stripe. A deposit goes directly into the shop’s own Stripe account, in the shop’s own name — we are not in the middle of it, we never hold the money, and no card number, expiry or security code ever touches our servers or our database.

Passwords. Stored as a hash and never in a form we can read. The same goes for the link in a booking email: only a hash of it is kept, so somebody reading our database cannot use one to open a booking.

Only the companies that run parts of the service, each doing one job:

Stripe

Payments, deposits and refunds, and the shop’s own subscription. Holds card details; we do not.

Resend

Sends confirmations, reminders, password resets and alerts, and receives replies to them.

Neon

The database everything is stored in.

Vercel

Runs the site and serves every page.

Backblaze

Stores the photographs a shop uploads, and the films on our own pages, which are played straight from it. That tells Backblaze the viewer’s IP address; a film sets no cookies.

Apple and Google

When somebody in a shop uses the app, a notification about a booking — the client’s name, the service and the time — is handed to Apple’s Push Notification service for an iPhone, or to Google’s Firebase Cloud Messaging for an Android phone, to deliver to that phone. Nothing is sent to either for anybody who does not use the app.

Google Fonts

The typeface on these pages is fetched from Google when the page loads, which tells Google the reader’s IP address. Nothing else is sent to Google.

OpenStreetMap

Where a page shows a map — a shop’s booking page, or the search results — the map pictures are fetched from the OpenStreetMap Foundation, in the UK, when the page is viewed. That tells them the reader’s IP address and which area of the map was shown. Nothing else is sent to them.

postcodes.io

When you search, what you typed into the box — a postcode or a place name — is sent from our server to postcodes.io, a free service run by Ideal Postcodes in the UK, to find it on the map. With “Near me”, your position is rounded to about 100 metres in your browser, and that rounded point is sent the same way to find the name of the area. The request comes from our server, so it carries neither your IP address nor anything that says who you are.

Nothing is sold. Two more companies see something only if you have said yes to them on the cookie bar, and nothing before:

Google Analytics

Only with a yes to “Measuring the site”. Which of our pages were read, in what order, and where the visit came from, against a random ID in a cookie. IP addresses are shortened before Google keeps anything. Never on a shop’s booking page, and never inside the app.

Meta

Only with a yes to “Measuring our adverts”. That a page of ours was viewed and, if you then sign up or start a trial, that you did — so we can tell whether an advert on Facebook or Instagram was worth running. Without that yes Meta learns neither. The sign-up and the trial start are also sent from our server, so an ad blocker does not hide them from the count: with them go your email address and account number, both scrambled one way (hashed) before they leave us, and your IP address and browser, which Meta uses to match the event to its own records. We use it only to judge our adverts and build no audiences from it. It never runs on a shop’s booking page or inside the app.

Say no, or say nothing, and neither is loaded — not switched off, absent from the page.

Six of our own, none of them for analytics or advertising, and Stripe’s on the page where a client pays. Each is needed for the thing you are doing at the time, so none asks first. Then the ones that are for analytics or advertising, which need your yes.

Signed in

Set when you sign in, and what keeps you signed in. Nobody who is only reading or booking gets it.

Which link

Set only when you arrive at one of our pages by a link with a label on it — a campaign link we posted, or an invite from another professional. (The Start buttons on our own pages carry their label in the sign-up form instead, and set nothing.) It holds that label, the page you landed on and when, so that if you sign a shop up we can note where you came from, as described above. It lasts 30 days, is cleared as soon as you sign up, cannot be read by scripts on the page, and is never sent anywhere but back to us. Arrive any other way and it is not set at all.

Your choices

Set when you answer the cookie bar, and holds only the answer — which of the purposes below you said yes to, and when — so you are not asked again. Lasts a year, or until the question changes, or until you press the button below. Cannot be read by scripts on the page.

Saved (wh_flash)

Set inside the app when you save something, so the next screen can say “Saved” once. Holds only that message, lasts 60 seconds and is cleared as soon as it is shown. The page’s own script reads it to show the message; it holds nothing about you.

Where (wh_place)

Set during a booking when you choose between a visit at home and going to the shop, and holds that choice and the postcode you gave, so the last step can use them without putting your postcode in the address bar. Lasts 30 minutes and cannot be read by scripts on the page. When the booking page is shown inside a shop’s own website, this is a third-party cookie kept for that website alone (partitioned); a browser that refuses it just asks for the postcode again.

Offer links (offer_links)

Set inside the app when a shop offers a free slot to its waiting list, and holds the one-off links to that offer for a moment, so the professional can copy one into a text message. Lasts ten minutes and cannot be read by scripts on the page.

Stripe (__stripe_mid, __stripe_sid)

Set by Stripe on the page where a client pays a deposit or the full price, to prevent fraud. __stripe_mid lasts a year and __stripe_sid 30 minutes. They are Stripe’s, under Stripe’s privacy policy, and are not used for advertising.

With a yes, and only then, these are set by the company named. Each is asked for separately, and “Only what’s needed” sets none of them.

Measuring the site

Which pages people read and where they came from, so we know what is worth writing. Cookies from Google Analytics, lasting up to two years.

Measuring our adverts

Whether somebody who saw one of our adverts went on to sign up or start a trial. Nothing about you is used to show you adverts elsewhere. Cookies from Meta (Facebook and Instagram), lasting up to three months.

Booking links

The link in a confirmation or reminder email stops working after 30 days. For a repeating appointment, each date’s link lasts until the day after that appointment if that is later than 30 days, so a date months away still has a working link. A link offering a slot from a waiting list stops working after one day.

Health answers

Kept until the retention date the shop set, then deleted outright — not flagged as deleted.

Appointments

Kept while the shop is a customer, because they are the shop’s own trading records and its takings depend on them.

A closed shop

When an owner closes their shop, its plan is cancelled that day and everything it holds — clients, appointments, takings, consent forms and health answers — is deleted thirty days later. Until then it stays readable so the shop can export it, and can be reopened by asking.

A deleted login

Deleted at once: the email, the password and every signed-in session. The person’s name stays against their past appointments in the shop’s books, as it would for anybody who left.

Email delivery log

Every send attempt and whether it worked, so “no email arrived” is a question with an answer. Recipient address and subject, not the message — except for alert emails, which are recorded without the address.

Alerts

Unconfirmed, seven days. Confirmed, 12 months from when it was made, or until you stop it.

You can ask for a copy of what is held about you, ask for it to be corrected, ask for it to be deleted, object to how it is being used, and complain to the Information Commissioner’s Office. Where the data belongs to a shop’s clients, those requests go to the shop, and we help the shop answer them.

Two of these are buttons. Anyone who signs in can delete their own login from Shop → Your login, and an owner can close their shop from Shop → Close this shop; both ask for the password again, and the section above says what each deletes and when.

The limit, stated plainly. Removing a client from a shop’s list marks the record as deleted and hides it, rather than erasing it — their past appointments are part of the shop’s own accounts. A genuine erasure request from a client has to reach the consent and health records as well, and today that is done by hand rather than by a button. Health records already delete properly. Ask at legal@wunderhand.com and it will be done; we would rather say that than imply a button exists that does not.

The database and the servers that run the site are in the European Union. Stripe, Resend, Backblaze, Apple, Google and the OpenStreetMap Foundation are each their own companies with their own arrangements for moving data outside the UK and the EU, and each publishes them.

This wording took effect on 26 September 2026. If it changes in a way that matters, shops are told before it takes effect.