KVKK Disclosure Notice

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. Data controller

The data controller is POİEX TEKNOLOJİ LİMİTED ŞİRKETİ. Contact details are available 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 requests concerning this data on iştebu! yemek are addressed directly to POİEX through the channel listed in section 5.

2. Data subjects and categories

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.

New dish-priced daily plans record selected dishes and portion counts, service-day prices and funded meal allowances, the organization administrator’s price-visibility preference and discounts. Eaters see amounts only when that preference permits; hidden amounts remain subject to the same limit. These records serve existing meal-coordination and billing purposes under the same legal bases and retention periods. Authorized kitchen and organization staff access orders for production, delivery and invoice reconciliation. Missing-delivery and gift adjustments identify the actual individual order or bulk-order box. Existing orders are not converted, and no personal wallet, employee card payment, new recipient category or service provider is introduced.

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 process 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. Existing meal-coordination and billing legal bases and retention periods apply; card checkout has separate activation requirements.

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.

For an authorized Seller admin, the AI-assisted dish workspace processes, linked to the acting admin account, the entered dish name and description, ingredient names and grams, recipe chat, assistant responses, response scope/model/prompt/provider-request metadata, and successive draft versions, together with the energy, protein, carbohydrate, and fat values, food labels, and illustrative dish image generated by OpenAI. The field is limited to dish/product information and instructs the admin not to enter information about a person or child, health data, or other sensitive personal data. The original paste, chat, and draft versions are retained in the application database without a scheduled deletion period, including after confirmation. A confirmed recipe and dish fields remain until replaced or no longer needed for the active service relationship. Cost/usage audit rows separately retain provider request metadata and token/image counts.

For users who open an in-app support request, the processed categories include the request category and status, user and support-team messages, up to three attached JPEG, PNG, or WebP images with filename, content type and size, source screen, app version, interface language, optional active-organization context, and private internal notes of authorized POİEX operators. 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 conversation remains between the user and authorized POİEX operators; organization admins and Sellers cannot access it. A generic native push without the reply text may link the user to the conversation.

An active admin of the same organization may view active or ended organization enrollments for employees, admins, guardians, and students for organization management, including the record’s system creation and optional end timestamps, role, contact details, guardian relationship, and class/distribution group. The single-person dialog searches active and ended records within that organization; an admin may submit one or more guardians for a selected active student. An exact selection is validated by a server state token and applied atomically without a separate second confirmation screen, while a similar or ambiguous student match pauses for comparison and explicit confirmation. An admin may remove one guardian while another active guardian remains or end the student. 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 only that organization’s weekly meals and costs. Ratings, review labels, and review text are never attributed or shown on these pages. No separate analytics record is created for this purpose.

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.

A school admin may preview and confirm the student, guardian/membership, and pre-deadline future-selection effects of a family departure. Confirmation ends the selected member and every active student they guard in that school, together with the local guardian links, in one transaction. When one student leaves, every guardian’s remaining scope is reconciled: another active student preserves guardian permission; an admin or active staff/self-eater keeps membership without guardian permission; otherwise the school membership ends. Deadline-closed selections and historical meal/cost records remain.

When an authorized POİEX operator deletes an inaccurate individual or bulk order, the audit records the acting operator and the deleted order’s date, meal service, recipient/orderer, quantity, menu, and dishes. An order with a submitted review or settled invoice cannot be deleted through this operation.

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.

Aggregate kitchen-demand forecasting evaluates 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 when the phone is not yet represented by the matching active eater/guardian record. Failed or older sends are excluded. Person-level intermediate results exist only transiently during the request: they are not stored or disclosed to the Seller, which sees only aggregate kitchen and dish quantities.

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.

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

For a delivery-terms change, categories additionally include the recipient, Seller and customer organization, current delivery and order-deadline times, in-app title/body/deep link, and channel state. A current installation receives push; because this is critical, the recipient phone and SMS fallback state are processed only when no current push installation exists. Push and SMS are never both queued for the same recipient and event.

iștebu! processes data relating to website visitors, unauthenticated native app installers, organization admins, beneficiaries, Seller (food-service seller) admins, prospective Seller team members, active affiliation-only Seller team members, prospects, support contacts, privacy-rights requesters, and — at school-segment customers — children/students (an account-less eater whose name, optional class/distribution group, meal selection, cancellation, rating and optional dish-review note are processed) and their guardians (whose name, phone, school membership, and actions for the child are processed). School enrollment and meal coordination do not collect a child’s health, dietary, or allergy data. A guardian may separately submit voluntary private food-preference and health declarations for the child under the purpose-specific consent described below. Allergens shown on dishes are product information, not person-linked health data. In the current People flow, a company admin may add one employee or up to 2,000 Excel rows containing the required phone, optional account name, and optional existing distribution group. A school admin may add one student with one or more guardian phones, or up to 2,000 rows containing the required child name and guardian phone, optional guardian name, and optional existing class/distribution group. The pasted table is processed transiently for preview and apply and is not retained separately. Enrollment creates no meal selection or headcount, and an optional employee or guardian name fills only an entirely blank account name. Supported older clients may continue to provide a phone-only selected-scope roster during the compatibility window. Separately, an active Seller admin may enter the intended teammate’s phone for an affiliation-only team invitation. That 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, member role, creator/redeemer/revoker, status, and timestamp audit. The boolean is not a handset delivery receipt. After redemption, the active 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 role has no menu, client, kitchen, delivery, billing, payout, or team-administration access unless a current admin separately promotes the member. Categories also include identity, phone number, email address, role, organization, meal selections, delivery and billing records, invoice legal name, tax identifier, tax office, billing address, Seller payout IBAN, order totals and menu/assignment pricing snapshots (payout including VAT, effective PHB, Buyer total, VAT/fee components, and formula version), food business registration number and verification status, the Seller’s verification documents (tax certificate and food business registration certificate, stored privately and not disclosed to organizations), invoice evidence, a company-admin payment declaration’s payment date, reporting account, report timestamp and optional privately stored PDF/image receipt, the rejection time, acting account and reason when a declaration does not match, settlement/collection/payout references, support and privacy request messages, verification and response records, ratings and sentiment labels. A 1–3 star dish rating must include a negative label or non-blank note; 4–5 stars require neither. A free-text dish-review note remains optional, is shared with the Seller, shown back to the author, and not shown to organization admins. Categories also include in-app product feedback about the application itself (with the screen it was sent from, the app version, and the interface language), uploaded avatars, organization logos, dish images, cookie choices, device data, backup records, cron monitoring metadata, diagnostic events, and security logs. A school parent/guardian may also contact us from inside the app to introduce iştebu! yemek to another school their child attends; for this inbound inquiry we process their phone number, message content, referred school name, city, source organization (attribution only), and our response records, and no child data is involved.

The same review submission may also contain a fixed delivery/service issue and an optional service note. The actual submitting account is recorded separately from the eater, so a guardian submitting for a child is the submitting account; account-less QR submissions have no such link. Dish and service notes are shared with the Seller, shown back only to the submitter, and not disclosed to organization admins.

For production web and native diagnostic events, the categories also include the startup or tab-navigation milestone name and duration, application release and platform, and a route with its organization identifier replaced by a placeholder. These custom performance fields contain no name, phone number, meal, billing, or free-text business content.

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.

At a school, the administrator may alternatively select a staff scope with the same employee fields: required phone, optional account name, and optional existing distribution group. Staff and student/guardian scopes are previewed and applied separately.

A landing visitor may initiate a WhatsApp conversation from the floating contact CTA, an audience-specific company, school or caterer contact page, or a corporate-meal service, sector or regional page. For that inquiry 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 native app installations, including before sign-in, live-update delivery processes 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. This flow carries no name, phone number, meal data, or billing content.

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. Only for users who enable notifications do we process an encrypted FCM registration token, random installation UUID, account association, platform, app/native version and build, locale, time zone, and last refresh time. A send includes 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.

When an authorized Seller admin takes a concrete action on one or more still-open negative-label occurrences, one- to three-star free-text reviews, or fixed delivery/service issues, we process the Seller’s single response, the selected feedback links, an in-app notification for each active submitting account, and its read time. The original submission remains unchanged. Each submitter — including a guardian submitting for a child — receives at most one notification for the same action and customer organization, and sees only their own covered dish and service feedback. Account-less QR and anonymous bulk-box submissions cannot receive a notification. An internal “no action required” resolution creates no notification. Any native push uses generic lock-screen copy and contains no Seller response, review text, dish, child, or organization name.

On Android, if the person signing in accepts the operating system’s one-message access prompt, the verification SMS body is processed transiently only in device memory. The app extracts the six-digit code and fills the login field; it does not retain the message or send it to the iştebu! yemek backend. Refusal, cancellation, timeout, or an unavailable system service leaves manual entry available.

A school creates and controls each student’s organization-scoped meal enrollment. Guardian membership or permission never copies that student into another organization. A child-scoped code links a 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 that organization’s meal.

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.

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.

3. Purposes, legal basis, and transfers

Seller feedback actions are processed to improve and evidence meal-service quality and to deliver a concrete response to the authors whose feedback the action covers. This processing rests on legitimate interest in reliable service quality and accountable follow-up; no response is required or sent for a generic acknowledgement without a concrete review or change.

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 output is 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. The proportionality, definite retention period, and legal basis for retaining the original paste, chat, and draft versions indefinitely must be validated by counsel before production use. OpenAI may retain API inputs and outputs in default abuse-monitoring logs for up to 30 days unless law requires longer. OpenAI, L.L.C. operates on United States/global infrastructure; its KVKK Article 9 safeguard is not yet complete and the current status is published on Sub-processors. The system does not add a user’s name, phone, organization name, meal selection, employee, guardian, or child record to this flow. 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 support accurate handout. A name or phone list entered for bulk assignment is compared transiently only with active beneficiaries in that organization and is not retained as a separate record. Before any change, the admin sees exact unique matches, duplicates, missing people, and possible same-name matches. When active beneficiaries share a name, the candidates’ current group and active guardian names are shown only in this preview so the admin can select the intended child. Add mode skips unresolved rows and changes only matched people; full-list mode cannot be applied until every row is resolved and then clears only the current group value of people absent from the list. It does not change organization enrollment, guardianship, meal selections, headcount, billing, or history, and entered phone numbers and guardian names shown for matching are not transferred to the Seller. The current group appears with the beneficiary 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 historical meal or billing records, and is not shown on the public QR page. This processing relies on contract performance and legitimate interest in accurate delivery.

This aggregate forecast supports meal coordination and headcount operations. The processing rests on contract performance, pre-contractual onboarding, and reliable-operation legitimate interest for adults, prospective members, and organization-managed student rosters. No phone number is disclosed in the result, and no new processor or person-level recipient is introduced.

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 queued for the same recipient and event. Channel state and the event-scoped idempotency key are retained with the related meal-coordination records.

In the current People flow, an authorized company or school admin may 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 records in the same organization; selecting a registered student shows current guardians and permits several new guardians in one submission. 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, direct link, class/group update, roster ending, guardian-permission or membership effect, future-selection cancellation, and every masked SMS recipient with the exact rendered message before one atomic apply; invalid or unresolved rows block it. Once applied, the membership and guardian relationship become active immediately. The SMS is informational and not an acceptance gate. A newly active membership receives the no-code Vatansms 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; 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. The roster and child meal coordination processing rests on performance of the customer service and legitimate interest in accurate, limited and reliable meal operations.

The separate family/student departure flow shows the affected students, guardian memberships, and pre-deadline future selections before confirmation. Family confirmation atomically ends the selected member and every active student they guard in that school; student confirmation ends the student and any last guardian’s school membership only when that guardian has no other active scope. User accounts, memberships in other organizations, deadline-closed selections, and historical records remain.

At a school, staff and student/guardian are separate full-list scopes; reconciliation in one does not affect the other. School staff are matched by phone, and active admins are protected from staff-roster removal.

Mobile live-update technical records are collected electronically when the native app checks for updates at startup and in the background. They are processed under pre-contractual steps before sign-in, contract performance for signed-in users, and legitimate interest in secure service delivery, continuity, diagnostics, and incident recovery.

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 as durable in-app notifications and also sent by push when a current native installation exists. Routine events never fall back to SMS. Critical delivery/deadline changes, meal-day closures, selected-dish substitutions, invoice-ready notices and automatic-order failures use Vatansms only when the recipient has no current push installation; one event never sends both push and SMS to that recipient. 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. This 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 Android OTP AutoFill, the message body is collected on-device only after the person accepts the operating system prompt for that one verification request and is discarded after code extraction, cancellation, or timeout. The processing rests on contract establishment/performance and legitimate interest in secure, usable account access. The operating-system prompt is a technical device-access choice, not marketing consent. This flow sends the message body neither to the iştebu! yemek backend nor to a new recipient.

For a free-text service announcement, an authorized POİEX operator must choose exactly one audience mode: search active user accounts by name or phone and select one account 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 transient and are not retained. The operator previews deduplicated person/device counts, records an internal reason, and confirms the non-marketing purpose before a durable in-app notification and user-enabled native push rows are queued. Phone-only recipients and SMS are not supported by this flow. Terminal push rows are deleted after 90 days and inbox rows follow account erasure.

Data is collected electronically through the website, app, OTP flow, organization actions, image uploads, support messages, privacy-rights requests, business email, and system logs. Processing is based on contract performance, pre-contractual steps, legal obligation, legitimate interest in customer support, security and service reliability, and explicit consent for optional analytics cookies. Seller-team invitations and the current People enrollment flow remain SMS-primary: the intended phone is processed for a time-limited invitation or no-code login notice through the existing Vatansms processor, while the documented invitation and roster safeguards continue to apply. Separately, an authorized POİEX operator may select either one active account with organization context or one organization with selected active roles. The console previews deduplicated people/devices and, after an internal reason and non-marketing confirmation, creates a durable in-app notification and push rows for current user-enabled installations. Phone-only recipients and SMS are not supported by the operator-announcement flow. Operators are instructed not to enter child, health, allergy, dietary or other sensitive personal data.

The floating landing-site CTA and the in-app school-referral card open a prefilled message to the WhatsApp Business line that the person chooses whether to send. The phone number, message, and response records are collected electronically under pre-contractual steps at the person’s request and legitimate interest in responding to inbound sales inquiries (KVKK Article 5/2-c and 5/2-f).

For an open meal service, the system creates an automatic in-app reminder normally 90 minutes before the selection deadline, only when 30 useful minutes remain and during the organization’s local 08:00–22:00 window; a target outside the window is moved to the preceding local 20:00 slot. Before delivery, current selection, explicit not-eating choice, membership, guardian authority and deadline are rechecked. One account missing its own and one or more children’s selections in the same organization, day and service receives one combined notification; separate services are assessed separately. An authorized 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, contract performance and the legal obligations tied to invoicing and collection support a durable in-app notification and payment action for every 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 with the billing record.

Invoice/accounting data also includes the company admin’s designated-buyer declaration; the withholding rate, code and threshold; withheld VAT; and the 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 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. This processing rests on contract performance and tax/invoicing legal obligations.

After an EFT/bank transfer, a company admin may enter the payment date and an optional PDF/image receipt. Contract performance, operational collection verification, and legal recordkeeping support processing the reporting account, automatic report timestamp, payment date, and receipt. A receipt is stored in private Cloudflare R2 object storage and opened only through a short-lived authorized link. The declaration is not bank-collection confirmation, debt discharge, or authorization of the Seller payout. If the 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.

The activity-level mapping is: website and cookie preferences rely on necessary service operation or explicit consent for Microsoft Clarity; authentication/session records rely on contract establishment/performance and account-security legitimate interest; meal operations, organization-managed student enrollment, authorized guardian actions, and feedback rely on customer-service performance and reliable-operation/service-quality legitimate interest; billing, collection, and Seller payout settlement rely on contract performance and legal obligation; media uploads rely on service performance and operation; support and privacy requests rely on pre-contractual steps, contract performance, legal obligation, and customer-support legitimate interest; backups, cron monitoring, and diagnostics rely on service continuity and security.

Mobile live-update records are used to check native compatibility, deliver signed bundles, measure adoption, diagnose delivery, and support rollback.

Data may be shared with organization admins, Sellers, hosting and security providers, object storage and backup providers, business email providers, SMS providers, cron- and uptime-monitoring providers, error-monitoring providers, analytics providers, accounting, legal, and public-authority recipients when necessary. Current 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. All listed processors except Vatansms, Paraşüt and iyzico operate outside Turkey, which triggers a cross-border transfer; Vatansms and Paraşüt are based in Turkey. The KVKK Article 9 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. Sellers (food-service sellers) receive only an operational subset: daily headcount, menu assignments, bulk-order line items, delivery location, and the name needed for a beneficiary to find their own meal on the delivery label. The label shows the beneficiary’s first and last name, so that boxes are not mixed up between people who share a first name 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 (e.g. by physically seeing the label); the personal data it shows is no more than what is already printed on the label (first name, that day’s meal selection, the Seller’s name, date, and delivery time), and it additionally shows the dishes’ declared food information (description, allergens, dietary tags, special warnings, and energy — product information, not personal data). The same page 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 under KVKK Article 7. 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.

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.

Mobile live-update technical data is transferred to Capawesome Cloud (Genz IT Solutions GmbH) for the purposes above. The EU endpoint is used. Capawesome operates from Germany and uses some United States sub-processors; the KVKK Article 9 safeguard for this transfer is not yet completed.

Google LLC (Firebase Cloud Messaging) is the native push delivery processor. It receives the Firebase installation ID, target registration token, and notification payload; iOS delivery continues through APNs. A feedback-action notice expires after 7 days and an operator-confirmed service announcement expires after 24 hours.

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 the visitor chooses to send it, their phone number, message, and the response conversation transit WhatsApp/Meta infrastructure outside Turkey (a cross-border transfer, with the Article 9 safeguards being put in place as above). The legal basis is pre-contractual steps at the visitor’s request and legitimate interest in responding to inbound sales inquiries (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 the person initiates the contact, no explicit consent is taken and this is not an unsolicited commercial electronic message under Law No. 6563 / İYS. The inquiry is retained for 1 year; unrelated later marketing requires separate explicit consent.

Seller team-invitation creation and redemption requests pass through the existing Hetzner and Cloudflare infrastructure. The target phone, a sanitized and length-bounded form of the inviting Seller’s display name, and the invitation link are sent by SMS through the existing Turkey-based Vatansms processor; no new processor is used, and the platform does not persist the rendered SMS body. The existing cross-border status and the Article 9 safeguard gap described above apply to Hetzner and Cloudflare.

In direct Seller team enrollment, a current admin confirms the phone and an account and affiliation-only membership are created immediately, without invitation acceptance. We process the account phone, Seller organization, role and membership lifecycle, acting admin, and no-code SMS queue state under Seller-service performance, pre-contractual onboarding, and legitimate interest in accountable access. The person signs in with OTP on their own phone; admin promotion is separate. The SMS names the Seller and links to the official app through the existing Vatansms processor. Delivery is not an enrollment condition. Account, membership, and SMS records follow their existing lifecycles; no separate phone list is retained.

For a possible student match, when one name is a contiguous part of the other and the surnames match, the authorized school admin compares the current and Excel child names, class, and active guardian names with masked phones and 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 name or explicitly apply the Turkish-title-cased Excel name; an unresolved possible match is protected from full-list removal.

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. Account deletion

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. Account closure immediately removes the server-side registration token and account-installation association. 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.

Retention periods vary by processing purpose; see the Privacy Policy Retention section for details. 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, create-request ID, and phone-authentication tag 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. An unused invitation can be revoked and becomes invalid if its creator loses active admin status or membership. After lifecycle guards pass, the in-app “Delete my account” flow closes your account immediately: sessions are revoked, the account can no longer be signed into, active memberships end, in-progress (pre-deadline) meal selections are dropped, and the phone is detached so the number is freed for re-registration. Your personal data is not yet destroyed at closure; it is stored with access closed, to prove the underlying transactions were real and to establish, exercise, or protect a legal right (KVKK Article 5/2-e), and is deleted or anonymized in the periodic destruction cycle following closure (within six months at the latest). On a written KVKK Article 7 request the deletion is completed within 30 days at the latest.

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.

When the deletion is processed, your name, phone, profile image (including the image file in object storage), the technical fields on consent records (IP, device), your personal in-app feedback-action notification copies, and their read times are erased; the eater (meal-subject) name on your meal records is also stripped. Past meal selections, bulk orders, ratings, and billing-tied records are retained with the identity link cut, for the statutory retention period required by VUK m. 253 and TBK m. 146 — they appear as “Anonymous user” in per-person historical views; aggregate billing, headcount, and quality figures are unaffected. Free-text in-app product feedback 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 de-identified Seller action and its covered rating/label/service-issue links remain as a service-quality checkpoint without the deleted user’s inbox copy or free-text notes.

A guardian’s meal selections, ratings and review notes placed for a child are not auto-deleted over time; they are kept for the service relationship. A guardian cannot remove the child, and an active student’s last guardian relationship cannot end. The 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. Erasing the child’s identity is a separate authorized KVKK process, while billing-related past records are retained anonymized. The guardian exercises the child’s KVKK rights.

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, deletion may be refused until another admin is appointed. This is a procedural prerequisite, not a refusal of the KVKK Article 7 right.

5. Rights

KVKK Article 11 requests can be sent to privacy@istebuyemek.com. The right of access and portability can also be exercised in-app via “Download my data”. The generated export includes your account details, active and ended memberships, received feedback-action notifications and Seller responses, the dish/service feedback of yours covered by those notifications, 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.

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.