---
title: Privacy Policy
version: 1.7
effective: 2026-09-16
---

# Privacy Policy

This policy explains how **Madar** handles personal data in the Madar point-of-sale and
ordering platform.

## 1. Who is responsible for your data

Madar is used **by restaurants** to run their business, and that shapes who is responsible
for what.

- When you order food, make a reservation, or take a delivery, **the restaurant you ordered
  from is responsible** for that data — it is the controller. Madar processes it on the
  restaurant's behalf, on its instructions, as its processor.
- Madar is directly responsible only for the data of its own account holders — the people
  who log in to manage a restaurant — and for our own business records.

To have your order data corrected or deleted, **contact the restaurant you ordered from**.
When they instruct us, we act on it, and we will help you reach them.

## 2. What we collect

### Delivery orders and reservations

| Data | Why |
|---|---|
| Name | to identify the order |
| Phone number | to confirm the order and contact you about delivery |
| Delivery address — street, floor, landmark | to deliver the order |
| Order contents and amount | to fulfil and bill the order |

Your phone number is verified with a one-time code sent over WhatsApp.

**There is no marketing database.** This data exists to fulfil your order. We do not build
profiles from it and we do not sell it. A loyalty membership is deliberately different, and
is described below.

### Dining in

When you eat in, the waiter opens a bill against your table. If you gave a name on arrival —
for a booking, or so the staff could find you — it is held on that bill, with the number of
guests and any note about the order, and becomes part of the order record when the bill is
settled. The floor plan itself records **tables, not people**: where a table is, whether it
is occupied, and whether it still needs clearing.

### Loyalty programme

Joining is a deliberate act. You scan the code at the counter and enter your name and phone
number; ordering from a restaurant does not enrol you. The restaurant may require the number
to be verified with a one-time WhatsApp code, the same way ordering does.

| Data | Why |
|---|---|
| Name | to greet you at the counter and to put on your card |
| Phone number | to identify your membership, so one person is one membership |
| A random membership code | what your card's barcode contains. It is random, not derived from your name or number, and cannot be guessed from anyone else's |
| Points or stamps, and lifetime totals | to work out what you have earned |
| Each earning and each reward, with the order it belonged to | so a balance can be explained, checked and corrected |
| The branch whose code you scanned | reporting for the restaurant |
| The language you read in — English or Arabic | so the restaurant writes to you in the language you read. Your card page reports whichever your browser is set to, and we store it against the membership |
| Your birthday — the **day and month only** | to wish you a happy birthday, where the restaurant does that |

**We do not ask for the year you were born.** A birthday greeting needs to know *when*,
not how old you are — and a full date of birth is an identity credential, the thing a bank
asks for to prove who you are. The field is optional, it appears only where the restaurant
runs birthday rewards, and where they do not it is not shown and nothing is stored. On the
day, the restaurant's programme sends you a greeting and, if they have set one, adds a
reward to your card. How that message reaches you, and how to stop it, is set out below.

**A loyalty membership is, by design, a record of how often you visit and what you spend,
linked to your name and phone number.** That is what makes rewards possible, and it is the
one place in Madar where a customer's purchases are deliberately connected over time. It is
the restaurant's record. It is not shared with other restaurants on Madar, it is not sold,
and it is not used for advertising. You can leave at any time — see section 9.

#### Your card page

The membership code your barcode carries is also the address of your own card page. Opening
it shows your balance, the rewards on offer, the buttons that put the card in a wallet — and
**your past orders at that restaurant: the date, the branch, the total, and the items on
each one.**

**The link is the only credential.** There is no password and no login, deliberately:
someone who has just been sent a message has to be able to act on it by tapping it, not by
remembering a password they never made. The consequence is just as plain, and we would
rather state it than dress it up — **anyone holding that link, or a clear photograph of your
barcode, can open the page and read that history.** It is the trade a paper stamp card
already makes, with more written on it. Keep the link the way you would keep the card. If
you would rather the history were not reachable at all, ask the restaurant to delete the
membership; see section 9.

#### Messages from the restaurant

Where the restaurant switches them on, the programme sends two kinds of message and no
others:

- **A birthday greeting**, on the day, where you gave a day and month.
- **"We've missed you"**, when you have not been in for **7 days**, and once more at **14**.
  After **60 days** it stops for good — a message from a shop you have forgotten is a list
  being worked through, not a greeting. Two per absence, never a third.

Either can add points or stamps to your balance, where the restaurant has set an amount.
That addition goes through the same ledger as every other movement, so it appears in your
history with a reason rather than as a balance that changed by itself.

"Not been in" means the later of your last order and your last points movement, as they were
attributed to your membership. A visit nobody attached to your card — a walk-in paid in cash,
with no card and no number — is invisible to this, and always will be.

These are the only messages the programme sends unasked. An order confirmation and a
one-time code are not marketing; they are how an order works.

#### Stopping them

Every one of these messages carries a link to your card page, and that page carries the
switch. One switch stops both kinds at once: a birthday greeting and a "we've missed you"
are the same restaurant talking to you, and asking one to stop is asking the restaurant to
stop. It takes effect immediately and needs no account, no reply and no reason. It does not
touch the card — your balance, your barcode and your rewards carry on exactly as before.

### Madar accounts (restaurant staff and managers)

Name, email address, a securely hashed password, and the branches and permissions assigned
to you. Your password itself is never stored.

### Payments

Card payments are handled by the payment provider. **Madar never receives or stores card
numbers** — only which method was used and the amount.

### Device and app-version records

For each POS or kitchen device that talks to our server (or, where a device does not send
an identifier, for the connecting client), we record its device identifier, the app name
and version it reports, its organisation and branch, the first and last time it was seen,
and which older API features it last used. This runs so that old app versions can be
retired safely and so support can diagnose a problem. See
**[Data Retention Schedule](/data-retention.html)**.

## 3. What we do not do

- No advertising identifiers, no cross-app tracking, no ad networks.
- No tracking of where you are. The one feature that involves location — a wallet card
  surfacing near a branch — is decided by your own phone and sends us nothing.
- No selling or renting of personal data.
- No storage of card numbers.
- **No customer data is sent to any AI service.** See section 5.

## 4. Who we share data with

Only what running the service requires. The current providers, what each receives and where
it operates are listed at **[Sub-processors](/subprocessors.html)**.

Two disclosures worth stating plainly rather than leaving to a table.

**Menu item names** are sent to Google Cloud Translation to produce translated menus. No
customer data is involved — only the names of dishes.

**The customer-facing pages are served through Cloudflare**, which sits in front of them as a
reverse proxy. It ends the encrypted connection rather than passing it through, so it can see
the traffic in the clear: the visitor's IP address, the pages opened, and anything submitted
on them. It acts on our instructions and does not use that traffic for its own purposes. The
staff-facing system — the till, the dashboard and the API behind them — does not go through
Cloudflare, and no database content is ever held there.

Where a restaurant asks us to send its order data to another system it uses — for example
an in-house shopping-mall reporting system — we do so **only on that restaurant's written
instruction**. The restaurant is responsible for that disclosure.

## 5. The analytics assistant

Restaurant managers can ask questions about their own business in plain language — "what
sold best last week", "which branch is busiest on Fridays" — and get an answer with the
figures behind it. Producing that answer involves sending the manager's question and the
resulting figures to an AI provider (see
**[Sub-processors](/subprocessors.html)**).

What this means for **you as a diner** is simple, and it is a deliberate design choice
rather than a policy promise we ask you to take on trust: **no customer data can reach the
assistant at all.** It can only ask for a fixed set of pre-written business measures —
revenue, units sold, waiting times, stock levels and the like. There is no measure in the
system that returns a customer's name, phone number, address or location, so there is
nothing for it to send. The assistant cannot write its own queries and cannot reach data
outside that fixed set.

Staff names are handled separately and are described in the
**[Employee Privacy Notice](/employee-privacy-notice.html)**.

Questions and answers are stored so a manager can return to a conversation. They are kept
with the restaurant's own account data and are deleted with it. The result rows themselves
are never stored — reopening a conversation re-runs the query, so the figures shown are
current rather than a stale copy.

The provider currently in use, the model, and exactly what is sent on each question are
listed under **[Sub-processors](/subprocessors.html)**, so the statements above can be
checked against the running system rather than taken on trust.

## 6. Loyalty cards in Apple and Google Wallet

Where the restaurant has set it up, your loyalty card can be added to Apple Wallet or Google
Wallet. This is optional: the card also works as a page on your phone with the same barcode,
and the counter scans either.

**What the card holds.** Your name, your balance, the restaurant's name and colours, and
your membership code as a barcode. The Apple version also shows your phone number on the
back of the card. All of that is your own data, on your own phone.

**Apple Wallet.** The card file is built and signed by us and downloaded to your phone.
**Apple is not sent your name, your number or your balance.** When you add the card your
phone registers with us so the card can keep itself up to date, and we store an identifier
for that device and a notification token for it. When your balance changes we send an
**empty** notification through Apple — it carries nothing about you — and your phone then
asks us for the new card.

**Google Wallet.** Google's system works differently, and the difference matters: the card
is **stored on Google's servers**. Adding it sends **your name, your membership code, your
balance and the restaurant's branch coordinates to Google**, and sends them again whenever
your balance changes. If you would rather Google did not hold that, use the web card or
Apple Wallet — the programme works identically either way. Google is listed under
**[Sub-processors](/subprocessors.html)**.

**Messages sent through the card.** A greeting or a "we've missed you" goes to your wallet
card where you have one, and to WhatsApp only where you do not. The two wallets do this
differently, and the difference is the same one as above.

*Apple.* There is no way to send text to a pass. iOS raises a notification when a **field on
the card** changes, so the message has to be a field: we write it onto your card here, send
the same **empty** push as for a balance change, and your phone comes back to us for the card
and shows the new line. **The words themselves never pass through Apple.** They are printed
on the card and stay there until the next message replaces them. Whether you have switched
notifications off for that particular pass is between you and your phone — Apple does not
tell us, which is one reason for the fallback below.

*Google.* Your card lives on Google's servers, so a message can only get onto it by being
sent there. **The text of the message goes to Google's Wallet API**, alongside the name and
balance Google already holds. There is no version of this that keeps the words from Google.
If you would rather Google did not receive them, use the web card or Apple Wallet.

*The WhatsApp fallback.* When a phone comes back for the updated pass, we know the message
landed — that fetch is the only delivery signal either wallet gives us, and only Apple gives
it. If no phone has come back after about **8 hours**, we send the message on WhatsApp
instead, so a card sitting muted in a drawer does not silently swallow it. A card saved in
Google Wallet gets no fallback at all, because Google reports nothing back and the only
alternatives would be messaging you twice or never.

**On the card appearing when you are near the shop.** The card carries the coordinates of
the restaurant's branches, and your phone compares them against where it is. **That
comparison happens on your phone. Your location is never sent to us. We do not receive it,
store it, or have any way to see where you are.** Your phone's own settings control whether
this happens at all.

## 7. Where data is stored

Primary systems are hosted in Europe. Backups are held on separate infrastructure under our
control. Some providers listed under Sub-processors operate outside Egypt; that is
identified there.

Error and crash reports are an exception to "hosted in Europe": they are received by our
server in Europe but are then processed and stored on a separate server we operate **in
Egypt**, which is not part of that European hosting. See **[Security](/security.html)**.

### On the POS tablet itself

Each POS tablet keeps a local copy of its branch's own operational data — orders and their
items, payments, tills and cash movements, refunds, open bills and tables, kitchen tickets,
deliveries and bookings — plus a queue of changes not yet sent to the server, so it keeps
working while offline. That copy lives in the app's private storage on the device and is
protected by the operating system's own device encryption; Madar adds no encryption layer of
its own on top of it.

Recent history is kept — the sync window covers roughly the last **48 hours** of ledger
activity plus anything still open — and older rows are pruned automatically. Unsent changes
are never pruned before the server confirms them, however old they get. Signing out of a
device keeps its unsent sales rather than losing them, unless the device is wiped. If a
tablet's local store is found to be damaged, the app exports its unsent queue to a file in
its own private storage and deletes that file once the queue has been sent.

**If a device is lost or stolen**, sign it out and change the PINs of the staff who used it.

### Between a shop's own devices

Devices at the same branch talk to each other directly over the shop's own Wi-Fi — orders,
bill changes, voids, refunds and cash movements — so they stay in sync even without a
connection to the server, and each keeps copies of the others' unsent changes until the
server confirms them.

These messages are **signed** with a key specific to the branch, so a device from another
branch, or an outsider on the network, cannot forge or alter them. They are **not
encrypted today** — anyone connected to the same Wi-Fi could read them. Encrypting this
traffic is planned. Until then, restaurants should put their POS devices on a private,
password-protected Wi-Fi network rather than an open or shared one.

## 8. How long we keep it

Set out in full in the **[Data Retention Schedule](/data-retention.html)**. In summary:
order records are kept for **5 years** to meet accounting and tax requirements; account data
is kept while the account is active; diagnostic error reports are deleted after **30 days**.

## 9. Your rights

Under Egyptian data protection law you may request access to your data, its correction or
deletion, and may object to how it is used. Because the restaurant is the controller of
order data, requests about orders go to them and we assist.

**To leave a loyalty programme**, ask the restaurant, or write to us and we will help you
reach them. Deleting the membership removes your name, phone number and membership code, and
the card stops working. The orders themselves stay in the restaurant's accounting records for
the period in the retention schedule. Note that **removing the pass from your phone stops
the card being shown but does not, by itself, delete the membership** — ask the restaurant
for that.

**To stop the messages without leaving**, use the switch on your card page — see section 2.
That is a preference and not a deletion: the membership, the balance and the card go on
working exactly as before.

To delete a Madar account, see **[Delete your account](/delete-account.html)**.

## 10. Security

How the platform is secured is described in **[Security](/security.html)**.

## 11. Children

Madar is a tool for businesses and their customers. It is not directed at children.

## 12. Changes

We will notify material changes through the product. Every previous version of this policy
remains available with its effective date.

## 13. Contact

**privacy@madar-pos.cloud**