Privacy Policy

1. Hardware browsing and client follow-up

The hardware catalogue has a separate browsing and request workflow. It records random device/session identifiers, page and product views, cart additions/removals, checkout starts, submitted requests, campaign/referrer information and cart snapshots. These hardware records are separate from a restaurant guest’s QR-menu order history.

A hardware request stores your name, business name, phone, email, city/address and notes where supplied, selected devices and quantities, prices or quote status, and request status. Staff may also record a client received by phone, WhatsApp or referral, with contact details, a next follow-up date, follow-up notes and a quote reference. Access is limited to hardware staff, and staff changes are recorded through the hardware back office.

Your browser stores the hardware cart and random device identifier locally. Session storage holds the checkout attempt (including entered contact details) until submission succeeds, along with receipt access tokens and request identifiers. Previously started requests and receipts may still use browser storage at store.orderscribe.com. Clear site data on both hosts to remove those local copies. Receipt access requires the saved access token, which is sent in a request header, not in a public link.

If the dedicated hardware reminder integration is enabled, Slack receives the client and business names, request reference, status, due date and device quantities with a staff-only link. Phone, email, address and free-text follow-up notes are excluded from those reminders. The hardware records do not currently have an automatic deletion schedule; contact us to request access or deletion.

2. What we collect when you order

QR-menu checkout collects this, and nothing else about you:

• Phone number — this is how you are identified. There is no verification step and no code is sent to you: the number you type is used to find or create your customer record, and it is passed to the restaurant so it can reach you about the order.
• Delivery address, plus the map coordinates you share if you tap “use my location”. The coordinates are what decide the delivery fee — they are matched against the restaurant's delivery zones, and the address you type is never measured or priced. Both are stored on the order, and the address is additionally written into your order notes, which is how the restaurant and any driver actually read it. Who sees what is set out under “Who receives your data”. Pickup orders carry neither.
• Order details — the items, options, quantities, prices, your notes, and any promo code you applied.
• We never ask for your name. When a customer record is created for you automatically, your phone number stands in for a name.
• We do not take card details on a QR menu — those orders are paid in cash to the restaurant.

3. What we record while you browse a menu

The current QR-menu website's production emitter is limited to two first-party analytics event types. When a branch menu loads it queues a session start if that browser session has not already started, and it increments that branch's daily menu-read counter. It does not currently send product-open, view-duration, option-tap, social-click, session-update, session-end, or order-conversion events:

• A random device identifier we generate and keep in local storage, plus a separate identifier kept in session storage for the browser tab. The analytics request also carries the branch, the device type, the browser's user-agent string, and the referring page. It carries no name, phone number, or email address.
• The server creates at most one session row for that session identifier. It stores the restaurant and branch, the device and session identifiers, device type, the IP address seen by our server, user-agent, referrer, and session timestamps. The row has fields for page counts, interactions and order conversion, but this website does not currently send the events that fill those fields, so they stay at their defaults for visits made here.
• Each menu load also increments one counter row shared by every visit to that branch on that Beirut calendar day; it is not a separate row for each menu view. That shared row keeps the device identifier, and any later customer link, from the first view that created it. Later views only increase the counter.

4. Cookies and what your browser stores

The QR application's own code sets one first-party application cookie: os_locale remembers whether you chose English or Arabic. The repository sets no order-tracking or advertising cookie, and no third-party advertising or analytics script runs on the site. The repository does not establish whether Cloudflare or another infrastructure provider sets a separate technical cookie at runtime; that remains for live provider review.

Your browser separately stores the device and session identifiers described above, your cart for each branch you shopped, a copy of your last order so the confirmation screen can render it, and any star rating you gave an order. The device identifier is not a fingerprint — we generate it, it lives in your browser, and clearing your site data for orderscribe.com removes all of it.

5. How browsing gets linked to your order

When you place an order, the device identifier your browser is carrying is sent with it. Session rows, shared daily menu-counter rows, and any product-view or option-interaction rows already present from the previous 90 days that carry the same identifier and no customer are then attached to your platform-wide customer record. Browsing stored for that device therefore stops being anonymous once you order; for a shared daily counter, this can attach the row created by that day's first view.

6. Your record spans restaurants

Your phone number identifies one customer record across the whole platform, not one per restaurant. From it we build a summary: how many orders and visits you have, when you last ordered, when you were last seen — the more recent of your last visit and your last order — which restaurants you have engaged with, the cuisine types those restaurants are listed under, and the language set on your customer record.

A restaurant is not given your order history at other restaurants. That summary is, however, what marketing audiences are selected from, so an audience can include people who have not ordered from the restaurant sending the message. Marketing only ever reaches people who opted in.

7. Messages you may receive

• When an order is marked delivered we may send one WhatsApp message asking you to rate it, containing the link to that order's page. It is part of the order, not marketing.
• Marketing consent is separate for WhatsApp and SMS, and the platform refuses a marketing send unless the customer has explicitly opted in to that channel. The SMS path exists in the provider and consent code but is not a confirmed active production channel. There is no reachable way to give either consent on this website — nothing here asks you for it — so ordering through a QR menu signs you up for nothing and, by itself, neither authorizes nor triggers marketing. If consent for that platform-wide customer record was already recorded through another client or channel, a campaign can still reach the phone under that existing consent. If we add a reachable opt-in here or activate another channel, this policy must change before it is used.
• The platform can also send a customer WhatsApp login code, for signing in with a phone number. No QR-menu guest page asks for that customer code and nothing in the guest flow calls its endpoint, so browsing or ordering on a QR menu never causes one to be sent to you. Those three categories are the whole list for a guest's phone number: the WhatsApp rating request, consented marketing over a configured channel, and this customer WhatsApp login code.
• We do not send order-status updates over WhatsApp or SMS. Your order's progress is shown on its own order page.
• The server does create a pending internal notification-intent row linked to an order when the order is created or its status changes. That row holds an event kind/key, processing status, attempt and timing fields, and a failure code, but no recipient, phone/customer field, channel, provider, template, body, payload, or message-log link. There is currently no worker or dispatcher that sends it. It has no separate purge job and is hard-deleted when its parent order is hard-deleted.
• Withdrawing marketing consent — replying STOP (or إيقاف) to a WhatsApp message is wired to revoke it automatically. That path only works if our messaging provider passes your reply back to us, which is not something we control or can promise.
• Withdrawing marketing consent — a marketing message written as free text carries an unsubscribe link that opts you out when you open it. A message sent through a pre-approved WhatsApp template carries that link only where the approved template reserves a place for it, so not every message has one.
• Withdrawing marketing consent — the contact at the end of this policy is a separate fallback that does not depend on an inbound STOP webhook or a template containing the link. Message us on WhatsApp or email and ask us to record the opt-out; use it if you replied STOP and a message still reached you. Those contact transports can also fail, so none of these routes is presented as a delivery guarantee. Opting out never affects your ability to order.
• For each WhatsApp or SMS provider attempt that passes the pre-send gates, the platform keeps a delivery log containing tenant/customer/template references where present, the destination number, channel, category, message purpose and locale, an idempotency key where the caller supplies one, provider and provider message identifier, attempt and delivery status/timing, a bounded generic error and stable failure code, and message cost/campaign fields. The rendered body is stored for ordinary non-sensitive messages, so a stored rating-request body includes the order-tracking link it sent; authentication/OTP bodies, and any send marked sensitive, are blank at rest. These logs are not on an automatic deletion schedule today.

8. Who receives your data

We do not sell your personal data. It reaches:

• The restaurant you ordered from — your phone number, what you ordered, your order notes and the totals, because it needs them to prepare the order. Your delivery address is part of those notes: on every delivery order the checkout writes a “Delivery to: …” line at the front of the notes, and the restaurant's order detail panel and its kitchen display print the notes as they were sent. So the restaurant does see the address you typed, as text. What it does not get is the structured copy: the address and any coordinates are stored on the order as their own separate fields, and no restaurant-facing screen carries those — so there is no map position for your order anywhere the restaurant can reach.
• The driver the restaurant assigns to a delivery order. Drivers are separate accounts on the platform — their own phone number as their identity, their own sign-in token — attached to the branches they serve. From the moment an order is offered to a driver, before they have accepted it, their app shows the order number and its status, your phone number and the name your customer record carries (for an order placed here that name is that same phone number), the total and the delivery fee, whether it is being paid in cash, your notes, and the collecting branch's own name, address and map location. If that assignment later reaches delivered, failed or cancelled, those fields remain available in that driver's delivery history. Your delivery address reaches the driver both inside those notes, as the “Delivery to: …” line the checkout writes, and in a structured delivery field together with the map coordinates you shared. This lets the app show the driver your destination as a map pin and open a route to it. A pickup order carries none of that location data and is never offered to a driver.
• Anyone holding your order's tracking link — it opens that order's number, current status, when it was placed, and estimated delivery time. That is the whole of what a holder gets. No name and no phone number are behind the link; nor are any address, notes, items, prices, or full receipt.
• Providers used by the current implementation: DigitalOcean (hosting and the image CDN), our WhatsApp Business messaging provider (360dialog or Bird, depending on configuration), Twilio where SMS is used, Sentry for error monitoring with its SDK's default-PII option disabled, Resend for restaurant-account and subscription-service email, and Stripe for restaurant subscription payments.
• Slack, where a webhook is configured, receives internal operational alerts and reports. Report messages can contain platform order, customer and signup counts; restaurant names with their order counts and per-currency sales totals; subscription and menu-edit figures; and infrastructure status. Account and billing alert messages can contain restaurant names and identifiers, subscription or provider-event identifiers, plan, amount, currency and billing frequency, and transport or webhook status.
• Anthropic receives data only when restaurant staff use the configured AI assistant or paid auto-translate. Auto-translate sends the source menu-item names and target language. The assistant sends the staff member's message and replayed conversation, the current date, restaurant name and slugs, currencies, branch names, slugs, time zones, hours and active state, category and subcategory identifiers/slugs, and menu or business data returned by its tools. Staff can also put other data into the free-text conversation, so they should not enter guest personal data there.
• The repository contains customer and driver mobile clients, but neither v2 app is distributed today. The authenticated APIs can store an Expo push token. If a client has registered one, Expo receives a customer order-status notification containing the order number and a deep-link payload with the restaurant and branch slugs, branch and order identifiers, order number, status and tracking token, or a driver offer containing the order number and assignment identifier. This QR website never registers a push token. Separately, only when a driver taps Navigate, the driver client opens a Google Maps URL containing the selected branch or customer coordinates and a generic route label; Google then receives that URL and ordinary request metadata. These are code-capable deferred-mobile paths, not a claim that either mobile app is publicly available.
• Cloudflare is our DNS provider and sits in front of orderscribe.com as a reverse proxy. Every request to this site — every page, every menu, every order — reaches our servers through Cloudflare: it terminates the HTTPS connection at its edge and screens traffic before passing the request on. Cloudflare therefore processes the content of each request and its technical metadata, including your IP address, as infrastructure in the request path.
• Current infrastructure and provider paths can process data outside Lebanon. The repository does not establish every provider's exact processing location or legal transfer role; those points remain for the pending provider and legal review.

9. How long we keep it

• Orders — delivered and cancelled orders leave the restaurant's live records about 90 days after the order, and are permanently deleted about six months after that. Deletion runs in daily batches, so a very busy restaurant's oldest records can take longer to clear.
• Public-page analytics — only the English and Arabic root landing pages (“/” and “/ar”) emit a view event today; tracked call-to-action components emit click events. Each saved row contains the event kind, an allowlisted reported source path, the locale, and its timestamp — no phone, email, name, device or session identifier, IP address, user-agent, or referrer. Tracked click components resolve the page currently open against that allowlist; if the page is not on it, the click is not sent as coming from a different page. The endpoint uses the incoming IP address in a per-minute throttle cache but does not copy it into the event row. Event rows are permanently deleted after 180 days.
• Menu analytics — session rows, shared daily counters, and any product, option-interaction, or daily product-rollup rows are not covered by a registered deletion job today. A 90-day session-cleanup function exists in the code but is not wired into any periodic tier, so it does not establish a current 90-day retention period.
• Customer and driver records and any registered push tokens, consent history, WhatsApp/SMS delivery logs, restaurant accounts and billing records, subscription-email delivery records, AI-assistant conversations/messages/actions/usage records, and auto-translation usage records have no automatic deletion schedule configured today. The driver logout path and customer push-token endpoint can clear their respective push token; that is not a scheduled deletion job.
• Restaurant email verification and password-reset links expire after 24 hours. Only a one-way hash of each one-use token is stored, and the daily cleanup permanently deletes its row after it has been expired for more than seven days.
• Provider-side copies and technical logs — this repository does not configure or prove retention/deletion periods at Cloudflare, Sentry, DigitalOcean, 360dialog/Bird, Twilio, Resend, Stripe, Slack, Anthropic, Expo, or Google Maps. The periods above describe browser storage and OrderScribe database jobs, not a promise about provider systems; those periods remain for provider and legal review.

10. Your choices

• An authenticated customer API exists for clients that implement the WhatsApp phone-login flow. Successful code verification issues a 30-day bearer token; verifying again soft-deletes the previous live token and issues a new one. The API can show your basic profile, keeps the phone number read-only, lets you change the name and language, and lets you manage saved addresses, favourites and ratings. No page in the QR-menu guest flow signs a customer in with that code or receives that customer token, so those controls are not reachable here. Restaurant accounts use the separate email-and-password identity described below. Neither the customer API nor the restaurant-account website offers a full data export or a control to delete the customer or restaurant account.
• For a fuller access/export request, correction outside those controls, or deletion, there is no automated data-request workflow and no approved fixed response deadline. Use the contact below to request a manual review of records associated with your customer phone number or restaurant-account email. We may need to verify that you control that phone number or email before disclosing or changing records.
• Withdraw marketing consent at any time — see “Messages you may receive” for the three routes, what each depends on, and the separate contact fallback. No transport is guaranteed.
• Clear your site data for orderscribe.com to remove the device identifier, the session identifier, the os_locale cookie, your saved cart, the stored copy of your last order, and any stored rating.
• A request about a customer record does not itself erase order, message, consent, or analytics rows. Those records follow the relationships and retention described above; a hard deletion of a customer removes some linked rows and leaves the customer reference blank on others, including orders, message logs, and analytics.

11. Restaurant accounts

If you sign a restaurant up on this site, we collect the owner's name, an email address, a password, the restaurant's name, and optionally a phone number. The email address is the platform-wide sign-in identity. The password is stored through Django's password hashing rather than as the raw password. Resend carries signup verification, account-exists, and password-reset email. The trial takes no card; if the restaurant later subscribes, payment runs through Stripe, from which we receive identifiers, amounts, currency and billing status. We never see full card details.

Resend also carries service emails for trial ending and expiry, payment reminders and overdue status, subscription suspension, and payment confirmation. They are rendered in English or Arabic where current restaurant data supports that locale and go to an active owner email, falling back to an active admin email. A durable delivery row stores the event kind, restaurant, locale, event date, amount and currency where relevant, delivery state, attempts and failure code; it does not store the recipient address, subject, or rendered body.

That phone number is not only a contact detail on file. OrderScribe can send a platform announcement to it over WhatsApp. An announcement goes to every admin account — owner or admin — of every restaurant whose account has not been deleted, so it is not limited to the owner: any of the restaurant's admins with a phone number on file receives it. An announcement is a service message about the platform, not marketing, and the marketing-consent rule described above does not apply to it — a restaurant owner is not asked to opt in to an announcement, and the platform carries no opt-out setting for one. When the server-wide admin-OTP skip is off, a staff account with a phone on file receives a WhatsApp sign-in code after the email-and-password step; an account with no phone skips that code. The authentication message body is blank in the delivery log described above.

When restaurant staff use the AI assistant, OrderScribe stores the conversation title, their message and the assistant's content/tool records, plus proposed or applied action inputs, diffs, results and undo data, and token/usage metering. Auto-translate stores the returned menu translations and a usage/charge row. Neither record family has an automatic deletion schedule today; what is sent to Anthropic is described under “Who receives your data”.

12. Children

The service is meant for people who can lawfully place an order. It is not directed at young children, and we do not knowingly collect their data.

13. Changes to this policy

If we change this policy, the new version will be posted on this page with an updated date at the top.

14. Contact

Questions or requests about your data: message us on WhatsApp at ‎+961 81 758 391 or email [email protected].