Privacy policy
Dukkan POS is a point-of-sale system for small shops. This page explains what the platform holds, where it is held, and for how long.
[PLACEHOLDER — counsel to supply: the identity and contact details of the controller, the supervisory authority, and the legal bases relied on.]
Two different roles
The platform handles two kinds of information, and its role is different for each.
- The merchant's own account. The shop's name, its address on the platform, the owner's login email, and the subscription that runs it. Here the platform decides what is collected and why — it is the controller.
- The shop's data. Products, prices, sales, staff, and the shop's own customers — including their names, phone numbers, purchase history and outstanding debts. This belongs to the merchant. The platform stores and processes it on the merchant's instruction and for no other purpose — it is the processor. The terms of that relationship are in the data processing addendum.
A shopper whose name appears in a shop's customer list never signed up for anything here. Requests about that data go to the shop; the platform assists the shop, and does not decide on its behalf.
What is stored
| Category | Examples | Role |
|---|---|---|
| Merchant account | shop name, subdomain, owner's email, plan, subscription dates | controller |
| Staff | name, role, hashed PIN | processor |
| Catalogue | products, categories, suppliers, units, prices, stock | processor |
| Sales | orders, order lines, discounts, payments, cash movements, shifts | processor |
| Shop customers | name, phone, purchase history, outstanding balance | processor |
| Devices | a server-generated identifier, a human-readable label (e.g. "Galaxy A15 · Android 15"), last-seen time | processor |
| Files | exports and backup bundles the shop produced, in private storage | processor |
| Operational logs | activity log entries, sign-in attempts, delivery records for the emails we send | mixed |
The mobile app collects no hardware identifier: no advertising ID, no IMEI, no Android ID. A terminal is identified by a random identifier the server issues at enrolment, which the owner can revoke from the Devices screen.
Sub-processors
| Sub-processor | What it does | Where |
|---|---|---|
| Supabase | the database, authentication, and file storage | [PLACEHOLDER — region] |
| Vercel | hosting and delivery of the web application | [PLACEHOLDER — region] |
| Mailgun or Resend | delivery of transactional email, whichever is configured on the platform | [PLACEHOLDER — region] |
There are no others. No analytics service, no advertising network, no tracking pixels, no third-party scripts on any page.
[PLACEHOLDER — counsel to supply: the international transfer mechanism for each sub-processor above.]
Cookies
The platform sets functional cookies only. There is no analytics cookie and no third-party cookie of any kind, because there is no analytics and no third-party tracking to serve.
| Cookie | What it is for |
|---|---|
dukkan_session | keeps a signed-in staff member signed in |
dukkan_admin | the same, for a platform administrator |
dukkan_store | which store account is signed in |
dukkan_ownersel | which of an owner's shops is currently selected |
dukkan_switched | a one-shot notice that the selected shop changed |
dukkan_till | which till this browser is ringing up on |
dukkan_lang | Arabic or English, per device |
No consent banner is shown because none of these is used for anything but running the service.
How long it is kept
- A live shop's data is kept while the shop is live. Nothing is deleted on a schedule while the subscription runs.
- Saved exports and reports are removed 90 days after they are produced.
- Backup bundles are kept to the most recent few per shop (8 by default) and the older ones are pruned.
- Sync tombstones — which carry no personal data, only "a row with this id is gone" — expire after 30 days.
- Operational logs follow platform-wide retention windows: the activity log is archived rather than deleted, and sign-in attempt records and expired session tokens are removed on their own windows.
- A closed shop is retained for a window after closure and then permanently deleted. [PLACEHOLDER — counsel to confirm the window; the mechanism is implemented and described in the addendum.]
Taking your data with you
A shop owner can export their entire shop — catalogue, customers, sales history, settings — as a single file, at any time, from the store settings. That export is also the termination path: it is offered before a shop is deleted, and it is what the addendum means by return of data.
Security
Access to a shop's data is scoped to that shop at the database level. Staff PINs are stored hashed, never in plain text. Terminal credentials are revocable from the owner's Devices screen, and a stolen refresh token invalidates the whole device rather than being silently reused. File storage buckets are private; no uploaded file is world-readable.
Your rights
[PLACEHOLDER — counsel to supply: the rights available to data subjects, how to exercise them, response times, and the complaint route. Note for counsel: a shop-level export exists today; a per-customer export and a full erasure workflow are known outstanding work and should not be promised here before they are built.]
Changes to this page
The version in force is shown at the foot of this page. Material changes are notified to shop owners [PLACEHOLDER — counsel to specify how and how far in advance].
Contact
Questions about this page go through the contact form.