Legal
How the MiMony family of restaurant applications — point of sale, manager & waiter, kitchen display, customer display and self-order kiosk — handles personal information on the devices they run on.
MI Mony("MiMony", "we", "us") builds and publishes the MiMony restaurant management applications. Our registered address is Al Kifah Tower, King Fahd Road, Dhahran 34232, Saudi Arabia.
This policy explains what personal information the MiMony Android applications collect, why they collect it, who it is shared with, and the choices available to the people it describes. It covers the applications only. It does not cover the separate websites, marketing pages or back-office web portals we operate, which carry their own notices.
This single policy applies to all five MiMony Android applications. Each one is a different piece of the same restaurant system, and each collects only what its own job requires.
| Application | Package | Who uses it |
|---|---|---|
| MiMony POS | com.pos.system.pos | Staff — the counter terminal. Takes orders, prints receipts and accepts card payments. |
| MiMony Manager & Waiter | com.pos.mimony.pos_mimony | Staff — handheld table service and management: floor plan, order taking, reports, shift control. |
| MiMony KDS | com.mimony.kds | Staff — the kitchen display. Shows incoming tickets to cooks and tracks preparation times. |
| MiMony CDS | com.mimony.cds | Customer facing — the display at the counter. Mirrors the order and total being rung up. |
| MiMony Kiosk | com.user.mimony | Customer facing — self-order kiosk and table tablet. Customers browse the menu, order and pay themselves. |
All five are business applications, installed on devices owned and operated by a restaurant. They are not consumer apps for personal use.
This distinction decides who you should contact about your information, so we state it plainly.
The restaurant is the controller. Each restaurant that licenses MiMony decides what it records about its staff and its guests, and how long it keeps it. Order history, customer names and phone numbers, employee records, sales reports and payment records belong to that restaurant.
We are the processor.We supply the software and, where the restaurant uses our hosted backend, the servers it runs on. We act on the restaurant's instructions under a written agreement and do not use its data for our own purposes.
We are the controller for a narrow set of data: crash reports and technical diagnostics from the apps themselves, and the licensing and support records we keep about our business customers.
If you are a diner or an employee and you want to exercise a right over your information, the restaurant is the right first contact. Write to us anyway if you do not know who that is — see Section 16 — and we will route the request.
The apps collect the categories below. Not every app collects every category; the right-hand column says which ones do.
| Category | What it includes | Apps |
|---|---|---|
| Staff account | Name, username or email, employee number, job role and permissions, login PIN, session token. Set by the restaurant, not by us. | POS, Manager & Waiter, KDS |
| Staff activity | Who opened, changed, discounted, voided or cancelled an order and when; clock-in and clock-out times; till open and close; the reason recorded for a void or refund. | POS, Manager & Waiter, KDS |
| Order data | Items, quantities, modifiers, kitchen notes, table or ticket number, order type, timestamps, preparation and bump times, totals, taxes and discounts. | All five |
| Customer contact | Name, phone number, and — where the restaurant enables it — email address, delivery address and a loyalty identifier. Entered by a staff member or by the customer at a kiosk. Optional in every case; an order can be placed without it. | POS, Manager & Waiter, Kiosk |
| Payment outcome | Amount, currency, approved or declined, card scheme, the last four digits of the card, authorisation and reference numbers, and the receipt. See Section 6. | POS, Manager & Waiter, Kiosk |
| Staff photo | An optional profile picture a staff member chooses from the camera or gallery. | Manager & Waiter |
| Device and diagnostics | Device model and manufacturer, Android version, app version and build, a generated device or terminal identifier, network connection state, push notification token, and the IP address the device connects from. | All five |
| Crash reports | Stack traces, the app state at the moment of a crash, and the device details above. Collected through Firebase Crashlytics to fix faults. | All five |
Information we do not collect
The apps do not request or collect an advertising identifier, contacts, calendar, SMS, call logs, health or fitness data, browsing history, or background location. There is no advertising SDK and no third-party behavioural analytics in any of the five applications.
Android asks for these permissions. Every one is tied to a feature you can see; none is used for tracking or profiling.
| Permission | Why the app needs it | Apps |
|---|---|---|
INTERNETACCESS_NETWORK_STATE | Reach the restaurant's MiMony server to send and receive orders, and detect when the connection drops so work can be queued offline and sent later. | All five |
NFC | Read a contactless card or phone held against the device to take a payment. Handled entirely inside the certified payment SDK — see Section 6. | POS, Manager & Waiter |
ACCESS_FINE_LOCATIONACCESS_COARSE_LOCATION | Two technical requirements, not a mapping feature. Android will not let an app scan for nearby Bluetooth receipt printers without location permission, and the card payment SDK requires it for the fraud checks the card schemes mandate. We do not record, store, log or share the device's location, and the apps have no background location access. | POS, Manager & Waiter |
BLUETOOTHBLUETOOTH_SCANBLUETOOTH_CONNECT | Find and connect to the restaurant's thermal receipt and kitchen printers. | Manager & Waiter |
READ_PHONE_STATE | Read the device identifier the payment SDK uses to register and recognise the terminal with the acquiring bank. | POS, Manager & Waiter |
USE_BIOMETRICUSE_FINGERPRINT | Let a staff member unlock their session with a fingerprint or face instead of retyping a PIN. The biometric itself is held by Android in secure hardware; the app only receives a yes or no and never sees or stores it. | POS, Manager & Waiter |
CAMERAREAD_MEDIA_IMAGESREAD_EXTERNAL_STORAGE | Let a staff member take or choose a profile photo. The app opens the picture the user selects and nothing else in the gallery. | Manager & Waiter |
WRITE_EXTERNAL_STORAGE | Save receipts, shift reports and sales summaries as PDF files on the device so they can be printed or shared. | POS, Manager & Waiter |
POST_NOTIFICATIONS | Show an alert when a new order arrives, an order is ready, or a manager approval is requested. | Manager & Waiter |
Where Android treats a permission as optional, the app asks for it the first time the feature is used and the request can be declined. Declining disables only that feature — Bluetooth printing, the profile photo, biometric unlock — and the rest of the app keeps working.
Card numbers, PINs, CVV codes and magnetic-stripe data never enter the MiMony applications and are never sent to our servers.
Where a MiMony app accepts a card, the card is read inside a certified payment SDK — NearPay's Tap to Pay on Android — or on a separate certified payment terminal. That component handles the card data in an isolated environment and talks directly to the acquiring bank. Our app hands it an amount and receives a result.
What the app receives and stores against the order is the outcome only: approved or declined, the amount and currency, the card scheme, the last four digits, the authorisation and reference numbers, and the receipt text. That is what appears on the printed receipt and in the restaurant's sales reports.
The payment provider is an independent controller of the card data it processes and handles it under its own privacy policy and its PCI DSS obligations. Cash, and payments taken at the counter after a kiosk order, involve no card data at all.
| Purpose | Legal basis |
|---|---|
| Taking, routing, preparing and completing an order, and printing or displaying a receipt. | Performance of a contract with the customer, and the restaurant's legitimate interest in running its service. |
| Calling a customer about their order, or identifying it for collection or delivery. | Performance of a contract; the customer provides the detail voluntarily. |
| Authenticating staff, applying role permissions, and keeping an audit trail of voids, discounts, refunds and cancellations. | The restaurant's legitimate interest in preventing loss and fraud, and in supervising its business. |
| Recording sales, taxes and payment records. | Compliance with tax, fiscal and accounting obligations. |
| Delivering push notifications about orders to staff devices. | Performance of a contract with the restaurant. |
| Diagnosing crashes and faults, and improving stability and performance. | Our legitimate interest in maintaining a reliable product. |
| Camera, photo library, Bluetooth and biometric access. | Consent, given through the Android permission prompt and withdrawable in device settings at any time. |
Where local law makes consent the required basis instead of legitimate interest, we rely on consent and it can be withdrawn.
We do not sell personal information and we do not share it for advertising. We disclose it only to the following, and only for the purposes described.
| Recipient | What they receive | Why |
|---|---|---|
| The restaurant operating the app | All order, customer, staff and payment data it records. | It is that data's controller. |
| Google — Firebase Cloud Messaging | A push token and the notification payload for staff devices. | Delivering order alerts. No customer contact details are put in a notification payload. |
| Google — Firebase Crashlytics | Crash stack traces, device model, OS and app version. | Fixing faults. Crash reports are not used to identify individuals. |
| Google — Cloud Firestore | The tenant code the app was provisioned with. | Looking up which MiMony server the device belongs to at startup. No order or customer data is written to it. |
| Google Fonts | The device IP address when a typeface is fetched. | Loading fonts used in the interface. |
| NearPay and the acquiring bank | Card data captured inside their SDK, and the transaction amount. | Authorising and settling card payments. See Section 6. |
| Authorities | Only what a valid legal order requires. | Complying with the law, or defending a legal claim. |
Google's handling of the Firebase services above is described in the Google Privacy Policy. If we ever sell or transfer our business, personal information may pass to the acquirer under this same policy.
Operational data is held on the MiMony backend servers used by the restaurant, hosted in Saudi Arabia. Some restaurants run MiMony on their own on-premise server instead, in which case the data stays on their premises and is governed by their own arrangements.
Each app also keeps a local copy on the device: an encrypted store for the session token and credentials, held in the Android Keystore, and a local cache of the menu, open orders and queued work so the app keeps functioning through a network outage. Both are removed when the user signs out or the app is uninstalled.
Firebase Cloud Messaging, Crashlytics and Cloud Firestore are operated by Google and may process data outside Saudi Arabia. Those transfers rely on the safeguards in Google's data processing terms, including standard contractual clauses where they apply.
| Data | Kept for |
|---|---|
| Orders, sales and payment records | As long as the restaurant's tax and accounting obligations require — commonly five to ten years — then deleted or anonymised. |
| Customer name and contact detail on an order | For the retention period the restaurant configures. It can be cleared on request. |
| Staff accounts and activity logs | For the duration of employment and the period afterwards required by local employment and audit law. |
| Session token on the device | Until sign-out, token expiry, or uninstall. |
| Offline cache on the device | Until sign-out or uninstall. Queued orders are cleared once they reach the server. |
| Push notification token | Until sign-out or uninstall. |
| Crash reports | Up to 90 days in Firebase Crashlytics. |
No system is perfectly secure. If a breach affects personal information we hold, we will notify the affected restaurant and the relevant supervisory authority within the time the applicable law allows, and support the restaurant in notifying the individuals concerned.
Depending on where you live, you may have the right to ask for a copy of your personal information, to have it corrected or deleted, to restrict or object to how it is used, to receive it in a portable form, and to withdraw a consent you previously gave. You also have the right to complain to your local data protection authority.
Because the restaurant is the controller of order, customer and staff data (Section 3), send that request to the restaurant you dealt with. If you cannot identify or reach them, write to us at [email protected] with enough detail to find the record — the restaurant, the approximate date, and the phone number or name used — and we will pass the request on and support them in answering it. We will acknowledge within 30 days.
You can withdraw permissions the app has been granted at any time in Android Settings → Apps → the MiMony app → Permissions, and uninstalling the app removes everything it stored locally on that device.
These are business applications for restaurant operations and are not directed at children. We do not knowingly collect personal information from children. If a child's information reaches us through a kiosk or an order, contact us and we will have it deleted.
We update this policy when the apps change what they collect or how they use it. The effective date at the top always reflects the current version. Material changes are announced to the restaurants using MiMony before they take effect, and the updated policy is published at this address.
| Entity | MI Mony |
|---|---|
| Address | Al Kifah Tower, King Fahd Road, Dhahran 34232, Saudi Arabia |
| Privacy | [email protected] |
| Subject line | Privacy request — and the app name |
© MI Mony · Version 1.0 · Effective September 16, 2026 · Governed by the laws of Saudi Arabia
GET STARTED TODAY
Join 400+ Saudi operators who run their front and back of house on MiMony. Free for the first 14 days — no card required.
MiMony
The operating system for Saudi restaurants. Built in Riyadh, loved from Jeddah to Dammam.