Legal

Security and incident response

Effective 7 September 2026 · Hatzlacha Management LLC

This page is the security policy for Affiliate Loop. It is public because a merchant deciding whether to route their programme through this app should be able to read the controls rather than be told they exist.

What the app can reach

Affiliate Loop asks Shopify for the narrowest set of scopes that lets it do its job: orders and their line items, so a sale can be attributed and a commission calculated; discount codes, so each affiliate can be given a personal one; products, so per-product rates can be set. It does not request payment data, and Shopify never exposes card details to an app of this kind in any case.

Of Shopify’s protected customer data, the app is approved for one field: the buyer’s email address, on orders that an affiliate was credited for. It is used for two purposes and no others — so a merchant can see which buyer an affiliate brought, and so an affiliate cannot be paid commission on their own purchase. The app does not request or store buyer names, phone numbers or addresses. Orders that no affiliate is credited for are not stored at all.

Tracking consent

A referral click sets a first-party cookie on the merchant’s own domain so a shopper who buys next week is still credited to the creator who sent them. Where a shopper has told the store they do not want analytics or marketing tracking, Shopify reports that decision through its Customer Privacy API, and the app’s theme extension erases those cookies and strips the referral from the cart. A decision made part-way through a visit takes effect immediately rather than on the next page. The shopper still gets the discount they clicked the link for; what stops is the tracking.

Encryption

Data in transit is TLS everywhere: the admin, the partner portal, the storefront proxy and every call to Shopify. The database is encrypted at rest by the hosting provider, and connections to it use TLS.

Any third-party credential a merchant hands the app — an email sending key, a Meta token — is sealed individually with AES-256-GCM under a master key held in the environment, never in the repository, with the key version recorded on the row so keys can be rotated without losing what old rows were sealed with. Plaintext credentials are never written to a log, never returned by a page load, and never echoed back into a form; support sees a short fingerprint instead.

Database backups are encrypted with AES-256 before they are written. The backup script refuses to produce an unencrypted dump against a production database, on the grounds that a backup is a complete copy of every programme and every buyer email in it, and it outlives the database it came from.

Separation between merchants

Every record belongs to exactly one shop, and the database client refuses a query that has not been scoped to one. This is enforced in the data layer rather than by convention in each query, because a convention holds until the day somebody forgets it. A sign-in link minted for one merchant’s programme does not authenticate against another’s.

Test and production data

Development and testing run against a separate database, seeded with generated data. Production data is never copied into a development environment, and no development environment holds production credentials.

Who can reach personal data

No screen in the merchant admin displays a buyer’s email address. Attribution is shown as an order name and the affiliate who earned it, which is what a merchant needs to run a programme, so the address is not put on a page where it does not need to be.

Administrative access to production is limited to the named individuals who operate Hatzlacha Management LLC, on the principle of least privilege, and is used to run and repair the service rather than to browse it. There are no shared logins. Every account with production access requires multi-factor authentication and a unique password of at least sixteen characters generated and stored in a password manager; passwords are never reused across services and never transmitted in plain text. Access is removed the day a person stops needing it.

Logging access to personal data

Every read of a buyer’s personal data and every erasure of it writes a line to an access log, recording what was reached, how many records, who or what performed it, and the basis it was permitted under. The log identifies the person by a hash of their address rather than the address itself, so that a record kept to prove an erasure happened does not become the copy that survived it.

Retention

Session records are deleted the moment a merchant uninstalls. Programme data is held for a short window after that in case the uninstall was accidental, and is then erased in full, which Shopify also compels through its shop/redact webhook forty-eight hours after uninstall. Click records, which carry only a salted daily hash of the visitor IP and never the address itself, age out on a rolling window. A buyer erasure request removes the email, the customer id and the email hash from the commission while leaving the financial record itself intact, because that row is the merchant’s evidence of money owed to an affiliate.

Data loss prevention

Backups run on a schedule, are verified as readable before they count as a success — an unreadable backup is worse than none, because it is trusted — and are pruned on a retention window. A backup that cannot be listed is deleted and the run is marked failed rather than passed. Scheduled jobs record proof that they ran, so a cron line that silently stops firing is visible rather than assumed to be working.

If there is an incident

An incident is any unauthorised access to, disclosure of, or loss of merchant or buyer data, and any event that gives good reason to believe one has happened.

1. 01

   Contain, within hours of detection

   Revoke the credentials involved, cut the access path, and take the affected component out of service if it cannot be made safe in place. Containment comes before diagnosis.

2. 02

   Assess, within 24 hours

   Establish which shops are affected, which records were reachable, and whether data was actually accessed rather than merely exposed. The access log and the hosting provider’s logs are the evidence.

3. 03

   Notify

   Affected merchants are told by email without undue delay and in any event within 72 hours of becoming aware, with what happened, what data was involved, what has been done, and what they need to do. Shopify is notified in parallel where the incident touches data obtained through its APIs. Merchants are the data controllers for their buyers, so any notification to a buyer is theirs to make and we give them what they need to make it.

4. 04

   Remediate and record

   Fix the cause rather than the symptom, write down what happened and what changed, and keep that record. A fix that is not written down is a fix that gets undone.

Reporting a vulnerability