Privacy Policy

Authorized company administrators can view their own company’s team orders, including dishes and portions, order/payment status, total order value, company and member shares, pending and final amounts, and allocations in retained historical refund records. Unconfirmed, failed or cancelled payment attempts are distinguished from confirmed orders and do not increase production quantities. This view does not disclose card metadata, personal payment profiles, billing addresses or identity numbers. Member payments do not become company debt; the view itself executes no charge or refund. It reads existing meal and payment records without adding a retention period or service provider.

1. Controller

The data controller for iştebu! yemek services is POİEX TEKNOLOJİ LİMİTED ŞİRKETİ. Company contact details are listed on the Company Information page.

Who is the controller for your data?

POİEX is also the independent data controller for the personal data of people who use iştebu! yemek — not the organization you belong to (your employer, school, etc.). POİEX determines the purposes and means of processing this data under KVKK Article 3 in its own name. The organization you belong to runs a separate service relationship through iştebu! yemek and acts as its own controller only for its own processes. KVKK Article 11 rights concerning this data on iştebu! yemek are exercised directly against POİEX at privacy@istebuyemek.com.

2. Data we process

When you report missing, substituted, or wrong food for an order, a verified link to your own order and the issue type are added to the support record and included in your data export. Only you and authorized POİEX operators can access the record. It does not itself create a refund, additional charge, or payout approval. When personal-data erasure is processed, the order link is removed along with the user link; the platform does not embed that link in retained message text.

For newly published dish-priced daily plans, selected dishes and portion counts are retained with the service-day prices, funded meal allowance, visibility preference and discounts. The organization administrator decides whether eaters see the allowance amount and dish prices; the limit is enforced even when amounts are hidden. Authorized kitchen and organization staff use these orders for production, delivery and invoice reconciliation. Missing-delivery and gift adjustments identify the individual order or bulk-order box. Existing orders are not converted. This feature does not create a personal wallet or employee card payment; existing meal and billing retention periods apply.

For dish-based pricing, the Seller enters the restaurant portion price including VAT and chooses the discount for every headcount range, including the first. The discounted amount is the Seller payout; the platform service fee is added on top. These price and discount changes apply to subsequently published plans; existing plan price snapshots remain unchanged.

New institution contribution settings retain each member’s daily or calendar-month cap, pending commitments and settled institution spending. Authorized institution admins can export member-level monthly usage and unused monthly entitlement for their own external meal-card loading decisions. Pending amounts are separate from settled spending. Unused entitlement is not cash, a wallet balance or automatic carry-over. Card checkout has separate activation requirements; existing meal and billing retention periods remain unchanged.

When a dish-based payment is finalized, the selected quantity, final unit price and caterer entitlement are retained for billing and transaction verification. Later price changes or substitutions do not reprice this evidence. Retaining these records does not itself initiate a refund.

Institution administrators may confirm a meal-date payment-model change after reviewing affected orders. The actor, effective date, contribution policy, affected order/payment references and cancellation state are recorded. Open selections and holds must be cancelled before the new policy applies; uncertain bank results remain pending. Affected users receive an in-app notice and must select again. Captured or past-deadline orders remain unchanged, and entitlement already used within the period is not reset. Existing meal and billing legal bases and retention periods apply.

Delivery issue cases retain the support reference, reported and approved dish quantities, reason, decision maker, funding shares, bank outcome, offset history and decision/result notices. Company bank repayments additionally retain the completed transfer amount, date, verified company IBAN, bank reference and review note. Existing financial-record retention rules apply; no new processor or retention period is introduced. The reporting and refund workflow is described in Delivery and Returns.

Authorized operations staff may retain a payment link, provider or bank reference, review note, independently observed amount when available, and review history as immutable evidence of an external adjustment. Open cases and confirmed external adjustments block new payout approval and period close; these records execute no bank refund, allocate no amounts between funding sources and do not automatically correct reports. Later evidence cannot reverse a provider approval already initiated. Your data export includes your external-case reference, state, observed amount and audit times, excluding internal notes and operator identities. Existing financial-record retention and payment-profile erasure rules apply. Period confirmation retains frozen institution, member and gift totals and the confirming operator; later differences are reported without changing that record. Payment source does not automatically classify an invoice or receipt.

Confirmed capture, a final charge below the hold, and confirmed cancellation of an unnecessary hold on an institution-funded order create an in-app notice only for the payer account. It contains the payment link, date and frozen amounts; an unknown bank outcome creates no success notice. Inbox text is available in Turkish or English. Current native installations with notification permission may receive one push in their installation language showing the order date, original hold and confirmed charge; a lower charge includes the uncharged difference in the same notice. Confirmed hold cancellation shows the cancelled amount and states that no charge was made. This content passes through the existing FCM/APNs providers and may appear on the lock screen depending on device settings; it contains no names, payment profiles or card details. The payment link requires sign-in. These events do not use SMS. Pending payment push expires after 7 days; terminal outbox records follow the existing 90-day technical retention window and personal inbox copies follow account-data erasure.

Authorized operations staff may search existing records by name, phone or transaction/invoice reference for support and financial reconciliation. Search text and results are not stored as search history. Results contain names and record references linking to existing authorized details, without exposing payment profiles, saved cards, identity numbers or phone lists. Institution administrators receive no new access and no new service provider is added.

The AI-assisted dish workspace processes, linked to the acting authorized Seller-admin account, dish names and descriptions, recipe ingredient names and grams, recipe chat, assistant responses, response scope/model/prompt/provider-request metadata, and successive draft versions. OpenAI produces energy, protein, carbohydrate, and fat values, food labels, and an illustrative dish image. This field is for dish/product information only; the admin is instructed not to enter information about a person or child, health data, or other sensitive personal data. The working draft and history are stored immediately. The admin may inspect and edit the draft; the “Save dishes” action applies it to the catalog.

An in-app support thread contains its category and status, user and staff messages, source screen, app version, interface language, optional active-organization context, and private notes used by authorized POİEX operators. A message may include up to three JPEG, PNG, or WebP images together with filename, content type, and size. Images are re-encoded without cropping first on the device and then by the server, which validates the actual image bytes and removes EXIF/GPS metadata. Incomplete uploads are deleted from private Cloudflare R2 storage within one day; submitted images are held under a 30 MB total per-user support-image limit and opened only through short-lived signed links. The thread and public replies are visible only to you and authorized POİEX operators, not organization admins or Sellers. No email copy is created. A generic native push may announce a reply and link to the thread, but never contains the reply text.

The organization-lifecycle audit records the company’s onboarding, active, or inactive status; transition and timestamp; the acting POİEX operator, company admin, or Seller admin who activates the relationship; deactivation reason; and an operator note of up to 500 characters. If deactivation encounters open relationships, services, current/future assignments, or orders, the operator sees impact counts; a separately confirmed cleanup closes or removes those records atomically and records the removed counts in the audit. Assignments included in a settlement or containing a review are never removed through this flow. The note must not contain child, health, dietary, allergy, or other sensitive personal data.

Authorized operations staff may grant or revoke startup permission for companies before invoice information is complete and for Sellers before invoice information and document approvals are complete. A Seller with permission can appear in the marketplace, connect with companies and manage menus and orders; document verification statuses remain unchanged. The organization, permission action, acting account, optional operator note and timestamp are retained within the existing operational authorization audit. Permission automatically closes with a recorded system event when company invoice information is completed or when the Seller’s invoice information, payout IBAN and both document approvals are complete. Permission does not replace billing or payment prerequisites and does not cancel existing connections or orders.

For aggregate kitchen-demand forecasting, recent individual meal selections and admitted personally paid or institution-contribution-funded Menu/Alakart orders, each beneficiary’s roster join/end timestamps, and successful unique join-invite SMS sends from the preceding 96 hours are evaluated on demand. Failed or older sends and phones already represented by the matching active eater/guardian record are excluded. Person-level intermediate results exist only transiently during the request: they are not stored or shown to the Seller. The Seller sees only aggregate kitchen and dish quantities, never the phone numbers.

For meal-price estimates, authorized beneficiaries see only the aggregate participant count for their own company/kitchen/service group and the corresponding estimated price. The estimate uses aggregate orders from the last seven completed service dates; with insufficient history it uses the initial expected service headcount, or available service-day history when no expectation exists. Current committed orders provide a lower bound. The calculation source and sample size are shown; other beneficiaries’ identities and individual order histories are not disclosed. This estimate does not determine a charge. The initial price shown when ordering is retained under existing order/pricing record handling and may be compared with the final amount once pricing is finalized.

Only an active admin of the same organization can use People management to view active or ended organization enrollments for employees, admins, guardians, and students, including the record’s system creation and optional end timestamps, role, contact details, guardian relationship, and class/distribution group. When an account-backed meal beneficiary’s active membership in that organization ends, the active beneficiary enrollment also ends and its pre-deadline future selections are cancelled; the ended membership/beneficiary enrollment and historical meal and cost records remain under their existing audit, billing, and dispute-retention terms. Supported admin flows retain the acting user when available, the lifecycle source, and the prior enrollment link for a new or ended student meal enrollment; no actor is inferred retroactively for legacy records. A student’s ended and current enrollments share the child profile that preserves organization-scoped meal and cost history continuity. Person and student detail may show that organization’s weekly meals and costs; ratings, review labels, and review text are never attributed or shown there. This view creates no separate analytics or person-history record.

A school-family/student departure is separately previewed before confirmation, showing the students, guardian memberships, and pre-deadline future selections affected. Family confirmation atomically ends the selected member and every active student they guard in that school, together with local guardian links. Student confirmation reconciles each guardian’s remaining scope: another active student preserves guardian permission; an admin or active staff/self-eater keeps membership without guardian permission; otherwise the school membership ends. Pending child-scoped guardian invitations expire. Deadline-closed selections, historical meal/cost records, user accounts, other-organization memberships, and global child-profile guardian links remain.

For phone-based enrollment, the current People flow lets a company or school admin add one person or process up to 2,000 Excel rows in the browser, choosing “Add new people” or “Update full list”; the Excel file is not uploaded and the raw list is not retained. The single-person dialog first searches active and ended students, staff, or employees in the same organization; selecting a registered student shows current guardians and permits several new guardians in one submission. A school admin selects student/guardian and staff scopes separately, and a full-list sync in one scope does not affect the other. Company or school employees match by phone. Students match by whitespace-collapsed, Turkish-normalized full name, never by guardian phone. One exact name match is automatic; for duplicate names, the admin sees candidate class and active guardian names within their school and must choose—the system never guesses. In single-person enrollment, submitting an exact new or selected record validates a server state token and applies atomically without a separate second confirmation screen; a similar or ambiguous student match pauses for comparison and explicit confirmation. In the Excel flow, the preview shows every create, link, class/group update, roster ending, guardian-permission or membership effect, future-selection cancellation, and each masked SMS recipient with the exact rendered message before one atomic apply; unresolved or invalid rows block apply. Once applied, the membership and guardian relationship become active immediately. The SMS is informational, not an acceptance or authorization gate. A newly active membership receives the existing no-code login notice with the organization name, https://istebuyemek.com/app, and same-phone sign-in instruction; an existing active school member newly linked as guardian receives a relationship notice. The local outbox retains recipient, rendered body, queue/send state, provider message id or last error; queue/provider acceptance is not a handset delivery receipt. Add-only never removes a missing person. Full-list reconciliation ends missing active student/employee organization enrollments and cancels their open future selections. Local active guardian relationships of students leaving the roster end, while additional guardians of students who remain active survive even when omitted from the upload. An active student cannot be left without a guardian: guardians cannot remove children, and a school admin may remove one guardian only while another remains or may end the student. User accounts, memberships in other organizations, and historical records remain. Active admins are protected from staff and membership removal.

We process account and role data, phone-based login records, meal selections, cancellation and bulk-order records, delivery and billing-period data, invoice legal name, tax identifier, tax office, billing address, Seller payout IBAN, order totals, and the menu/assignment pricing snapshot (payout including VAT, effective PHB, Buyer total, VAT/fee components, and formula version), food business registration number and verification status, the Seller’s two verification documents (tax certificate and food business registration certificate) which — like the food registration number — are Seller compliance data stored in a private bucket, read only by our reviewer via short-lived links, and not disclosed to organizations, invoice number and evidence, payment-declaration and settlement/collection/payout records, and the in-app, push or SMS-fallback channel state for an invoice-ready notification. We also process support and privacy-rights messages, ratings and sentiment labels. A 1–3 star rating must include a negative label or non-blank note; 4–5 stars require neither. The same submission may contain a fixed delivery/service issue and an optional service note. The actual submitting account is recorded separately from the eater, so a guardian who submits for a child remains the submitting account; an account-less QR submission has no such link. Free-text dish and service notes are shared with the Seller and shown back to the submitter, but never to organization admins; because the text can identify the writer, the app gives this warning before entry. We also process in-app product feedback you submit about the application itself, uploaded media, language and cookie preferences, backup records, cron monitoring metadata, masked diagnostic events, opt-in analytics data, and school meal-coordination data described below.

Meal-operation records include explicit selections, their source, not-eating choices and the authorized actor, bulk quantities, delivery days and retained historical automatic-order records. Automatic individual ordering and percentage-based extra-meal ordering have been removed. The system creates no new orders for people who have not selected a meal or from an extra-meal percentage. Authorized users may still make explicit selections and manual bulk orders. Previously created orders, their sources, policy history and finalization records are retained; this change does not cancel existing orders or their billing amounts. The existing meal-coordination legal bases, recipients and retention periods continue to apply.

For pre-deadline draft printing, an authorized Seller admin may view and print the current named delivery roster and package counts after acknowledging that the list can change. The screen and every physical output are marked DRAFT with the generation time and selection deadline. This access changes no existing data category, recipient, purpose, legal basis, or retention period.

When a visitor starts a WhatsApp conversation from the floating contact button, an audience-specific company, school or caterer contact page, or a corporate-meal service, sector or regional page, we process the sender’s phone number, the prefilled message’s service model, sector or requested area, conversation content, and our response records. The in-app school-referral variant additionally carries the referred school, city, and source organization; neither website variant nor the referral includes child data.

For an automatic or admin-confirmed meal-selection reminder we process the mode, organization, meal service and day, audience, recipient user, a current explicit not-eating choice, the first names of still-missing children in a guardian notification, the in-app title/body/deep link and any push state; an admin-confirmed send also records the acting admin and request identifier. Selection reminders do not use SMS.

For a delivery-terms change SMS we process the recipient user/phone, SMS-safety-normalized and length-bounded Seller and customer-organization names, rendered content carrying the current delivery and order-deadline times and the statement that existing meal selections did not change, queue/send state, provider message id, and last error.

On Android, if you accept the operating system’s one-message access prompt during login, the verification SMS is handed to the app only on the device. The app extracts the six-digit code and fills the login field; it does not retain the SMS body or send it to the iştebu! yemek backend. Refusal, cancellation, timeout, or an unavailable system service leaves manual code entry available. This transient processing rests on contract establishment/performance and legitimate interest in secure, usable account access; it is not used for marketing and creates no new off-device transfer.

For native app installations, including before sign-in, mobile live updates process the app identifier and version, native build, platform, operating-system version, an Android random UUID generated for the installation and stored in app preferences, Apple’s identifierForVendor (IDFV) on iOS, installed bundle identifier, update channel, live-update plugin version, and IP address. Names, phone numbers, meal data, and billing content are not sent through this update flow.

When a signed-in native user reaches the first usable app screen, the app first shows an in-app explanation and opens the operating-system notification prompt only if the user explicitly chooses to enable notifications. On Android versions without a notification runtime prompt, registration likewise starts only after that explicit choice. We process an encrypted FCM registration token, a random installation UUID, the account association, platform, app/native version and build, locale, time zone, and last refresh time only for users who enable notifications. A send carries the notification title, body, in-app link, and provider acceptance/error metadata. Each current installation may receive a generic, lock-screen-safe reminder for a same-day delivered meal that is still unrated; the notification contains no child, dish, or organization name. Topics, Firebase Analytics, and BigQuery delivery export are not enabled.

For a Seller team invitation we process the inviting admin, organization, invited affiliation-only member role, invitation status and creation/expiry/redemption/revocation times, and the redeeming or revoking account. The intended teammate’s phone is normalized only transiently to create a nonce-bound keyed match inside the 72-hour link. The SMS includes a sanitized, length-bounded form of the inviting Seller’s display name and the invitation link; the platform persists neither the raw phone, create-request ID, phone-authentication tag, nor SMS body. The server stores the SHA-256 digest of the invite token, a boolean recording whether the synchronous SMS send call succeeded, and the organization, creator/redeemer/revoker, status, and timestamp audit. The boolean is not a handset delivery receipt.

After redemption, an active Seller team member’s name, verified phone, Seller organization, affiliation-only member role, membership status and timestamps, OTP/session records, and redeemer-side invitation audit are processed. This membership grants no operational or administrative access unless a current admin separately promotes the member.

A Seller admin may instead add a teammate directly by phone. This creates or reuses the account and creates an affiliation-only membership immediately, before the person’s first sign-in and without invitation acceptance. We process the account phone, Seller organization, member role and lifecycle, creation time, and acting admin, and queue a no-code login SMS naming the Seller and linking to the app. SMS delivery is not a condition for membership. The person signs in with OTP on their own phone; admin access still requires a separate promotion. No separate phone list is retained; account, membership, and SMS queue records follow their existing lifecycles.

A school creates and controls each student’s organization-scoped meal enrollment. A guardian membership or permission never copies that student into another organization. On older clients, the first guardian may share an 8-character, single-use code valid for 72 hours; redemption links the second guardian only to the school and exact child named by the code, without a separate child-consent gate. Each organization admin sees only that organization’s enrollment and meal operations; a Seller sees only the minimum data needed for the meal it serves in that organization.

When an authorized POİEX operator deletes an inaccurate individual or bulk order, we retain an audit containing the acting operator and the deleted order’s date, meal service, recipient/orderer, quantity, menu, and dishes. Reviewed or invoice-settled orders cannot be deleted through this operation.

For a possible student match, when one name is a contiguous part of the other and the surnames match, the admin compares the current and Excel child names, class, and active guardian names with masked phones, then explicitly chooses same or different. An exact guardian name-and-phone match is recommendation evidence only, never an automatic merge. The admin may keep the current child name or explicitly update it to the Turkish-title-cased Excel name. An unresolved possible match is protected from full-list removal.

An authorized Seller admin may select still-open negative-label occurrences, one- to three-star free-text reviews, and fixed delivery/service issues and publish one Seller response. The response is linked immutably to the selected feedback; the original submission is unchanged. Each active account that actually submitted the feedback — including a guardian submitting for a child — receives at most one in-app notification for the same action and customer organization. The detail shows only that submitter’s covered dish and service feedback and records the read time. Account-less QR and anonymous bulk-box submissions cannot receive a notification. A Seller may instead close selected signals internally as requiring no action; that resolution sends no notification. This processing rests on legitimate interest in improving and evidencing service quality.

A feedback-action push uses generic lock-screen copy: the Seller response, review text, dish, child, and organization names are omitted from the payload. The in-app link routes to the authenticated notification detail.

Optional delivery location

Confirming a point sends its coordinates once to Google Geocoding for a province, district and street-address suggestion. You can edit the suggestion in the form; it is stored persistently as the company address only when you save the form. Viewing a saved address does not trigger another lookup. Manual entry remains available if the lookup fails. The map opens at the saved delivery point first. Without a point, the written company address is sent to Google Geocoding to find its approximate location. Device location is requested only if neither exists, or through “Go to my location”; a permitted sample recenters the map without a separate device marker. Search text is sent to Google Places Autocomplete after a short typing pause or when Search is pressed. Selecting a suggestion requests only its location through Place Details. Suggestion lists and search session information remain only in the open picker and are not added to the company record. A manually edited address is sent to Google Geocoding when Find on map is pressed. The selected address can be reviewed and edited in the form; manual address entry remains available.

A company administrator can enter the delivery address and mark its entrance on a map within the same field. Entrance instructions entered in the address field are part of the company address and visible to members and caterers who can access that address. The confirmed latitude, longitude and address at confirmation are stored separately on the organization. These precise point details are visible only to company administrators and authorized users of actively linked caterers, and withheld from members and pending or ended counterparties. An address change requires reconfirmation. Processing serves the requested meal-delivery contract within the existing meal-coordination purpose (KVKK Article 5/2(c)).

Opening the map without a saved point or written address, or pressing “Go to my location”, requests browser or OS location permission; an existing permission may allow the position to be obtained without another prompt. A one-time device position centers the open map; there is no background tracking. Manual map selection remains available without this permission. The device position reaches our server only if separately confirmed as the entrance and saved with the company form. The address and point remain until the administrator replaces or removes them or the organization record is deleted. Separate entrance notes saved in earlier versions are preserved, cannot be edited in this form, and remain visible only to company administrators and authorized users of actively linked caterers; infrastructure backups follow the existing 30-day rotation. Device permission is not treated as recorded KVKK explicit consent.

Opening the picker sends IP/browser information and the viewed map area to Google Maps Platform (Google LLC; United States and global infrastructure). If requested, the device position is supplied as the map center. This integration does not supply company identifiers, legacy separate entrance notes, accounts or meal records to Google. The written address and user-submitted search text may include entrance details entered by the administrator. Google’s processing and retention follow its Privacy Policy and Maps terms; POIEX has not verified a provider retention period. The KVKK Article 9 cross-border transfer arrangement for Google Maps has not yet been completed. The caterer’s directions link supplies the coordinates to the external Google Maps app or website.

During setup, a kitchen administrator enters official business details and a billing address, then chooses whether the kitchen uses the same or a different address. A separate kitchen address can be selected through the optional Google Maps picker or its manual-entry fallback. Opening the picker sends IP/browser information, the viewed area and the written kitchen address for initial positioning to Google; search text is sent to Places. Device positioning follows the existing optional picker behavior; there is no background tracking. Only the administrator-confirmed province, district and address text are stored on saving the revision-bound business section; this form does not persist kitchen coordinates, raw Google responses or search suggestions. Map selection does not change the separate billing address; choosing the same address copies billing fields into the kitchen address on saving. The existing business-verification purposes and retention apply. The previously disclosed Google Maps cross-border transfer and provider-retention gaps remain unchanged.

Android crash and unresponsive-app reports are sent to the existing Sentry service, including before sign-in and before the app screen opens. They contain the error type and technical stack frames, application release and build number, debug mapping identifier, device manufacturer/model/architecture and operating-system version. These native reports exclude account or organization identifiers, installation identifiers, device names, request URLs, free-text exception messages, screenshots and session replay. The existing 90-day diagnostic retention period applies.

3. Purposes and processors

The AI-assisted dish draft is processed for contract performance and legitimate interest in accurate and efficient Seller-catalog operations, support and troubleshooting, and longitudinal product-quality evaluation. Recipe content and chat are sent to the OpenAI API; no web search is enabled and text responses are requested with store=false. For each dish, the AI is instructed to assess the recipe and labels together in its first proposal and correct clear contradictions in the draft; it can also correct errors reported by the user in chat. Before a targeted correction, the current workspace identifies the affected dishes and fields, leaves unrelated draft information unchanged, and asks for clarification if the target is ambiguous. The Seller admin can inspect and edit dish information before saving. The current interface asks for no separate allergen or diet acknowledgement, and “Save dishes” writes directly to the catalog. The AI receives every recipe ingredient and all known gram amounts, including ingredients hidden from customers. The current portion flow stores the cooked serving weight and AI-estimated nutrition per 100 g of cooked food. Serving nutrition is scaled from that record. When portion suggestions are selected, AI can propose missing cooked serving weight; otherwise the Seller enters it. Stored density is retained while the recipe is unchanged and reassessed after recipe changes. Customers see the serving weight and a notice that nutrition values are estimates. In the current assisted flow, selected options can propose a recipe from a dish name and fill missing raw ingredient weights. Fill mode preserves existing values; selected information can be regenerated globally or per dish. Quantities-only mode preserves the ingredient list. Image generation starts off; edits do not automatically generate another image. Input, generation preferences and baseline catalog values are retained with draft history. Supported older versions keep unknown grams blank. Missing amounts that significantly affect energy or macronutrients are requested in chat and must be clarified before catalog save. Minor unknown amounts may remain blank alongside approximate nutrition and the assessment reason in the draft. After saving, the Seller controls which ingredient names and known gram amounts customers can see. The current flow saves the quantity-assessed draft without a second AI label-conflict review. Supported older app versions retain their existing confirmation and review flows during the transition. OpenAI is an overseas provider for this flow; its current transfer status is published on Sub-processors. When nutrition generation is selected, estimates use standard Turkish catering recipes, ingredient composition and cooking yield without requiring separate permission to make assumptions; the draft records those assumptions. Nutrition completion also fills missing recipe and serving information while preserving supplied values. Incomplete nutrition receives one correction attempt; if still incomplete, the operation is reported as failed. Generated descriptions, ingredient names and assessment text are instructed to use Turkish.

Organization-lifecycle records keep abandoned company accounts out of operational action queues, prevent unsafe activity while inactive, support an explicit return to onboarding, and preserve an accountable transition history. Processing rests on contract performance and legitimate interest in accurate, secure, and accountable service operations.

The distribution-group name is free text; the organization admin must not enter health, allergy, or dietary information in it.

An organization admin may assign a beneficiary to one distribution group, such as a class, age band, or department, to make handout easier. Names or phone numbers pasted for bulk assignment are compared transiently only with active beneficiaries in that organization; the raw list is not retained as a separate record. Exact unique matches, duplicates, missing people, and possible same-name matches are shown to the admin before any change. When active beneficiaries share a name, the admin also sees the candidates’ current group and active guardian names only in this preview to select the intended child. “Add listed people” skips unresolved rows and changes only matched people. “This is the full group list” cannot be applied until every row is resolved; once applied, it clears only the current group value of people absent from the list and does not change organization enrollment, guardianship, meal selections, headcount, billing, or history. Pasted phone numbers and guardian names shown for matching are not disclosed to the Seller. The current group appears with the name only in the authorized Seller print view and on the physical label; it is not derived from date of birth, must not be used for health or dietary information, is not copied into meal or billing history, and is not shown on the public QR page.

Aggregate kitchen-demand forecasting is part of corporate meal coordination and headcount operations. It rests on service performance, pre-contractual onboarding, and reliable-operation legitimate interest for adults, prospective members, and organization-managed student rosters.

When a Seller changes the delivery time or order-deadline offset on an active link, the system creates an in-app notification for active members of the customer organization. A current native installation receives push; because the change is critical, Vatansms is used only as fallback when that recipient has no current push installation. Push and SMS are never both sent for the same recipient and event. Channel records follow the retention terms of the related meal-coordination records.

Data is used for secure login, corporate meal coordination, headcount, delivery, invoicing, collection, Seller payout settlement, support, privacy-rights handling, service quality, media storage, backup and disaster recovery, security, cron monitoring, external uptime monitoring, error monitoring, and optional analytics. Current starter processors include Hetzner, Cloudflare, Cloudflare R2, Google Workspace, Sentry, Healthchecks.io, UptimeRobot, Microsoft Clarity, Vatansms, Paraşüt (e-invoicing/accounting), and WhatsApp/Meta. iyzico is actively used for card payments and seller submerchant/payout processing. Buyer identity, contact, billing-address and transaction details required for payment are sent to iyzico; seller registration sends business, authorized-contact, tax and IBAN details, including the owner’s Turkish identity number for a sole proprietorship. Card details are entered on iyzico’s payment screen; POİEX does not store full card numbers or security codes. If the user chooses card storage, POİEX stores only encrypted provider card keys and masked card details. See Sub-processors for the current full list and the KVKK Article 9 transfer mechanisms. Organization admins access the operational data of their own organization (headcount, beneficiary selections — including the specific dishes each member chose for the day, never the price — name/phone, billing records). Sellers (food-service sellers) receive only the operational data needed to produce and deliver the meal: daily headcount, menu assignments, bulk-order line items, delivery location, the name needed for a beneficiary to find their own meal on the delivery label, and the current distribution group assigned by the organization admin, if any. The label shows the beneficiary’s first and last name plus the current distribution group, so boxes can be routed to the correct person and group at handout. The beneficiary’s phone number and email address are not shared with Sellers. The QR code on the delivery label contains an unguessable, unique link to that meal’s info page; the page opens without login for whoever holds the link, shows no more personal data than what is already printed on the label (first name, that day’s meal selection, the Seller’s name, date, and delivery time) plus the dishes’ declared food information (description, allergens, dietary tags, special warnings, energy — product information, not personal data), and allows a one-time rating of the meal for 24 hours after delivery. It contains no price, phone number, or other contact details. This 24-hour upper bound applies only to the unauthenticated QR link; signed-in users and guardians may later rate any delivered, previously-unreviewed own or child meal in the app, still only once. The QR on the box label of a bulk-ordered meal works the same way; that page shows no beneficiary identity — only the ordering organization’s name and that day’s dishes — and allows one rating per box without login. A bulk-box rating is linked to no person, so it carries no personal data and no identity link to erase. So the Seller can issue the food invoice, the billing identity of the organization it is actively linked to (legal name, tax identifier, tax office, billing address) is disclosed to that Seller; the intermediation invoice and collection run through POİEX. Once a Seller’s verification is complete, its seller identifying information (trade title and tax identifier/VKN) is shown publicly on the marketplace and to actively linked client organizations in the app, as required by the seller-transparency obligation under Law No. 6563 and Article 5 of the E-Commerce Regulation; the Seller’s food business registration number remains internal compliance data and is not disclosed to clients. When a parent/guardian uses the in-app card for a school referral, the prefilled message they choose to send is transported over WhatsApp/Meta infrastructure outside Turkey; the legal basis is pre-contractual steps at the data subject’s own request and legitimate interest in answering inbound sales inquiries (KVKK Article 5/2-c and 5/2-f). Because the parent/guardian initiates the contact, no explicit consent is taken and this is not an unsolicited commercial electronic message under Law No. 6563 / İYS; no child data is shared, and any later marketing message back to the parent/guardian would require separate explicit consent.

Healthchecks.io receives only production scheduled-job identifiers, environment, server IP address, heartbeat timestamps, and start/success/failure status. UptimeRobot probes only the public production health endpoint and records its URL, server IP address, probe time, HTTP/TLS status, and response time. Neither monitor receives account, meal, billing, or support content.

The floating contact button opens a generic prefilled message in the WhatsApp Business line. The company quote link and school and caterer demo links route to a contact page with the cross-border-transfer notice. Corporate-meal service, sector and regional pages show that notice beside a direct WhatsApp link; the prefilled message identifies only the relevant public service model, sector or requested area. Opening a link does not itself send the message. If you choose to send it, your phone number, message, and our replies transit WhatsApp/Meta infrastructure outside Turkey. This processing rests on pre-contractual steps at your request and legitimate interest in responding to the inbound sales inquiry (KVKK Article 5/2-c and 5/2-f). The same basis applies to the in-app school-referral card, which shares no child data. Because you initiate the contact, no explicit consent is taken and this is not an unsolicited commercial electronic message; unrelated later marketing requires separate explicit consent.

For an open meal service, the system creates an automatic in-app reminder normally 90 minutes before the deadline, only when at least 30 useful minutes remain and during the organization’s local 08:00–22:00 window; a natural target outside that window is moved to the preceding local 20:00 slot. Recipient authority and remaining tasks are rechecked before delivery. One account missing both its own and one or more children’s selections in the same organization, day and service receives one combined notification; distinct services are evaluated separately. An authorized organization admin may independently select self-eaters and guardians, preview and confirm another reminder. Current native installations receive push; selection reminders never use SMS.

When a Seller records a food-invoice PDF, the app creates a durable in-app notification and payment action for each active company admin. A current native installation receives push; because the event is critical, Vatansms is used only when that admin has no current push installation. Push and SMS are never both sent for the same admin and invoice. Channel state and the invoice-scoped idempotency key are retained as billing-related records.

Billing records also include the company admin’s designated-buyer declaration and the invoice’s withholding rate, code and threshold, withheld VAT, and bank-payable amount. The declaration is off by default and applies only to reconciliations that have not yet been invoiced. For food invoices dated in 2026, if the VAT-inclusive total of the completed weeks selected by the Seller for one invoice exceeds TRY 12,000, the system freezes the 5/10 rate, food-service withholding code 604, withheld VAT, and bank-payable amount on the invoice and each week. The invoice gross does not change: the Buyer pays gross less withheld VAT through the bank channel and declares/pays the withheld part through VAT 2. A later declaration change does not rewrite an issued invoice, collection, or payout record; a withholding invoice is blocked until the threshold for a new tax year is configured.

After an EFT/bank transfer, a company admin may record the payment date and an optional receipt in the app. The reporting account and report timestamp are recorded automatically; an uploaded receipt is stored in private Cloudflare R2 object storage and opened only through a short-lived authorized link. This is an operational bank-verification signal, not confirmation of collection, debt discharge, or authorization of the Seller payout. If a declaration does not match the bank record, its rejection time, acting account, and reason are retained with the prior declaration and reporting is opened again.

Capawesome Cloud (Genz IT Solutions GmbH) receives only the technical update-delivery data listed above to check native compatibility, deliver signed bundles, measure adoption, diagnose delivery, and support rollback. The EU endpoint is configured. Capawesome operates from Germany and uses some United States sub-processors; the KVKK Article 9 safeguard for this transfer is not yet completed. This processing rests on pre-contractual steps before sign-in, contract performance for signed-in users, and legitimate interest in secure service delivery and continuity.

After the user signs in, completes any required welcome steps, and reaches the first usable app screen, the app first shows an in-app explanation. The operating-system native push prompt opens only if the user chooses to enable notifications; on Android versions without a notification runtime prompt, registration is still created only after that explicit choice. Operational messages are stored in the in-app inbox and also sent by push when a current native installation exists. Routine events never use SMS. Critical events use Vatansms only as a fallback when the recipient has no current push installation, and the same event never sends both push and SMS. OTP, initial participation/invitation, organization enrollment and guardian-link flows remain SMS-primary. Google LLC’s Firebase Cloud Messaging receives the Firebase installation ID, target registration token, and notification payload; FCM uses APNs for iOS delivery. Processing rests on contract performance and legitimate interest in reliable service communication, and is not used for marketing. The KVKK Article 9 safeguard for the United States/global infrastructure transfer is not yet completed.

For each send, an authorized POİEX operator must choose exactly one of two audience modes: search active user accounts by name or phone and select one result with active organization context, or select one organization and at least one of its active eater, guardian and admin roles. The two modes cannot be combined. The search text and result list are not stored. The console previews deduplicated recipient/device counts and queues a durable in-app notification plus native push to current user-enabled installations after the operator records an internal reason and confirms that the message is operational rather than marketing. Phone-only recipients and SMS are not supported by this flow. The batch audit stores the message title/body, internal reason, actor, organization, audience flags, confirmation, counts and deduplication hashes but not the search or recipient list. Terminal push delivery rows are deleted after 90 days; inbox rows follow account erasure. Operators are instructed not to include child, health, allergy, dietary or other sensitive personal data.

The main legal-basis groups are: OTP/session records for account access and security under contract and legitimate interest; meal, delivery, headcount, and feedback records for service performance and quality; onboarding an intended Seller teammate as an affiliation-only member and maintaining that membership lifecycle under performance of the Seller service and pre-contractual onboarding, plus legitimate interest in secure, accountable team access; organization-managed student enrollment and guardian-proxy meal coordination under performance of the customer service and legitimate interest in an accurate, reliable school meal roster; support/demo messages for pre-contractual requests, contract performance, and customer-support legitimate interest; privacy-rights request records for legal obligation; and media uploads, backups, and diagnostics for service operation, security, and continuity.

Seller team-invitation creation and redemption requests are processed through the existing application infrastructure by Hetzner and Cloudflare. A sanitized, length-bounded form of the inviting Seller’s display name and the invitation link are sent with the target phone by SMS through the existing Vatansms processor; no new processor is used, and the platform does not persist the raw phone or rendered SMS body. The invitation record contains only a boolean indicating whether the synchronous SMS send call succeeded; this is not a handset delivery receipt. Only an account verified with the same phone can redeem the invitation. Redemption grants an affiliation-only member role with no menu, client, kitchen, delivery, billing, payout, or team-administration access; a current admin may grant admin access later through a separate role-promotion action.

Some infrastructure, storage, business email, monitoring, analytics, and messaging providers operate outside Turkey, primarily in Germany, the United States, Latvia, Slovakia, and Ireland. The KVKK Article 9 cross-border safeguards (Board adequacy decision, Standard Contractual Clauses notified to the Board within 5 business days, written undertaking, or Binding Corporate Rules) are currently being put in place for the affected processors. This page and the company’s records will be updated as each safeguard is recorded.

The product information on the QR meal page includes protein, carbohydrate, and fat values in addition to energy.

When new menus become visible and selectable in your organization, assignments within five minutes are combined into an automatic in-app announcement for the affected active meal beneficiaries and, for children, their active guardians. Each account is deduplicated per organization; there is no separate category toggle. Current native installations with operating-system notification permission receive push only while at least one announced meal remains open, unselected and not explicitly marked “not eating”. Quiet hours defer push to the next permitted organization-local time; menu visibility, selection deadlines, recipient authorization and remaining actionability are checked again before delivery. Push contains the meal date and selection deadline, without child, dish or organization names. It links to meal selection. Menu publication creates no SMS; the existing deadline SMS reminder runs separately. The account, organization, menu reference, meal date, deadline, in-app link and read time are processed for contract performance and reliable meal coordination. Announcements and read times are included in personal data exports, and personal inbox copies are removed through the existing account-data erasure process. Push delivery records retain the existing 90-day technical window; pending messages expire no later than the earliest relevant selection deadline still open at their scheduled send time.

Opening a notification or explicitly marking it read, individually or in bulk, records its first read time. Choosing or editing one of the announced meals in the app also acknowledges the corresponding menu announcement for the acting account only; automatic and operator-entered orders do not do this. Cancelling the meal later does not make the announcement unread again. In-app announcements do not expire with age; read entries remain in notification history and follow the same account-data erasure process.

4. Retention

The original paste, complete recipe chat, assistant-response metadata, and successive draft versions are currently retained in the application database without a scheduled deletion period, including after confirmation. The proportionality, definite retention period, and legal basis for this indefinite retention must be validated by counsel before production use. A confirmed recipe and generated dish fields remain on the dish until replaced or no longer needed for the active service relationship. Cost/usage audit rows separately keep provider request metadata and token/image counts. OpenAI may retain API inputs and outputs in default abuse-monitoring logs for up to 30 days unless law requires longer.

Organization-lifecycle audit records remain for the active customer period, or for 10 years when tied to billing, an access dispute, or a legal record.

Retention depends on purpose: refresh sessions last 7 days, cookie consent lasts 6 months, language preference lasts 1 year, error/replay diagnostics last 90 days, private database backups rotate after 30 days, cron monitoring records remain for the active Healthchecks.io account and may remain in provider backups for up to 2 months; external uptime records last 3 months on UptimeRobot Free and archived personal data may remain in provider backups for up to 180 days after service termination, Clarity analytics may last up to 13 months, active-customer support records and in-app product feedback are retained for the active customer period plus 2 years unless tied to legal or billing records, WhatsApp demo and school-referral inquiries are retained for 1 year, and invoice/legal records are retained for 10 years. A Seller team invitation is accepted by the server for no more than 72 hours; its browser-session copy lasts until redemption, explicit clearing, or the relevant tab session ends. The intended person’s raw phone and keyed match are not retained on the server; the authorization audit containing the organization, inviting/redeeming/revoking account, status, timestamps, and SMS send-success confirmation is retained for the active customer period, or for 10 years when tied to a billing, access-dispute, or legal record. The send-success confirmation is not a handset delivery receipt. Uploaded images remain until replaced, deleted, or no longer needed for the active service relationship. Where a dispute, security incident, or legal obligation applies, the relevant records may be retained for as long as necessary. These are the retention periods for which the relevant data is kept; in-app personal records are retained for the service relationship and statutory retention obligations, and are removed when that obligation ends or when you delete your account, on the schedule described in Section 5.

Capawesome delivery metadata and inactive update bundles are retained for 30, 60, or 90 days under the active plan (90 days maximum). After service termination, active-system data is deleted after a 30-day export period; immutable backups rotate within 30–90 days.

Our push registration is deleted when the app next opens or returns to the foreground after notification permission is disabled in operating-system settings, when the user logs out or closes the account, when the provider reports an invalid token, or when the registration has not refreshed for 30 days. Terminal push-outbox rows are deleted after 90 days. Firebase states that it retains Firebase installation IDs until the customer invokes its deletion API and removes them from live and backup systems within 180 days after that call.

5. Account deletion and what is kept afterwards

When account-erasure processing runs, image-attachment records from that user’s support threads and their private object-storage files are deleted. The de-identified thread text may remain under the support-history period because visual content cannot be reliably anonymized.

After lifecycle guards pass, starting the in-app “Delete my account” flow closes your account immediately: your sessions are revoked, the account can no longer be signed into, your active memberships are ended, in-progress (pre-deadline) meal selections are cancelled, your server-side native push registration is deleted, and your phone number is detached from the account so the same number can be reused for re-registration (the in-app record is replaced with an anonymous sentinel).

This account-closure flow also covers an active affiliation-only Seller team member and ends that Seller membership. The requirement to appoint another admin does not apply to this role; it applies only if the member was previously promoted and has become the organization’s sole active admin.

Your personal data is not yet destroyed at the moment of closure: your name, profile image (including the image file in object storage), the phone-number record, the technical fields on consent records (IP address, device), the content of SMS messages sent to you, the free-text notes you added to dish or service feedback, and the submitting-account link continue to be stored with access closed, for the purpose of proving that the underlying transactions were real and of establishing, exercising, or protecting a legal right (KVKK Article 5/2-e). This data is deleted or anonymized in the periodic destruction cycle following closure (within six months at the latest). If you want your data destroyed sooner, a KVKK Article 7 request to privacy@istebuyemek.com is completed within 30 days at the latest.

When the deletion is processed (on request or in the periodic destruction cycle): your name, phone number, profile image, and the technical fields on consent records are erased; the eater (meal-subject) name on your meal records is also stripped. Past meal selections, bulk orders, ratings, and billing-related records are retained — with the identity link cut — for the statutory retention period required by Vergi Usul Kanunu m. 253 and Türk Borçlar Kanunu m. 146. They appear as “Anonymous user” in any per-person historical view; aggregate billing, headcount, and quality analytics are unchanged. Consent records’ existence and timestamps are retained for audit; personal fields are scrubbed. Free-text product feedback you submitted about the application is retained to improve the product; when the deletion is processed the identity link is cut (the feedback’s link to your account is removed) and the text itself is kept. Free-text dish and service notes are scrubbed and the submitting-account link is cut; the structured star rating and fixed service issues remain anonymized.

The meal selections, ratings, and review notes entered for a child are kept for the service relationship. A guardian cannot remove the child, and the last guardian relationship of an active student cannot end. A school admin may remove one guardian while another remains or end the student enrollment. If an account is the sole guardian of an active student, in-app account closure or organization departure is refused until the school links another guardian or ends the student; a written KVKK Article 7 request remains separately processed within 30 days with school coordination. The guardian exercises the child’s KVKK rights and may write to privacy@istebuyemek.com; historical child-consent records are retained as audit history but no longer gate meal operations.

Guardian-initiated account closure or school departure remains subject to the existing lifecycle guard while the account is an active student’s sole guardian. A school admin may instead complete the family departure through the impact preview above without leaving an active student guardianless; this does not erase the child’s identity and does not replace the written KVKK Article 7 process.

If you are the sole active admin of an organization, the deletion may be refused until another admin is appointed. This is not a refusal of your KVKK Article 7 right; it is a procedural prerequisite to protect other users’ access to a paid service.

You can keep using iştebu! yemek on your own after your organization’s contract ends, delete your account at any time, or rejoin with another organization using the same phone number.

When personal-data destruction runs, your in-app feedback-action notification copies and their read times are deleted. The Seller’s action text and selected rating/label/fixed-service-issue coverage remain for quality statistics without your account identity or free-text notes.

The personal-data export generated for your authenticated account also includes in-app notifications you received about Seller feedback actions and your dish/service feedback covered by those notifications.

6. Contact

The personal-data export generated for your authenticated account includes your account details, active and ended memberships, and Seller team-invitation audit rows tied to you as creator, redeemer, or revoker. An invitation row shows the SMS send-success confirmation but contains no raw target phone, create-request ID, phone-authentication tag, invite token, or SMS body. An affiliation-only Seller team member is included in this scope.

Privacy questions and data protection rights requests can be sent to privacy@istebuyemek.com.

Optional food and health preferences

In Profile → Food preferences, you may submit your eating pattern and optional health information for yourself or a child you already actively guard. Allergy, intolerance and coeliac answers are separate; ingredients are selected from the 14 declared allergen groups. The list is not assumed to cover every health requirement. Unanswered, none and unknown are distinct. A declaration belongs to the eater’s shared identity across organizations and the submitting account. Each guardian can edit or request deletion of only their own declaration and cannot see or overwrite another guardian’s answers. No additional representation document is requested; the existing guardian link supplies technical authority. The legal sufficiency of representation for a child requires counsel review.

POİEX processes these voluntary details to support future menu and preparation improvement work. The first form step captures one explicit consent covering dietary preferences and optional allergy, intolerance and coeliac information for this purpose, separately from the privacy notice. There is no second consent control in the health step. Health questions may remain unanswered. Earlier grants are not automatically expanded; editing in the new form requires confirmation of the new scope. Withdrawing health consent requires a new confirmation before using this form again. The bases are KVKK Article 5/1 and, for health details, Article 6/3-a. Refusing consent does not block meal service. Audit records contain the profile, submitting account, scope, text version, grant/withdrawal and timestamp without food or health answers.

The kitchen cannot see your or your child’s individual answers or who they belong to. Organization administrators cannot view these answers either. This release computes or shares no kitchen recommendations from food preferences. Saving does not change existing orders, automatic assignments or charges and is not confirmation of an individually safe meal. Contact the organization and kitchen separately about health requirements.

Answers are stored on Hetzner servers in Germany without a fixed time limit; there is no automatic expiry. Editing replaces current answers. Deletion and consent-withdrawal requests are submitted to iştebu! yemek through the contact channels in this notice. Once processed, the relevant live answers are removed; answer-free consent audit remains. Account and child erasure also covers declarations and consent audits. After service/guardian relationships end, the declarant may still view their retained answers and request deletion. Existing private backups rotate after 30 days. Indefinite retention is a product decision for continuing improvement; its legal necessity and proportionality require counsel review.

International processing includes Germany/Hetzner hosting and existing Cloudflare security and private-backup services. Their published KVKK Article 9 transfer mechanisms have not yet been completed; this consent does not replace the legal mechanism for routine international transfers. Provider details appear on Sub-processors. Answers are not sent to the OpenAI recipe chat. The private form is blocked from session replay, and the live app does not store answers in browser storage. Personal exports include your declarations; KVKK Article 11 rights and contact channels are explained in the relevant section of this document.

This release only collects data; no food-preference recommendations are computed or shared with kitchens. Only the internal iştebu! yemek team receives aggregate counts of accounts that answered, declined or have not answered, without identities or health answers. Historically closed invitations with unknown outcomes are not counted as refusals. The current form collects dietary type and optional health information; earlier disliked ingredients, preparation preferences and other-ingredient records are retained.

Order confirmation first attempts non-3DS preauthorization. A supported response from the bank or payment provider requiring authentication opens direct bank verification; the application does not separately force 3DS for the first payment. Bank content and return state are encrypted; this step collects no new card number or CVV. Page access lasts at most 15 minutes and cannot outlive the order deadline. HTML is cleared at completion request, final result or reconciliation after expiry; residual return state is also erased through account deletion. Uncertain outcomes are queried without initiating another charge. Existing legacy payment sessions may finish through their original flow.

Personal payment details

Card payments use payer name, email, verified account phone, identity number and billing address. Known details are prefilled for you to review and edit before saving. Saving does not change your account name; delivery remains to the institution address. The identity number is stored encrypted. When signed in to your own account, you can view and edit the full number in your payment details without an additional SMS verification. The number is not persisted in browser storage or captured by analytics or session replay; personal exports keep it masked. Institution admins and operations screens cannot access this profile.

When adding a card from your profile, the email address is reused from your saved payment details without asking again in the card form. If it is missing, you are directed to complete your payment details first.

Encrypted buyer details are frozen when a payment starts; later profile edits do not change a pending transaction. Account closure removes access to reusable payment details. The destruction step in the existing account-deletion process deletes the reusable profile and clears the new encrypted buyer snapshots. Existing retention of financial amounts and audit records is unchanged. Required buyer details are transferred to the active iyzico service when a card payment is initiated.

Dish and delivery photos

You may optionally attach up to three photos to each rated dish and three more to delivery feedback. Printed QR reviews offer the same feature. Video is not collected. The camera opens only when you choose “Take a photo”; only files you select from the system picker are uploaded. Do not include faces or personal information.

Images are processed to investigate meal and delivery feedback under the existing legitimate interest in improving and proving service quality. Display copies are resized, oriented correctly and stripped of location/EXIF metadata. Files use private Cloudflare R2 storage under the cross-border transfer status already disclosed for that provider. Only the authorized eater/guardian and relevant Seller admin can view submitted photos through temporary links; company admins and public pages cannot access them.

No automatic deletion period applies to uploads or processed copies. Abandoned uploads and photos removed from a draft also remain in private storage. The photo-specific deletion policy and legal review have not been completed; scrubbing account details does not anonymize the image itself. Existing personal-data request channels remain available. Account-uploaded photo records and temporary download links are included in the personal data export.

Menu and Alakart entitlements

New companies may choose Menu, Alakart or both for a service. The institution right is shared across those services; changing kitchens does not reset usage. Hidden rights offer one eligible Menu without prices or member top-up. With visible rights, volume discounts apply before the institution contribution and the member pays the remainder. A mixed basket uses one entitlement reservation and one personal payment approval. Each Menu box and one Alakart basket contribute one volume unit; additional Alakart portions do not increase that unit. Legacy Menu service budgets and historical orders remain unchanged.

Authorized kitchen administrators may inspect the individual buyer name, order context and separate institution/member amounts for invoice reconciliation. Pending authorizations are distinct from finalized payments; saved cards, encrypted identity and provider secrets are excluded from this statement.

The company chooses daily or monthly use of its meal contribution. The fixed monthly amount is available from the company and employee entitlement start dates; it is not multiplied by weekdays or automatically prorated for the first month. Existing daily-derived monthly allowances continue to use selected weekdays and explicit entitlement start dates. Public holidays are not calculated. Rights renew automatically each period without carry-over. The company may grant selected employees an extra right for that period only. Entitlement is not a cash or electronic-money balance.

Menu, Alakart or both is chosen when creating a service and cannot be changed afterward. Using the other model requires ending the current service and creating a new one; remaining employee entitlement is not reset. The application retains the service model and start date, entitlement start/end dates, extra grants and usage amounts. Employees see their used, pending and available entitlement. Authorized company administrators can inspect and export Menu and Alakart usage by employee, date range and service; employee card payments are separate from company costs. The existing meal and billing legal bases and retention periods apply; no new recipient or service provider is introduced.

Kitchen setup and payment-account details

Kitchen setup is saved in separate business, document and payment sections. The physical kitchen and official billing addresses remain separate. Business type, account holder and payment contact email are included in the review. A sole proprietor’s Turkish identity number is encrypted in the setup record, any change request and the submitted payment-account request for iyzico sub-merchant registration and payouts. The kitchen administrator and authorized operations team see only the masked last four digits; updates reuse the encrypted record. The number is not included in public seller information or a customer company’s invoice profile.

Changes to reviewed official information, documents and payment fields are encrypted change requests. Accepted details remain in effect until review; changes affecting the payment provider take effect after provider confirmation. Saving or submitting for review does not send a registration request to the provider; authorized operations staff initiate registration. Operational permission may allow panel access with missing information; it does not verify documents or make card payments ready. Card-required orders cannot complete without a confirmed current payment recipient. Reviewed registration details are transferred to the active iyzico service when operations initiates registration; successful account synchronization alone does not prove provider KYC approval or a completed bank payout.

Team bulk orders and relationship termination

Team bulk orders placed by a company administrator are billed entirely to the company, including on employee-paid or contribution-funded plans; they do not consume employee allowances or charge employee cards. The time of a catering relationship termination request is recorded. Orders whose selection deadline has not passed at that time are cancelled and their authorizations voided; an uncertain bank result leaves closure pending and blocks new orders. Captured or past-deadline orders and financial records are retained.

Personal card-funded orders use the same label QR and distribution-group handling as individual selections. The public QR page does not disclose payment amounts, card details or distribution groups; cancelled card orders no longer resolve through their QR link.

iyzico retention and review evidence

iyzico’s published user agreement states at least 10 years for payment transaction records. The seller-registration retention period in POİEX’s executed Marketplace contract and evidence about the provider’s onward transfers have not yet been recorded in the compliance register. Active use does not represent completed contractual or PCI/KVKK review. POİEX’s own records remain subject to the retention rules above.

Individually paid recurring communities

A recurring community shares a delivery address and meal schedule. Its organizer manages the address, schedule and membership; each member is the individual meal buyer, and the kitchen issues that member’s meal invoice. The community has no institution allowance or institutional meal debt. The organizer cannot authorize another member’s card payment or create institution-funded bulk or automatic orders. Community setup uses the universal Terms and KVKK information instead of the corporate buyer agreement; the service relationship records the Link Terms.

Setup retains the customer kind, initial payment experience, delivery address, contact phone and membership role. New company setup additionally records the daily or fixed monthly allowance and founder’s meal enrollment. Processing uses the existing meal-coordination contract-performance and service-operations legitimate-interest purposes. Existing service and delivery information is shared with the authorized kitchen for meal coordination; personal payment profiles remain owner-only. Retention follows existing meal records: the active customer period, plus 10 years for billing or dispute records. Workspace creation introduces no new payment processor or organizer access to other members’ card or identity details.

An invoice scope may be recorded for closed service days of the same Buyer using a calendar month or custom start and end dates. Previously invoiced service days cannot be invoiced again; uncovered days remain open. Card collection and transfer to the Seller account are separate states; a transfer is confirmed using bank evidence.

Service funding arrangements

The company chooses the payment arrangement for each service when requesting it. For new hidden-price Menu services, the company chooses employee menus instead of a price limit; beneficiaries make no personal top-up and the service does not consume the shared allowance. Menu choice is optional when requesting service and required before ordering. General, weekday and date choices can be edited without cancelling existing orders. Choosing menus does not freeze service prices; daily meal publication preserves prices. Kitchen price changes apply to days without published availability. Closed orders use existing final billing snapshots. Legacy service limits keep their previous behavior. Visible Menu and Alakart services share one daily or calendar-month company contribution, with employees paying the remainder. For new services, a company chooses either fully funded hidden-price Menu or visible shared contribution with employee top-up. These two arrangements may coexist within a company. New fully personal services require a community. Community members pay their own orders; coordinators do not pay or place bulk orders on behalf of an institution. An initial shared contribution is saved with the first successful service request; abandoning a draft saves no rule. Existing shared allowances change through a dated impact preview, excluding hidden-price and fully personal services. Each service’s days, delivery and cutoff are accepted independently. Existing service arrangements and historical payment records are preserved. No new data category, processor or retention period is introduced.

Monthly shared contribution calculation

For a shared monthly contribution calculated from a daily amount, the daily per-person amount is multiplied by distinct service dates in the month; multiple meals on one date count once. The first month counts service dates from contribution setup. Opened monthly amounts and day counts are preserved. Daily-amount changes use a dated preview and apply from the first day of a future month; new months use current shared-service days. Public holidays are not calculated. Existing fixed monthly amounts are not automatically converted, and existing entitlement, usage and payment records are preserved.

Unconfirmed basket selections are kept separately for each account and organization in the browser tab session area (sessionStorage) so they can be restored after a refresh. This copy contains menu/dish references, service dates and quantities; it contains no card details, payment tokens, prices, payment approval or allergy/diet preferences. A draft does not create an order or reserve institution allowance or money. The device draft is removed when its service is confirmed; confirmed orders remain subject to the existing meal and financial retention periods. No new processor is introduced.

Your own order details show selected/served dishes, package and portion quantities, order/payment status and visible institution/member shares available in existing records. Card authorizations and actual charges are shown separately; failed or cancelled payment operations do not count as confirmed meal orders. Financial amounts are withheld for orders whose institution hides prices; missing historical financial details are not reconstructed using current prices. This screen reads existing meal/payment records and introduces no new retention period, recipient or processor. Payer details and masked cards are managed in Profile; order details do not show full identity/card numbers or payment tokens.

Card storage without an order

In the current card-funded flow, saving card and payment details returns you to the basket; each order requires a separate confirmation. Saving creates no order, authorization or charge. The save action accepts its adjacent card-storage disclosure without a separate checkbox. You can also add a card from your profile without ordering. Card number, name on card, expiry and email pass transiently through the application server to iyzico. The registration API accepts no CVV, identity or billing address; checkout identity/address fields are saved to the separate payer profile. Raw card number and name on card are not persisted in the database or production browser storage and are masked from replay and errors. Masked metadata, encrypted provider references, registration status and acceptance version follow existing retention rules. Existing cards keep their previous acceptance records. Card storage alone does not authorize automatic payments for later orders.

An unknown registration result blocks new attempts. Authorized operations staff can inspect limited registration metadata and record an audited confirmation that the provider has no remaining registration or has removed it. The existing personal-data erasure step clears card aliases, email, identity and address fields; existing financial-reference retention remains unchanged. Executed-contract, PCI and legal review evidence for the active iyzico service has not been recorded as complete.

Your default payment-card preference is stored on your account and used for future orders; existing orders keep their original card. The preference is included in personal-data exports and cleared at the existing account-data erasure step.

Operations orders and past meal balances

For meals added by authorized operations staff during a payment outage or order correction, we record the operator, reason, service date, payment responsibility, maximum quote, finalized company and personal shares, pricing volume and collection reference. These records serve existing contract performance and accurate service and financial records; existing meal and financial retention periods apply. Reasons must not include health, allergy, child or other sensitive personal data.

In My orders, you select a saved card and confirm the final past-meal amount to start direct bank authentication. If no card is saved, the existing card-registration step opens first and uses your saved payer email. Adding a card does not start a payment; you confirm payment separately. The current flow does not use iyzico Checkout Form; supported older app versions retain their payment flow. Normal new orders are blocked until the finalized personal share is cleared by verified capture. Operations does not receive personal payment profiles or card credentials, and this action does not automatically charge a card. The existing company administrator order view includes company and personal shares, without personal card credentials. Personal data exports include the owner’s meal balances and collection state, excluding internal operator notes. No new processor is added.

Editing and cancelling an operations order

Before the selection deadline, you may edit or cancel an order created for you by operations. A normal contribution order recalculates the new member share; the change is confirmed only after your explicit approval and successful bank authorization of any member amount. A company-paid exception keeps its originally approved maximum; you explicitly approve and cover any excess. If authorization does not succeed, the existing order and contribution reservation remain. An uncertain edit payment blocks another edit or cancellation until resolved. Cancellation records and links between original and replacement orders follow the existing financial-record retention periods.

First-entry information and direct guardian addition

Successful phone authentication updates the account’s latest login; the first login is recorded once for newly tracked accounts. The first application entry after organization enrollment is recorded separately, including an authenticated application launch with an existing session. Organization administrators see the membership’s first application entry after enrollment; authentication times and actions in other organizations are not shared. Historical first-entry information for existing records is shown as unknown. Processing supports account security and operational onboarding under contract performance and legitimate interest. No detailed login-event history, new tracking cookie, or new processor is added. These timestamps are included in the person’s data export and cleared through the existing personal-data destruction process after account closure.

To distinguish application use from successful authentication, we retain the latest foreground activity time at account level. Server time is recorded on application opening, foreground return and every five minutes while visible, regardless of the organization screen being viewed. This also fills any tracked first-entry timestamp for all active memberships after enrollment; unknown historical first-entry information remains unknown. Background requests and support impersonation do not count. Organization administrators can see their active members’ account-wide latest app activity and recent-member lists/counts calculated from it. No viewed organization or screen history is shared; subsequent activity of former members is not displayed. This supports operational adoption and use monitoring without daily activity history or inferred past activity. Latest activity timestamps follow the same export and post-closure destruction process.

In the current application, an authorized guardian reviews the child and the other guardian’s phone number and confirms direct addition. This immediately grants the minimum guardian membership in that organization and access to the selected child; invitation acceptance is not required. The sign-in SMS is informational. Existing guardians and meal selections remain unchanged, and the child is not copied to another organization. Previously shared codes and code redemption by older clients remain supported.

Full and partial order issues use the support review and original-funding allocation rules in Delivery and Returns. Company credit defaults to later invoice offsets; exceptional bank repayments are discussed with support without a separate EFT request form.