Privacy Policy

When you sign up as a business owner, Kliyan is the data controller for your account: your name, your email address, your login credentials, your business details and your subscription record. We decide what we need in order to give you an account, bill you, keep the service secure and meet our own legal obligations.

The records you create *about your staff* are a different matter. When you add an employee — a name, sometimes an email address, a role and a working schedule — you are the controller of that record and Kliyan is your processor. We hold it because you told us to. You are responsible for telling your staff that their name and scan activity are recorded, and for having a lawful basis (normally the employment relationship, or your legitimate interest in preventing loyalty fraud) for doing so.

For everything relating to loyalty cards — the pass itself, the stamp history, and any name, email address or marketing consent a customer chose to provide — the Business User is the data controller and Kliyan is the processor. The shop decides to run a loyalty scheme, decides what it offers, and decides what to do with any contact details customers hand over. We supply the software.

This matters practically: if you are a customer and you want your data corrected or erased, the business that issued your card is the first place to ask. We will act on their instruction, and section 10 explains what we do if you come to us directly instead.

The processing terms that govern this relationship — the Article 28 clauses, the sub-processor list, the security measures and what happens at the end of the contract — are set out in section 8 of the Terms of Service, which forms our data processing agreement with each Business User.

We would rather tell you this plainly than bury it. The platform isolates every business's data at the database level, so no Business User can ever read another's records. That isolation does not, and technically cannot, apply to us.

A small number of named Kliyan personnel hold administrative credentials for the production database. Those credentials bypass the row-level isolation rules and can read and modify any record on the platform, including passes, stamp history and any customer contact details a business has collected. They exist because parts of the service genuinely require them — the public join page has to read a business by its QR slug before anyone is logged in, the stamping endpoint has to write to a pass on behalf of a scanner with no account, and the billing webhook has to update a subscription when nobody is signed in at all.

Human access to that data by Kliyan staff is restricted to what is necessary and happens only in these circumstances:

• You ask us for help. Investigating a support request you raised — a card that will not update, a stamp that did not register, a subscription in the wrong state.
• Security or integrity. Investigating suspected fraud, abuse of the notification system, or a security incident.
• Fixing a defect. Diagnosing a bug that is corrupting or losing data, where reproducing it on test data is not possible.
• Legal obligation. Responding to a binding, lawful order from a competent authority.

We do not browse customer lists out of curiosity, we do not use one business's customer data to benefit another, and we do not use it to build any product of our own. Personnel with these credentials are bound by confidentiality obligations that survive the end of their engagement.

Note that your logo file is publicly readable by URL. It has to be: it is rendered onto the wallet pass by Google and Apple, and onto the public join page anyone with your QR code can open. Do not upload anything to that field that you would not put on a poster in your window.

Employees do not have Kliyan accounts. They do not register, do not set a password, and cannot log in. A Business User creates a record for each member of staff, and the platform issues that record a long, unguessable scanner link. Possession of the link is the credential.

• Name — required, and shown on the scanner screen and in the activity log.
• Email address — optional; the platform does not send employees any email.
• Role label — set by the owner.
• Scanner token — a random secret embedded in the employee's scan URL.
• Availability controls — whether the link is active, whether it works around the clock, and if not, the start and end times during which it does.
• Scan activity — every stamp and redemption is recorded against the employee who performed it, with a timestamp.

Created automatically when you add a card:

• A random identifier for the card itself, and the business it belongs to.
• Your current stamp count.
• The date you added the card, and the date it was last updated.
• A device identifier — see section 3.4 — used solely to stop you ending up with two cards for the same shop.
• A wallet reference: the Google Wallet object identifier and/or Apple Wallet serial number for your pass, plus a secret token Apple uses to authenticate its own update requests.

Created every time you are served:

• A stamp record: which card, which shop, which member of staff, which stamp number it was, whether it completed the card, and the exact time. Taken together this is a timestamped history of your visits to that shop, and you should read it as such.
• If your card is registered for updates: your device's push token and platform, so the shop's stamps can reach your phone.

Only if you choose to provide it:

• Your name (up to 80 characters).
• Your email address.
• A marketing consent flag. It can only be set to yes if you also gave an email address, it defaults to no, and leaving it untouched is never treated as agreement.

If a business sends a wallet campaign, a short delivery record is kept for that card: whether the message was sent, skipped or failed, the reason, and when. Section 7 explains campaigns in full.

We deliberately keep this layer thin. There is no analytics package, no tag manager, no advertising pixel and no session-recording tool anywhere in the product.

• Device identifier. A random value, stored in a cookie we set (section 5) and, for cards created before we moved to cookies, sometimes in your browser's local storage. It is meaningless outside Kliyan, is not linked to any advertising profile, and does nothing except recognise that this device already holds a card for a given shop.
• Session data. When a Business User is signed in, authentication cookies maintain the session.
• Locale preference. Your chosen interface language, remembered so the site does not reset to English on every visit.
• Browser type, at request time only. The public join page reads your user agent to decide whether to offer the Apple Wallet or Google Wallet button. It is used to render that one page and is not written to our database.
• Server logs. Our hosting and database providers record standard technical logs — IP address, timestamp, request path, response status — for security, abuse prevention and debugging. These are held by those providers under our instructions for a short period.
• Wallet device logs. Apple Wallet posts device-side error reports to an endpoint we expose for that purpose. They are written to our server logs and used only to diagnose pass failures.

Our contact form does not transmit anything to us on its own: it opens your own email application with a message pre-filled, and whatever you then send reaches us as an ordinary email.

Today the platform sends Business Users only service email: confirm your email address, reset your password, and messages we send by hand in reply to support requests. Service email is part of running your account and cannot be switched off while the account is open — though you can of course close the account.

If we introduce product announcements, onboarding tips or offers, they will operate on these rules:

• If you are already a Kliyan customer, we may write to you about our own similar products and services on the basis of Article 21.2 LSSI-CE, because you gave us your address in the course of buying from us.
• If you are not a customer, we will only write to you if you have given us consent.
• Every commercial message will carry a working one-click unsubscribe, and a message identifying itself as advertising where the law requires it.
• Unsubscribing from marketing never affects service email or your subscription.
• We will not pass your address to anyone else for their own marketing.

When a member of staff scans your card, the pass in your wallet is updated and your phone may show that the stamp count changed or that your reward is now ready. This is the core function of the product and is triggered by something you did in the shop moments earlier.

On iOS this works in two hops that are worth understanding: Apple's push service is sent an empty notification, with no message and no content. Its only job is to wake your device, which then contacts Kliyan directly to fetch the updated pass. Apple therefore never sees the contents of the update.

A Business User can also send a wallet notification to a group of its own cardholders — for example, everyone who is one stamp away from a reward, or everyone who has not visited in a while. Cards are grouped by simple arithmetic on the stamp count and the date of the last visit; a customer counts as lapsed after 30 days without a visit.

Several limits are enforced by the platform rather than left to the sender's judgement:

• Content must be loyalty-relevant. Most plans can only send pre-written messages about stamp progress, a ready reward, a welcome, or a come-back nudge. Free-text messages are available on the highest plan only, and are validated before they go out.
• No more than 3 notifications reach any single card in any 24-hour period, whatever the sender does.
• A monthly campaign allowance applies per plan, so no business can send continuously.
• Unrelated advertising is not permitted. Using a wallet pass to push offers that have nothing to do with the loyalty card breaches Google's and Apple's policies and can get passes disabled — for the offending business and, because the issuer accounts are shared, potentially for others.
• A delivery record is kept for each card (sent, skipped or failed, and why), both for the sender's audit trail and to enforce the caps above.

Wallet notifications are controlled on your device, not by an account setting on our side — you never made an account with us, so there is nothing for us to switch off. You have complete control by these routes:

1. Turn off notifications for that pass. Both Google Wallet and Apple Wallet let you disable notifications for a single pass while keeping the card.
2. Remove the card from your wallet. This stops everything immediately. Section 9 explains exactly what happens next on each platform.
3. Ask the business that issued the card to stop sending you campaigns, or to delete your card.

A Business User sending campaigns is the controller of that communication and is responsible for it. By sending, the business confirms that it will:

• Send only messages relevant to the loyalty programme the customer joined, and never use passes as a channel for unrelated advertising.
• Comply with Google Wallet and Apple Wallet policies, and with applicable rules on commercial communications.
• Honour any request from its own customers to stop, and not attempt to defeat the platform's frequency caps.
• Not send anything misleading, offensive, or contrary to the reward it actually offers.
• Provide its own customers with a privacy notice covering its loyalty programme, and deal with their data-protection requests as controller.

We may suspend campaign sending, and in serious cases the account, where these obligations are breached. The reason is not merely contractual: the wallet issuer accounts are shared across the platform, so abuse by one business can degrade the service for every other business and every cardholder.

Section 2.3 explains that a small number of Kliyan personnel can access production data, including the customer records inside a Business User's account, and that we rely on legitimate interests to do so. Article 21 GDPR gives you the right to object to processing on that basis, and we treat that right as real rather than decorative.

A Business User may object by writing to hello@kliyan.app with the subject line Object to support access. On receipt we will:

1. Record the objection against your account.
2. Stop accessing your account's data for support, product-quality and non-urgent debugging purposes.
3. Contact you for explicit, case-by-case permission whenever a support request you raise cannot be resolved without looking at your data — and take no look until you give it.

What the objection cannot cover. Some access is not carried out on the legitimate-interests basis and therefore falls outside Article 21: access strictly necessary to operate the service under our contract with you (the automated processes that create passes, record stamps and update subscriptions), access needed to investigate a live security incident or suspected fraud, and access we are legally compelled to give. We will still tell you, where we lawfully can, if any of these applies to your account.