Data processing addendum

This addendum forms part of the terms of service between Ismail A. Amassi, trading as Dukkan, Gaza, Palestine (the "provider", "we") and the merchant, and governs the personal data a merchant's shop holds on the platform. It applies from the moment a shop is created. On any matter of data protection, this addendum prevails over the terms; on everything else, the terms prevail.

Palestine has no general data-protection statute in force at the time of writing. This addendum is a contractual undertaking that follows the processor duties of the EU General Data Protection Regulation (Article 28), and it is written so that a merchant who is subject to such a law — in the European Union, the United Arab Emirates, Egypt, or elsewhere — can rely on it to meet that law's requirements for a processor agreement. Where a merchant's own law requires something more, the merchant should tell us through the contact form and we will discuss it in good faith.

Roles

The merchant is the controller of the data in their shop. The provider is the processor, acting only on the merchant's documented instructions — which, in the ordinary case, are the merchant's own use of the product: every screen, export, sync and report the merchant or their staff runs is an instruction.

We will tell the merchant if, in our opinion, an instruction would break a law that applies to us, and we may then pause that instruction until it is clarified.

The provider is the controller of one narrow set: the merchant's own account details and the operational records of running the service for them. The privacy policy covers those.

What is processed

Our obligations as processor

We will:

• process the data only on the merchant's instructions, and for no purpose of our own; we do not sell it, mine it, or use it to build anything beyond the merchant's own service;
• make sure that anyone who works on the platform under our direction is bound to confidentiality — today that is the provider alone, and any future person will sign a confidentiality undertaking before they touch shop data;
• put in place the security measures listed below and keep them in place;
• engage sub-processors only as set out below;
• help the merchant answer requests from their clients and staff, as set out below;
• help the merchant meet their own security, breach-notification and data-protection-assessment duties, with the information we hold;
• delete or return the data at the end of the service, as set out below;
• make available the information needed to show that these obligations are met, as set out under Audit.

Sub-processors

There are no others. In particular there is no advertising network and no third-party tracking anywhere in the product — web or mobile — and no analytics of any kind touches shop data: nothing measures a signed-in shop's staff or clients. Two measurements exist and both are cookieless and carry no personal data: visit counts on the public marketing pages, which process no shop data, and page-performance timings on every web page, which record how fast a page loaded and nothing about what it showed.

On the crash reporter specifically, because it is the one entry above that touches a live request. The error payload is assembled field by field in the platform's own code, not by a vendor SDK: the request body, headers, cookies and query string are never attached, and the message and stack are passed through a redaction step first — email addresses, telephone-shaped numbers, the database's own "duplicate value" detail line, anything under a key named for a secret, and any Arabic text (which in a server error is data, not a message). The report is redacted before it leaves the platform's servers, not after it arrives. Reporting is inert entirely unless a key is configured.

Changing the list. We will tell every shop owner by email at least thirty days before adding or replacing a sub-processor, naming it and what it will do. A merchant who objects on reasonable data-protection grounds may say so through the contact form within that period; if we cannot offer a way round the objection, the merchant may end the agreement before the change takes effect, export the shop, and receive a refund of the unused whole months of any prepaid period. Every sub-processor is bound to us by written terms that impose data-protection obligations no less protective than this addendum, and we remain responsible to the merchant for their performance.

International transfers. The data is stored outside Palestine, in the locations named above. Each sub-processor's terms include the European Commission's standard contractual clauses for transfers out of the European Economic Area, and a merchant who needs those clauses for their own compliance may ask us for the reference through the contact form.

Security measures

• Each shop's rows are scoped to that shop at the database level; a request bound to one shop cannot read another's.
• Staff PINs are stored hashed. The plain-text column was removed.
• Terminal credentials are opaque, stored only as a hash, single-use on exchange, and revocable from the owner's Devices screen. A refresh token presented twice revokes the whole device rather than being honoured.
• File storage buckets are private; nothing uploaded is world-readable.
• Privileged database routines are not executable by anonymous or ordinary authenticated roles, and a continuous-integration gate fails a change that would re-open them.
• All traffic between terminals, browsers and the platform is encrypted in transit; data at rest is encrypted by the database and storage providers.
• Access to the platform's administration is limited to the provider, behind a separate password-protected account, and every administrative action is written to an audit trail.
• Sign-in doors are rate-limited, and sign-in attempts are recorded.
• Backups of every shop are taken automatically, kept private, and pruned on the retention below.

Personal data breach. If we become aware of a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to shop data, we will notify the affected merchant without undue delay, and in any case within 72 hours of becoming aware, by email to the owner's address. The notice will describe what happened, the data and people likely affected, the likely consequences, and the measures taken or proposed; where not everything is known at once, it will be followed up as it becomes known. We will keep a record of every breach and help the merchant with any notification they must make to an authority or to their clients.

Assisting the merchant with data-subject requests

A merchant asked by one of their clients or staff to produce, correct or erase that person's data can, today:

• Export the whole shop — catalogue, clients, sales history and settings — as a single file, at any time, from the store settings.
• Correct a client's or staff member's record on its own screen.
• Delete a client record from the clients screen.

Two things are honestly not built yet, and this addendum will not promise them before they are: a per-client export (that one shopper's orders and payments as a file) and an erasure that reaches everywhere the name went — free-text activity-log entries, receipts already saved into file storage, and backup bundles already taken. Both are tracked as outstanding work.

Where a request needs something the merchant cannot do from the product, the merchant writes to us through the contact form and we do it, or explain why we cannot, within fifteen days, so that the merchant can answer their client within the thirty days most laws allow. If a data subject writes to us directly, we do not answer on the merchant's behalf: we forward the request to the merchant without delay and tell the person we have done so.

Retention

• A live shop's data is retained for as long as the shop is live. Nothing is deleted on a schedule while the subscription runs, and being blocked for non-payment deletes nothing.
• A blocked shop is kept for at least six months. After six months blocked, we may delete it; the owner is emailed at least thirty days beforehand and can export or renew in that time.
• A closed or deleted shop is marked deleted, retained for ninety days, and then purged permanently — the purge cascades to everything that belongs to the shop.
• Saved exports, reports, receipts and attachments in file storage are removed 90 days after they are produced or detached.
• Backup bundles are kept to the most recent few per shop — eight by default, adjustable per shop — and older bundles are pruned as new ones are taken.
• Sync tombstones expire after 30 days. They carry no personal data: only the fact that a row with a given id no longer exists.
• The activity log is archived, never deleted, once past a window of at least 30 days; the archive keeps every row with its original identity.
• Sign-in attempt records and expired session tokens are removed on platform-wide windows, no shorter than 7 days.

Return and deletion on termination

The store export is the return-of-data mechanism. It produces the shop's catalogue, clients, sales history and settings as one file, and it is offered before a shop is deleted rather than only on request. A merchant may take it at any time during the ninety-day window by asking us to reopen the shop for that purpose.

After the retention window above, the shop's rows are permanently deleted. Backup bundles taken before deletion age out on the backup retention above rather than being individually reached into — which is why the window matters and is stated here. On request we confirm in writing when a shop's purge has completed.

Audit

A merchant may ask us, at most once a year or after a breach affecting their shop, to show that this addendum is being kept. We do that in writing: we answer the merchant's reasonable questions, describe the measures in force, and provide the current security and compliance documentation our sub-processors publish (each of Supabase, Vercel, Resend, Mailgun and Sentry maintains independent third-party attestations and makes them available to their clients). Because the provider is a single person operating a hosted service on the infrastructure of those sub-processors, there are no premises of ours to inspect; an on-site or third-party audit is available only where a merchant's law or authority requires one, on thirty days' notice, at reasonable times, and at the merchant's cost.

Contact

Requests under this addendum go through the contact form.