Privacy Policy

1. Operator, scope and draft status

The legal operator responsible for U-Turn is TBD, with company registration number and registered address TBD. The privacy contact and usable support channels are TBD. This draft describes data handled by the inspected application and distinguishes intended pilot controls from verified code behavior. It is not a statement that a particular production deployment, provider contract or legally approved privacy program is already in place.

The applicable legal basis for each processing purpose, required notices and provider disclosures must be confirmed through Palestinian legal review before launch. An order, partner relationship or broad consent is not blanket permission for every disclosure. Both language versions require that review; unresolved legal or commercial details remain TBD.

2. Customer and order information

U-Turn’s data model includes customer names, WhatsApp identifiers or phone numbers, language, delivery addresses, map pins and landmarks; order items, price snapshots, totals, status and timing; chat messages and attachments where supplied; payment references and status; and support, complaint and incident records. Data may be supplied by you, restaurant staff, a captain or an authorized support operator in connection with the service.

Do not include unnecessary sensitive information in order notes or chats. U-Turn should request only what is needed for the relevant purpose and explain any additional required information. These pages do not confirm collection of card numbers or card security codes; the inspected payment adapter is a logging/sandbox adapter. Real payment processing, the provider and its card-data responsibilities must be confirmed before being offered.

3. Restaurant staff and captain records

Restaurant staff records include account identity and contact details, branch memberships, roles, authentication-related records and actions taken in the dashboard. Captain records include identity and verification documents, licence and vehicle details, availability and shift commitments, device and push-token details, job activity, food advances, earnings, payout and reconciliation records, and location updates submitted while using the captain service.

Verification and financial records should be available only to authorized people who need them for the relevant task. Proposed access limits do not themselves prove that every deployment, export or internal role is appropriately restricted; a deployment-specific access and provider review remains necessary before launch.

4. Purposes and necessary access

Operational purposes are receiving and fulfilling orders, checking serviceability, dispatching suitable captains, showing tracking and order status, communicating necessary updates, handling support and incidents, preventing fraud and misuse, authenticating accounts, securing the service, reconciling payments and maintaining required records. Authorized staff may need customer, restaurant, captain and financial information to perform those tasks, subject to their duties and permissions.

The permitted legal basis, necessity and retention for each purpose require confirmation; this draft does not treat consent as the basis for everything. Optional marketing requires separate, informed permission where lawful and must not be made a condition of ordering. No marketing-permission workflow is introduced by these pages.

5. Restaurant access: intended and verified limits

The intended restaurant access is the minimum needed to prepare and hand over its own orders, with a customer name and relevant order details. The inspected branch-order serializer omits the customer’s phone and precise delivery pin for delivery orders and supplies a first name; pickup records can include the customer’s full name and phone for identification or contact. Other features, exports and deployment-specific permissions still require review; this is not a guarantee that every possible data path has been audited.

6. Captain access and a post-completion location gap

The intended policy is to give the assigned captain only the contact and delivery information needed for an active job, and to restrict it afterward. The inspected captain-job view hides the customer’s phone once the relevant assignment is no longer active or the order is closed. It does not use that same condition to hide the precise drop-off coordinates and landmark, and a captain with a past assignment can request that job. Precise location access after completion is therefore an implementation gap; removal of that access is a draft commitment requiring implementation and verification before it can be promised.

Captains must not reuse customer details for unrelated contact or marketing. This use restriction is separate from technical access controls. Masked calling or fully anonymous communication has not been verified and is not promised. Support may need continued access for a genuine incident, subject to appropriate authority and review.

7. Location, tracking and incident evidence

Customer pins help check delivery availability, quote distance-based fees and guide delivery. Captain positions support dispatch, operational tracking and investigation of a reported attempt. Location records, timestamps, contact attempts, waiting time, order and payment status, and relevant explanations may be reviewed by a person when deciding a disputed incident. Records can be incomplete or inaccurate and must not be treated as conclusive proof of fault.

A contact-attempt log does not necessarily mean call audio was recorded; call-audio recording has not been verified in this implementation. Any future recording would need its own lawful basis, notice, access and retention arrangements before introduction. A tracking link’s expiry restricts the link’s use; it is not deletion of the order, address, location snapshot or associated records.

8. Providers, sharing and processing locations

Service delivery may require necessary disclosures to the relevant restaurant, captain and authorized staff, and to contracted messaging, hosting, storage, mapping or payment services that are actually used. Production provider identities, their specific roles, processing locations and international-transfer arrangements are TBD and must be verified and disclosed before launch. The presence of an integration or provider name in code is not proof that a production contract or lawful sharing arrangement exists.

Provider sharing requires Palestinian legal review. Blanket consent must not be assumed to make all disclosures lawful. Any required contractual safeguards, transfer mechanism or additional notice remains TBD until verified; no specific international-transfer safeguard is promised here. Disclosures to authorities must have an applicable lawful basis and be limited to what is required.

9. Automation, messages and human review

The software includes automated order, timer, dispatch and notification functions. This draft does not confirm that a live AI processor receives chat content, that messages are anonymized before processing, or that a production model provider is configured. If AI processing is introduced, its purposes, provider, data fields, lawful basis, human-review controls, processing location and retention must be confirmed and disclosed first; unresolved values are TBD.

Under the proposed policy, disputed delivery incidents, restrictions and loss claims receive human review and an opportunity to explain errors. The current restriction flow differs from the graduated customer policy, so these pages do not promise that every proposed review step is already automated or enforced. Access to support and competent complaint bodies must remain available.

10. Retention and the proposed location-history period

The proposed pilot retention for detailed captain location history is 30 days, subject to Palestinian legal and operational approval. The repository contains a configurable location-point purge job with a 30-day default; this alone does not verify that the job is enabled, successfully running or sufficient for every deployment. The approved retention and deletion checks must be confirmed before launch.

Retention periods for customer and address records, chats, orders, financial and reconciliation records, incidents, verification documents, account-security records and backups are TBD. Some records may need lawful retention for accounting, disputes, security or other required purposes. Deleting detailed location points does not necessarily remove order addresses, coordinate snapshots, exports, other records or backups; each needs a separate retention and access assessment. Tracking-link expiry is not a retention schedule.

11. Access, correction, deletion and optional consent

You may request access to your information, correction of inaccurate information, deletion where appropriate, and withdrawal of optional marketing or other optional consent. Contact the privacy contact (TBD); the operational request channel and response period are TBD and must be published before launch. Identity checks should be proportionate and should not require unnecessary documents.

A request is subject to applicable law and justified retention, such as an unresolved claim or required financial records. U-Turn should explain what it can act on, what it must retain, the reason and any review route. Withdrawing optional consent does not undo processing already lawfully completed and must not be treated as withdrawal from unrelated necessary service processing. These pages do not add a self-service deletion mechanism.

12. Security, cookies and incident response

The inspected application includes authenticated sessions, role and branch checks, password hashing, audit records and signed access for some stored files. The dashboard uses session cookies and stores locale and theme preferences. These are specific implementation features, not a guarantee that all security controls, production encryption, hosting or provider arrangements have been independently audited. No system can guarantee absolute security.

Limit access to necessary authorized users, protect account credentials and report suspected misuse or disclosure. Incident-response contacts, notification procedures and any legally required timelines must be confirmed; unresolved values are TBD. Do not assume that the absence of a separate cookie banner means optional tracking or marketing consent has been obtained. This feature adds no marketing tracker or analytics integration.

13. Complaints and policy updates

Ask for a person to review a privacy concern through the privacy contact or support channels (TBD). Response periods and the specific applicable complaint channels remain TBD pending Palestinian legal review. Internal review does not prevent a complaint to competent authorities or a claim before a competent court. No provision limits a right that applicable law requires U-Turn to respect.

Material changes must be communicated before taking effect and, where required, be supported by renewed valid consent or acceptance. The versioning note below applies to these pilot review documents; it is not permission to expand data uses retroactively or replace any separate privacy notice or legal basis required for a new purpose.