Data Processing Agreement

This agreement is between Lazy Objects Private Limited, brand Intentstack, 58, Jyoti Nivas College Rd, KHB Colony, 5th Block, Koramangala, Bengaluru, Karnataka 560095, India (CIN U52601KA2021PTC156153), the provider of StickyTier (the “Processor”, “we”), and the business identified in the account registration (the “Controller”, “you”).

It forms part of, and is governed by, the terms of service. Where they conflict on the processing of personal data, this agreement prevails. If you need a countersigned copy for your records, write to privacy@stickytier.com.

“Data protection law” means the law that applies to the processing, including India's Digital Personal Data Protection Act, 2023, to the extent its provisions are in force. Under that Act you are the Data Fiduciary and we are your Data Processor; this agreement uses “Controller” and “Processor” for the same roles.

1.1 You are the Controller of the personal data of the shoppers enrolled in your loyalty programme. You decide why and how it is processed.

1.2 We are the Processor. We process that personal data only to provide the service, and only on your documented instructions.

1.3 Your use of the service, your programme configuration and this agreement together are your documented instructions. If we believe an instruction breaches data protection law, we will tell you and may pause that processing rather than carry it out.

1.4 We act as an independent controller only for the account data of your staff who sign in (their email address, name and audit records). That is described in our privacy policy and is outside this agreement.

1.5 If you enrol a person through our API, you are responsible for obtaining and keeping their agreement to your programme terms first. A terms version is recorded only if you send one; if you send none, no acceptance is recorded for that enrolment. We do not verify any person's agreement. Acceptance of programme terms, delivery of your privacy notice and consent to particular processing are separate matters: the records we keep show which terms and privacy text versions applied, not consent.

1.6 Shoppers who order but have not joined (prospects). You are the Controller and we are your Processor for them too. We hold their details only so that points they earned can be credited if they join; we never email them and never use their details for marketing. Your own notice at checkout or in your privacy policy must tell them this. For a prospect created through our API, your notice is the only notice they get.

Data subjects: the Controller's customers who are, or become, members of the programme, and customers who place an order the programme evaluates.

Categories of personal data:

• contact identifiers — email address; name where the store platform or the Controller supplies it; and phone number only where the Controller supplies it (through the API, an import, or a member's own entry). We do not read phone numbers from the store platform;
• commerce identifiers — the store platform's customer id, order identifiers and numbers;
• transaction data — order totals, line items, refunds and cancellations;
• programme data — reward balances and ledger history, tier membership, referral relationships and redemption history;
• consent records — marketing consent state, its source, the version of the text agreed and when;
• optional profile data the member supplies themselves, such as a birthday.

Derived data: each member's tier and referral-check results (held or cleared), computed inside your programme only.

Sensitive data: none. The service is not designed to process health, financial account, biometric or other special-category data, and you must not configure it to. Data placed in a free-text field outside these instructions is at your own risk.

We will:

• (a) process personal data only on your documented instructions, including for transfers, unless a law we are subject to requires otherwise — in which case we will tell you first, unless that law forbids it;
• (b) ensure everyone authorised to process the data is bound by confidentiality;
• (c) implement the technical and organisational measures in Annex A;
• (d) follow section 4 when engaging sub-processors;
• (e) help you, so far as possible, to respond to requests from data subjects (section 5);
• (f) help you meet your own obligations on security, breach notification and impact assessments, taking into account the nature of the processing and the information available to us;
• (g) at your choice, return or delete the personal data at the end of the service, under section 8;
• (h) make available the information reasonably needed to show we comply with this agreement, and allow audits under section 7.

4.1 You give general written authorisation for us to engage sub-processors. The current list is published on the sub-processors page and forms part of this agreement.

4.2 We will give you at least 30 days' notice before adding or replacing a sub-processor, by email to your account's owner and a notice in StickyTier, and update the published list. You may object on reasonable data protection grounds within that period. If we cannot resolve your objection, you may terminate the affected part of the service without penalty, and export your data first.

4.3 We impose data protection obligations on each sub-processor no less protective than those in this agreement, and remain responsible to you for their performance.

5.1 Access and portability are self-service. A member can download everything held about them from the Account screen of your member portal without involving either of us: their member record, full consent history, complete reward ledger, orders and redemptions. While a programme is suspended its portal is paused, so you answer such requests from your own export, with our help if you need it.

5.2 Marketing consent is controlled by the member in the portal, timestamped, versioned against the consent text shown, and written to the audit log.

5.3 Erasure is available from the admin and is triggered automatically by your store platform's redaction request. On erasure we replace the email address, clear the name, phone number, birthday and store customer id, delete all sessions and sign-in tokens, and mark the member record as erased (direct identifiers removed). Free-text notes your team wrote on the person's own records are cleared, and notes elsewhere 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); a note that identifies them some other way, for example by a nickname, is not found, so avoid putting personal data in notes. The key we derived from the person's email address for a balance import is replaced. An import file you uploaded is deleted if its import has finished; any other is rewritten with the person's own records blanked and mentions of their email address or mobile number redacted, though a mention that identifies them some other way, for example by name in a free-text column, is not found. An export file already made is not changed. We also remove the data subject's contact details from every stored webhook, API event and webhook delivery payload that names them, whatever its processing state; that clean-up runs as a background job that normally finishes within minutes, is retried and alerted to us if it fails, and those copies are in any case deleted on the retention schedule.

5.4 On erasure, the person's order and points history is deleted. We delete their orders, reward ledger entries, redemptions, reservations, recovery cases, tier, balance and referral links on either side; a referral partner who is not erased keeps their reward. We keep no monthly or other totals of that history in its place: their figures leave your reports with them, and the monthly totals that earlier erasures left behind have been deleted. Keeping your own accounting records for the period the law requires of you is your responsibility; the finance export gives you what you need.

5.5 If a data subject contacts us directly, we will not answer the substance of the request. We will refer them to you and tell you promptly.

5.6 Human review of loyalty decisions. Tier placement and referral holds are worked out automatically, and our privacy policy tells members they can ask for a person at your programme to review them through the contact in your programme's privacy notice. You will monitor that contact, respond to such requests within the deadlines applicable law sets, and cooperate with us where a review needs information or action from us.

6.1 We will notify you without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting personal data we process for you.

6.2 The notice will describe, so far as we know it: the nature of the breach, the categories and approximate number of people and records affected, the likely consequences, what we have done or propose to do, and a contact point. Where we cannot give all of it at once, we will give it in stages without further undue delay.

6.3 Notifying regulators — including the Data Protection Board of India — and the people affected is your decision and responsibility as Controller. We will give you what you need to make it.

7.1 We will make available the information needed to demonstrate compliance, including a description of our security measures and this agreement.

7.2 You may audit no more than once in any 12-month period, on at least 30 days' written notice, during business hours, without unreasonable disruption and subject to confidentiality. You bear your own costs. A regulator exercising a statutory power is not subject to these limits.

8.1 You can export your programme's data at any time, including while the programme is suspended for want of a plan, until it is deleted under the off-boarding schedule. Export it before then if you want to keep a copy; that is how data is returned to you.

8.2 When your Shopify store uninstalls StickyTier, we erase every member's personal data 30 days later and delete the whole programme 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. You can also ask us to delete everything at once.

8.3 Operational records — stored order payloads, API event bodies, session records and error logs — are deleted on the automated schedule in our privacy policy, independently of termination. Server 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) and backups follow the periods in the privacy policy and are not edited when a person is erased. Application and server logs may contain customer email addresses. 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 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 it 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. 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. 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. 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. Stored order payloads are deleted 30 days after we receive them, whether processed or failed (twice that if still waiting).

9.1 The service runs on infrastructure in Mumbai, India. You authorise the following routine transfers of personal data outside India, each through a sub-processor named on the sub-processors page:

• 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.

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

9.3 If you are established outside India, you confirm that you have determined that having your data processed in India is lawful for you.

Each party's liability under this agreement is subject to the limitations and exclusions in the terms of service.

Every measure below is in place in the platform today. Where a measure is partial, this annex says so.

Access control and isolation

• Row-level security in the database on every tenant table, and automated tests assert one tenant cannot read another's rows.
• 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.
• API keys are stored hashed, and the tenant is derived from the key itself, never from an identifier the caller supplies.
• Merchants sign in with a one-time emailed code or through their Shopify admin; we store no passwords. Platform staff sign in with an emailed code and an authenticator app.
• Role-based permissions, with maker-checker approval available for balance adjustments.

Integrity

• 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.
• Balances are derived from the ledger and reconcile exactly against a full replay.
• Automated crediting (store order events, referrals, scheduled perks) is idempotent: each credit carries a unique key, so a replayed event is not credited twice. API callers get the same protection by sending an Idempotency-Key.

Logging of access

• 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.

Encryption

• 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.
• Sign-in codes and sign-in links are stored only as hashes and work once.
• Production refuses to write an unencrypted backup.

Application security

• 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 outside the Shopify admin, and cross-origin opener and resource policy headers.
• Outbound webhook destinations are checked against server-side request forgery, re-resolved immediately before each delivery.
• Inbound store webhooks are verified by HMAC over the raw body; signatures are compared in constant time.
• Rate limiting on sign-in, shared across application replicas.
• The application refuses to start with missing or weak secrets.

Resilience and monitoring

• Hourly and nightly encrypted off-site backups.
• Structured logging, an operations dashboard, failed jobs and deliveries kept for retry and redelivery, and email alerts to operators within minutes of a fault.
• Automated reconciliation that recovers missed store events.

Organisational

• A documented threat model and a decision log for security-relevant design choices.
• Changes go through version-controlled review, and the normal deployment path requires the automated test suite to pass.