Security

• Tenant isolation in the database. 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 new entries. A correction is made as a new entry rather than by editing an earlier one; 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.
• Encryption, and where it stops. 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. Retention periods are in our privacy policy.
• No passwords for merchants or shoppers. Merchants sign in with a one-time emailed code or through their Shopify admin, and shoppers with a one-time code sent by email; we store no passwords, and guessing is rate-limited. Platform staff sign in with an emailed code and an authenticator app. We do hold other credentials, and protect them: API keys are stored only as hashes, and Shopify access tokens are encrypted.
• Hardened web layer. A strict Content-Security-Policy with per-request nonces on every page except the embedded Shopify dashboard, which is prerendered and loads only our own scripts and Shopify's App Bridge; framing refused everywhere except inside the Shopify admin, and signed, constant-time-verified webhooks in both directions.
• An audit trail, and its limits. 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.
• Hosting. The service runs in Mumbai, India; the third parties involved are listed on the sub-processors page.

How we handle personal data is set out in our privacy policy and, for merchants, the Data Processing Agreement.

We keep a written incident response procedure and review it every year and after every incident. In short:

• Detect. Automated alerts reach our operator when services fail, backups fail or are missing, disks fill up or certificates near expiry, and an external uptime check watches the site. Reports to security@stickytier.com go straight to the operator.
• Contain and recover. We can suspend a programme, revoke sessions and API keys, rotate secrets and roll back a release within minutes, and we preserve logs and evidence before cleaning up.
• Tell the people affected. If a breach affects personal data we process for a merchant, we notify that merchant without undue delay and in any case within 72 hours of becoming aware of it, with what we know and in stages if needed — the commitment in our Data Processing Agreement. We report cyber incidents to CERT-In within the six hours Indian law requires, notify the Data Protection Board of India and affected people where we are responsible for the data, and inform Shopify where Shopify data is involved.
• Learn from it. Every incident ends with a written review and the changes it calls for.

If you believe you have found a security issue in StickyTier, please email security@stickytier.com with what you found, how to reproduce it, and what it could affect. We will acknowledge your report, keep you updated while we investigate, and tell you when it is fixed.

While you investigate, please:

• only test against your own account or store, never another merchant's programme or members;
• not access, change or keep data that is not yours, and stop as soon as you reach any;
• not run denial-of-service, spam or social-engineering tests against us, our merchants or their customers;
• give us a reasonable time to fix the issue before telling anyone else.

We do not currently run a paid bug bounty, but we are grateful for every report made in good faith.

Our security.txt has the same contact in machine-readable form.