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.
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.
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).
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.
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, 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.
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.
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. 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.
10. Security
How the platform is secured is described in Security.
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.