Data Processing Agreement

This agreement is between Lazy Objects Firm, A1, Joharipur, Kanhaiya Vihar, Delhi 110094, India (GSTIN 07CYGPP9646D2Z0), trading as 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. 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.

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, and phone number where the Controller supplies it;
• 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.

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. 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 privacy page 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 phone number and store customer id, delete all sessions and sign-in tokens, and mark the member deleted.

5.4 Reward ledger entries remain after erasure, in a form that no longer identifies anyone. They record that a transaction happened and what it was worth, and deleting them would corrupt your programme's accounts. Keeping your own accounting records for the period tax law requires 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.

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, unless you reinstall first. A programme not connected through Shopify is deleted when you ask us to. 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.

9.1 The service runs on infrastructure in Mumbai, India. The only routine transfer of personal data outside India is transactional email, sent through the provider named on the sub-processors page.

9.2 The service is offered only to Controllers established in India and the United States. We do not offer it to Controllers established in the European Economic Area or the United Kingdom, and this agreement does not include the EU Standard Contractual Clauses.

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.

Access control and isolation

• Row-level security in the database on every tenant table: isolation is enforced by the database, not by application code remembering to filter, and automated tests assert one tenant cannot read another's rows.
• The application connects as a least-privilege database role, which cannot change or delete audit records.
• API keys are stored hashed, and the tenant is derived from the key itself, never from an identifier the caller supplies.
• Merchant sign-in is by a one-time emailed code; no passwords are stored. Platform staff sign in separately with a second factor.
• Role-based permissions, with maker-checker approval available for balance adjustments.

Integrity

• The reward ledger is append-only, enforced by a database trigger: entries cannot be amended or removed, only corrected by a further entry.
• Balances are derived from the ledger and reconcile exactly against a full replay.
• Processing is idempotent; replayed or duplicated events cannot credit twice.
• Every configuration change and manual adjustment is written to an append-only audit log with who made it and when.

Encryption

• TLS 1.2 or 1.3 only in transit, with HSTS.
• Third-party access tokens encrypted at rest with AES-256-GCM.
• Sign-in codes and tokens stored as hashes, and single-use.
• Database backups encrypted before they leave the server; the decryption key is held offline, and production refuses to write an unencrypted backup.

Application security

• A strict Content-Security-Policy with per-request nonces, framing refused outside the Shopify admin, and cross-origin isolation 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

• Nightly encrypted off-site backups.
• Structured logging, an operations dashboard, dead-letter queues with replay, and email alerts to operators within minutes of a fault.
• Automated reconciliation that recovers missed store events.

Organisational

• A documented threat model and a recorded log of every security-relevant design decision.
• Changes go through version-controlled review and an automated test suite that must pass before deployment.