Privacy

StickyTier sits between two kinds of people, and our obligations differ for each.

• Shoppers enrolled in a merchant's loyalty programme. The merchant decides why and how that data is used; we only process it on their instructions. In data-protection terms the merchant is the controller and we are the processor. If you are a shopper, the merchant you bought from is who your rights run against first — though we will always help them answer you.
• Merchant staff who sign in to stickytier.com. Here we decide the purpose ourselves, so we are the controller. That is what most of this page is about.

Our application and database run on servers in Mumbai, India. Encrypted backups are stored with Cloudflare, and transactional email is sent through Resend in the United States. The full list, with what each one touches, is on the sub-processors page.

StickyTier serves merchants established in India and the United States. We do not currently offer the service to merchants established in the European Economic Area or the United Kingdom, because we have not put the transfer safeguards in place that hosting EEA personal data in India would require. We would rather say that plainly than imply a protection we have not built.

• Your email address, because it is how you sign in — we send a six-digit code rather than storing a password.
• Your name, if you set one, so colleagues can tell who made a change.
• What you did in the admin. Every configuration change and manual adjustment is written to an append-only audit log with who did it and when. This is deliberate and we cannot switch it off for you: it is what makes a reward ledger something a finance team can rely on.
• Operational logs — errors and request diagnostics, kept for 90 days.

We do not collect anything for advertising. There is no analytics or tracking product embedded in stickytier.com or in the member portal, and we do not sell, rent or share personal data with anyone for their own purposes.

When a merchant connects a store, we receive the data their programme needs to work: customer email and phone, order totals and line items, refunds and cancellations, and the reward activity we derive from those. We use it to run that merchant's programme and for nothing else. We do not combine data across merchants — there is no cross-merchant profile of any shopper, by design.

stickytier.com sets no cookies until you sign in. Browsing the marketing pages sets nothing at all, and there are no advertising, analytics or third-party cookies anywhere in the product. Because everything we set is strictly necessary to deliver a service you asked for, there is no consent banner to click through.

Ledger and order records outlive the rest because tax and accounting rules require transaction records to be kept. After a shopper is erased those records no longer identify them — see below.

When a merchant asks us to erase a shopper, or Shopify sends us a redaction request, we replace the email address, clear the phone number and store customer id, and delete every session and sign-in token. The state is marked deleted and the person can no longer be identified from what remains.

The financial ledger entries stay. They record that a transaction happened and what it was worth, which we are required to retain — but once the identifiers are gone they are no longer personal data about anyone. Deleting them would also corrupt the merchant's accounts, which helps nobody.

Shoppers can see and export everything held about them from the privacy page of the merchant's member portal, without asking anyone — that export includes the member record, consent history, full ledger, orders and redemptions. Marketing consent is a switch on the same page and is off unless it is turned on.

Merchant staff can ask us for a copy of their own data, ask us to correct it, or ask us to delete their account. Write to privacy@stickytier.com and we will respond within 30 days. If you are a shopper and you write to us directly, we will pass your request to the merchant who holds the relationship, and tell you we have done so.

• Every tenant's data is isolated at the database with row-level security, not by application code remembering to filter.
• The reward ledger is append-only, enforced by the database itself — entries cannot be edited or deleted, only corrected by a further entry.
• Third-party access tokens are encrypted at rest with AES-256-GCM.
• Backups are encrypted before they leave our server, with the private key held offline.
• Traffic is TLS 1.3 with HSTS, and the application sets a strict Content-Security-Policy.
• Every configuration change and manual adjustment is audited and cannot be silently reversed.

If you believe you have found a security issue, write to security@stickytier.com. We will acknowledge you.

If a breach affects data we process for a merchant, we will notify that merchant without undue delay once we are aware, with what we know, what we are doing, and what we recommend they do. As processor it is the merchant who decides whether their own customers and regulator must be told; we will give them what they need to make that call.

If we change this policy materially we will update the effective date above and tell signed-in merchants before it takes effect. We will not change it retroactively to cover something we already did.

[REGISTERED COMPANY NAME], [REGISTERED ADDRESS]. Questions about this policy: privacy@stickytier.com.