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. Our commitments to merchants as processor are in the Data Processing Agreement.
• 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. Personal data leaves India routinely in four ways:

• Transactional email — the recipient's address and the message — is sent through Resend: Japan (AWS Tokyo region); Resend, Inc. is based in the United States.
• Encrypted database backups are stored in Cloudflare R2, which is global storage. They are encrypted on our server before upload, so Cloudflare holds data it cannot read.
• Email people send to our @stickytier.com addresses passes through Cloudflare Email Routing (global) to our mailbox with Google (Gmail) (United States and other countries where Google operates), which also receives our operational alerts.
• The database's own logs, which may contain personal data from the database, are stored by Supabase, our database host, in data centres in the EU.

Data we send back to a merchant's Shopify store to apply a reward — a discount code or store credit against a customer — is held by Shopify under the merchant's own agreement with Shopify. The full list of sub-processors, with what each one touches, is on the sub-processors page.

Intentstack is offered to merchants based in India and the United States. We do not currently offer it to merchants based elsewhere.

• 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. Changes to programme rules, tiers, rewards, plans, settings, API keys and team access, and manual adjustments, are written to an audit log with the user or API key that made them, where one applies, and when. What is and is not logged, and the limits of that log, are set out under “How we protect it” below. When a person is erased, their identifying details are redacted from the log; the whole log is deleted with the programme.
• Web requests. When you or a shopper visit our sites or a merchant's rewards page, our web server logs the IP address, time, page address (without its query string), browser and result of each request. These logs are kept for a rolling period of 180 days on our server in India, as India's CERT-In Directions (2022) require, and then deleted.
• Operational logs — errors and request diagnostics, kept for 90 days.
• Your acceptance of our terms. When you choose or change a plan, or accept an update notice, we record who accepted (your email address, or your Shopify staff account id when you accept in the Shopify admin), when, which version of our documents, and the IP address and browser used where available — the evidence of our contract with your business. See “How long we keep things” below.

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.

From Shopify. When a merchant connects a Shopify store, we receive the data their programme needs: from customers, the Shopify customer id, email address and name; from orders, totals, line items, tags, refunds and cancellations, and the reward activity we derive from those. We do not read phone numbers from Shopify. We never keep a shopper's addresses, order notes, or the IP address or browser details Shopify sends; these are dropped when each notification is stored. Name and email stay on our stored copy of a notification until it is processed successfully, then are removed; a notification that fails keeps them until it is deleted (see “How long we keep things”).

From the merchant or the shopper. A phone number, and other details, can also reach us because the merchant's own system sends them through our API, because the merchant imports them from a file, or because a shopper types them in when joining. A phone number is optional, is never used to send SMS, and counts as part of the member's identity within that one programme. A small number of older records may hold a phone number that came from Shopify before 4 October 2026; they are erased in the same ways as any other.

We use all of 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.

What we compute (profiling). Inside one merchant's programme, two things are worked out automatically. Tier: from the shopper's orders under the rules the merchant publishes; the merchant can override it. Referral checks: when one member refers another, we check whether the two appear to be the same person (the same email after folding aliases, or the same phone), whether the referrer has made five or more referrals in a day, and whether the referrer's refunds are half or more of their order value across at least three orders. A referral that trips a check is held for the merchant's staff to approve or reject; it is not rejected automatically. Points earned on an order are taken back automatically if the order is refunded or cancelled. We do not use any of this for advertising.

Automated decisions. A member's loyalty tier is worked out automatically from their order history using the thresholds the programme publishes. Referral rewards may be placed on hold automatically when our checks find signs of misuse (for example a member referring themselves or an unusually high number in a day). A held referral is only ever refused after a person at the programme reviews it. These steps affect loyalty perks and rewards only; they do not affect a shopper's ability to buy, their prices outside the programme, or their legal rights. A shopper who thinks their tier or a referral is wrong, or wants a person to look again, can write to the contact in the programme's privacy notice, and a person at the programme will review it and reply.

An order on its own does not make someone a member. It creates a record (email address, name, Shopify customer id) so points can be credited if they join, and that person receives no programme email. A shopper becomes a member in one of three ways. Each records when it happened, how, and a version identifier for the merchant's terms and privacy text in force at that moment:

• Emailed link. They ask for a link on the rewards page, open it, and press the button on the page it opens. Opening the link alone does nothing.
• Store sign-in. A shopper already signed in to the merchant's store presses a join button on the rewards page, directly under the merchant's terms notice.
• The merchant's own system, through our API. The merchant's system tells us to enrol the person. We record the terms version the merchant tells us the person accepted; if the merchant sends none, no acceptance is recorded for that enrolment. The merchant is responsible for obtaining the person's agreement before it does this.

Joining is open only after the merchant has published its terms and privacy text.

If you buy from a store that runs a StickyTier programme but have not joined, we keep your email address, phone number and Shopify customer id for that store, as its processor, only so that points you earned can be credited if you join. We do not email you or use your details for marketing. We delete them after 365 days without activity if you hold no unclaimed points. If you hold unclaimed points, we delete them once those points have expired and 365 days have passed without activity (or after 365 days without activity if the programme's points do not expire). Whatever you hold, we delete them after 730 days without activity. Both periods run from your last activity (an order, points earned, spent or adjusted, a referral, a referral-link click, a sign-in link, or a redemption in progress), so new activity restarts them; there is no maximum period counted from your first order. Deleting your details also ends your claim to any unclaimed points and deletes your order and points history. You can ask the store to delete them sooner.

The cookies we set are listed below. Some are set before you sign in: the sign-in form sets one for ten minutes, and connecting a Shopify store sets one. Following a referral link stores nothing on your device: the referral is carried through the join itself. The marketing pages set no cookies, and there are no advertising, analytics or third-party cookies anywhere in the product.

The appearance cookie is set only if you choose dark mode. Switching back to light mode deletes it. The admin also remembers, in your browser's local storage, whether you left the “Advanced” menu section open.

Ledger and order records outlive the rest because the merchant's reward balances, liabilities and reports are built from them, and the merchant instructs us to keep the programme's ledger for the life of the programme. When a shopper is erased, their own ledger and order records are deleted — see below. A shopper who ordered but never joined is erased on the schedule in the table above, and any points they never claimed lapse then.

When a merchant leaves. Once a merchant's Shopify store uninstalls StickyTier, every member's personal data in that programme is erased 30 days later — email, phone, birthday, store customer id and sessions, along with the stored order payloads, imports and exports that carry copies of them. Their order and points history is deleted at the same time, and the programme itself is deleted 90 days after uninstalling. Reinstalling before day 30, when Shopify has not sent a store redaction request (shop/redact), resumes the programme. A store redaction request that Shopify has sent stays due even if the store reinstalls. A request to erase an individual customer is completed within 30 days of receipt, and also stays due after a reinstall. Our policy for a programme not connected through Shopify is to delete it 12 months after its subscription ended, if no one has signed in since, after we have emailed two warnings. Automatic deletion is not running yet. Until it is, such a programme is deleted when the merchant asks us to. Export remains available meanwhile.

When a merchant asks us to erase a shopper, or Shopify sends us a redaction request, we replace the email address, clear the name, phone number, birthday and store customer id, and delete every session and sign-in link. The member record itself is kept as an empty record, marked erased and without those details, so that the person stays erased. We do this when the request is processed, normally within minutes of receiving it, and track every Shopify request against a deadline of 30 days from receipt. We also remove the shopper's details from every stored copy we hold — store notifications, API events, webhook deliveries and cached API responses — including ones that failed or were never processed. That clean-up runs in the background and normally finishes within minutes; if it fails we are alerted and it is retried, and those copies are deleted on the schedule below in any case. Once it has run, what remains no longer contains their name, email or phone number.

Their order and points history is deleted. In the same step we delete their orders, points entries, redemptions, reservations, recovery cases, tier, balance and referral links on either side. A member they referred, or who referred them, and who has not been erased keeps the reward they earned, without the link to the erased person. We keep no monthly or other totals of their history in its place: their figures leave the merchant's reports with them, and the monthly totals that earlier erasures left behind have been deleted. For a new erasure, the placeholder we leave in place of the email on the empty member record is built from a random identifier, not from the email. Records erased before we made this change were converted to a random placeholder on 20 October 2026, so every erased member record now carries one. The identifiers those records carried before were handed to the same background clean-up, which removes them from the stored copies above. We therefore keep treating these remains as personal data where the law says so, and delete them with the programme.

What an erasure does not reach, and when it goes:

• Server logs (web access log with the visitor's IP address, and application logs): kept for a rolling period of 180 days on our server in India, as India's CERT-In Directions (2022) require, and then deleted. They are not edited when a person is erased, because they are kept unaltered as the security record those Directions require. Application and server logs may contain customer email addresses. Only the operators who administer our server can read them. Since 19 October 2026 the database's own logs are kept by Supabase, our database host, in data centres in the EU, under its own retention period, which we do not set.
• Our backups: hourly and nightly copies of the database, decrypted only to recover from a disaster. Our backups are encrypted with age on our server before they are written or uploaded. The private key is kept only on the operator's own device, in a password manager that is not synced to any cloud service, with a second copy kept offline; it is never on our servers. Each backup is deleted when its 35-day period ends. Erased data can remain in a backup until the backup expires: 7 days (nightly) and 48 hours (hourly) on our server. Offsite copies in Cloudflare R2 are deleted 35 days after upload and are locked against deletion for the first 30 days.
• Supabase's backups: Separately, Supabase takes a daily backup of the database and keeps each one for 7 days, the retention Supabase states for our plan; there is no continuous, minute-by-minute backup. Erased data can remain in them until they expire.
• Restoring a backup: After any restore, from our own backups or from Supabase's, we stop the application and job worker first, and re-apply every erasure recorded since the backup was taken before they resume processing. A restore fence keeps them from starting until the restored database has caught up with an encrypted record of erasures that we keep off our server and update every minute; an erasure made in the last minute before our server was lost may not yet be in that record.
• Retired database copy: The database previously hosted on our own server was copied to Supabase on 19 October 2026, kept read-only as a rollback copy, and was deleted on 22 October 2026.
• Notes typed by merchant staff in free-text fields: notes on the erased person's own records are cleared, and notes elsewhere in the programme that name them by email address, mobile number, full name or first name are redacted; a first name is left on the record of a member who shares it, as the note is taken to be about them. A note that identifies them some other way, for example by a nickname, is not found and stays as written until we are told of it: then we search the programme's notes for it and redact every note naming it, within 30 days of the request. Merchants should not put customer contact details in notes.
• Import files a merchant uploaded (balance and order imports): the key we derived from each person's email address for a balance import is replaced on erasure. A file whose import has finished is deleted. Any other file we still hold (a preview, an import waiting for approval, or one stopped part-way or failed) is rewritten: the erased person's own records are blanked, and mentions of their email address or mobile number elsewhere in it are redacted. A mention that identifies them some other way, for example by name in a free-text column, is not found and stays. A file that cannot be read as a table and names them is deleted. Copies a merchant keeps of their own files are outside our control.
• Reward codes: an erased person's unused reward and friend codes are deactivated in the merchant's Shopify store. When we cannot do that (the store is not connected, or Shopify refuses), we ask the merchant to delete the code in Shopify and track it until it is done, within 30 days of the erasure.
• Export files: an erasure does not change an export file already made. Files still on our server are deleted on the schedule in the table above; files a merchant has downloaded are outside our control.

Shoppers can see and export everything held about them from the Account screen 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 screen and is off unless it is turned on. While a merchant's programme is paused its portal is unavailable; ask the merchant, or write to privacy@stickytier.com, and the data is provided from the merchant's export.

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.

India's Digital Personal Data Protection Act, 2023 calls the person who decides why and how data is processed the Data Fiduciary. For merchants' own customer data, the merchant is the Data Fiduciary and Lazy Objects Private Limited is the processor. For merchant and staff account data, Lazy Objects Private Limited is the Data Fiduciary. As of 12 October 2026 the DPDP Act's main obligations and individual rights have not come into force; the main provisions are scheduled for May 2027. Until then, the rights below are commitments we make voluntarily as part of our service. When the relevant provisions commence, the corresponding statutory rights will apply as well. The IT Act and the SPDI Rules 2011, which apply today, continue to apply.

We commit to give you:

• Access — we will give you a summary of the personal data we process about you and what we do with it, and who else we have shared it with (our sub-processors are listed on the sub-processors page). Shoppers can download everything a programme holds about them themselves, from the Account screen of the merchant's member portal.
• Correction and erasure — we will correct, complete or update inaccurate or incomplete data, and erase data once it is no longer needed. What survives erasure, and why, is explained under “Erasure, and what survives it” above.
• Withdrawal of consent — we will let you withdraw consent where processing relies on it. A shopper's marketing consent is a switch on the Account screen of the member portal, and withdrawing it is as easy as giving it.
• A complaint route — we will have our Grievance Officer, below, answer your complaint.
• Nomination — we will let you nominate another individual to exercise these rights on your behalf if you die or become unable to. Tell us your nominee's name and email address and we will record it.

How to exercise them. Write to privacy@stickytier.com from the address the request concerns (or say how we can confirm it is you), and tell us which right you are using. We respond within 30 days, and there is no charge.

If you have a complaint about how we handle personal data, or about a request you have made, contact our Grievance Officer:

• Saurabh Pushkar, Grievance Officer, Lazy Objects Private Limited, brand Intentstack
• Email: saurabh@stickytier.com
• Post: 58, Jyoti Nivas College Rd, KHB Colony, 5th Block, Koramangala, Bengaluru, Karnataka 560095, India

We acknowledge a grievance promptly and respond within 30 days. Once the DPDP Act's complaint provisions are in force, you may also complain to the Data Protection Board of India.

This officer is also our Grievance Officer for the purposes of Rule 5(9) of the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.

• The application connects to the database with two limited roles. Merchant-facing access uses one that row-level security on tenant tables limits to the programme in context; some platform functions (store webhook intake, billing, offboarding, the staff console and administrative routes) use a separate platform role that is not subject to row-level security. Privileged access also exists outside the application: the database owner role, used only for schema migrations and maintenance; Supabase's administration of its own platform, as our database host; and our operator's administration of our server.
• Ledger corrections are made as new entries rather than by editing earlier ones; the only other changes are authorised processes: removing personal identifiers on erasure, deleting a whole programme on offboarding or at your request, and clearing test-mode sandboxes. An entry's status moves through a fixed lifecycle.
• In transit: traffic from browsers, Shopify and API clients to us is HTTPS only (TLS 1.2 or higher, with HSTS). Our calls to Shopify, outbound merchant webhooks and offsite backup storage use TLS. Email to our provider requires STARTTLS with TLS 1.2 or higher. Connections from our server to our database, hosted by Supabase, use TLS with the database server's certificate verified. Traffic between our own services on our single application server (such as the proxy, application and job queue) stays on host-only networks and is not separately encrypted. Resend delivers email to recipients under its own controls.
• At rest: the database is hosted by Supabase in Mumbai, India, and encrypted at rest by Supabase. The job queue and file uploads are stored on a LUKS2 encrypted volume on our server (AES-XTS, 512-bit key). The volume's key file is held on the server's system disk so the server can restart unattended; it protects against loss of the volume, not against someone who obtains a copy of the whole system disk. Shopify tokens are additionally encrypted with AES-256-GCM. Backups are encrypted before they leave the server.
• Not encrypted at rest: server and application logs (kept for a rolling 180 days), the web access log, and the container engine's storage, all on the system disk. These logs may contain customer email addresses and IP addresses.
• The application sets a strict Content-Security-Policy (the embedded Shopify dashboard, which is prerendered, uses a fixed policy that allows only our own scripts and Shopify's App Bridge).
• We log changes to rules, tiers, rewards, plans, settings, API keys and team access; manual point adjustments; exports downloaded; revealing masked member contact details in the merchant admin; and staff console actions. We also log every read of member contact details by merchant staff or an API key, in the merchant admin, inside the Shopify admin and through the API: one record per request, with who made it (the staff user or API key, or the Shopify user where Shopify identifies one), when, the programme, the member where a single member is read, and the page or API route. Our staff console has no screen that shows member contact details. API reads of points ledgers, which carry no contact details, are not individually logged. Audit records are protected against alteration through our application: the database refuses changes to, and deletion of, the point-adjustment, configuration and staff-activity logs, and we have confirmed these protections on the live database. The database owner account and the administrator (root) of our server could still alter records outside the application, including by switching these protections off; use of that access through our operations workflow is recorded in its own audit trail, and our weekly review checks that the protections are in place. We review these logs every week under a documented procedure: they are reviewed weekly by the operator, with AI-assisted analysis, and we handle any suspected unauthorised access under our incident response plan.

More on our security page. 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, email each merchant account's owner and show a notice in StickyTier at least 30 days before it takes effect. We will not change it retroactively to cover something we already did.

StickyTier is operated by Lazy Objects Private Limited, brand Intentstack, 58, Jyoti Nivas College Rd, KHB Colony, 5th Block, Koramangala, Bengaluru, Karnataka 560095, India. Questions about this policy: privacy@stickytier.com.