Terms of Use | iştebu! yemek

This English page is a support translation. The Turkish legal text prevails in case of inconsistency.

1. Operator and scope

iştebu! yemek is a brand operated by POİEX TEKNOLOJİ LİMİTED ŞİRKETİ. These terms apply to the iştebu! yemek website, app, the istebu.app compatibility addresses retained during the migration, demo, marketplace, and support channels. Separate customer or supplier contracts prevail for commercial payment, invoicing, liability, and service level terms.

2. Accounts and roles

Users log in with phone-based OTP authentication and may only act for organizations and roles they are authorized to use. Company admins, beneficiaries, and Seller (food-service seller) admins are responsible for the accuracy of the operational, invoice, tax, and payout records they create, including the company’s designated-buyer tax declaration and the TR IBAN a Seller enters for payout. A company admin must consult its tax adviser if the designation is uncertain.

An active Seller admin may create a revocable team invitation, valid for 72 hours, only for an authorized teammate. To show the recipient who is inviting them, the SMS includes a sanitized, length-bounded form of the inviting Seller’s display name. The invitation record includes a boolean indicating whether the synchronous SMS send call succeeded; this is not a handset delivery receipt. The raw target phone, create-request ID, phone-authentication tag, and SMS body are not retained. The recipient can use the invitation only after authenticating by OTP with the same phone number; redemption grants an affiliation-only member role with no operational access. Menus, clients, kitchen, delivery, billing, payout information, and team administration are not granted automatically. A current admin may later promote the member through a separate confirmation action. The inviting admin is responsible for entering the correct phone number and for the scope of any later promotion; an unused invitation also becomes invalid if its creator loses active admin status or membership.

A Seller admin may also add a teammate directly by phone. An account and affiliation-only member record are created immediately, without accepting a link; the teammate signs in with OTP on their own phone. The admin is responsible for the correct number. Administrator access requires a later separate confirmation. Previously issued invitations remain usable within their existing validity window.

An affiliation-only Seller team member may sign in to their own verified account and exercise their own account and data rights, but cannot perform operational or administrative actions for the Seller unless a current admin separately promotes them.

Users may also report fixed delivery/service issues for the meal and add an optional service note. An authorized Seller admin may select open negative labels, one- to three-star free-text reviews, and fixed delivery/service issues and publish one Seller response. This field must be used only for a concrete investigation or action taken; the Seller is responsible for the response’s accuracy and content. Publishing creates an in-app notification for the active account that actually submitted the selected feedback, including a guardian who submitted for a child; current native installations that enabled notifications may also receive generic push copy that omits the response text. The Seller may instead close selected signals internally as requiring no action, which sends no notification. Neither resolution alters the original rating, note, or service report.

3. Meal operations and billing

iştebu! yemek coordinates daily corporate breakfast, lunch, snack and dinner selection, cancellation, bulk order, delivery, headcount, quality feedback, and invoice-period records. Each service is separately defined by type, service days, delivery time, selection deadline and any per-person budget. A 1–3 star dish rating must include at least one negative label or a non-blank note; 4–5 star ratings require neither. A free-text note remains optional in every case and, when added, is shared with the relevant Seller. Mutations after the configured deadline may be rejected. Invoices are prepared from delivered periods, system quantities, and the relevant organization’s invoice profile. A Seller may select one or more completed weekly settlements for one invoice, access the invoice profile (legal name, tax identifier, tax office, billing address, and designated-buyer declaration) of the actively linked customer company, and record the issued invoice’s PDF evidence. The declaration applies only to records that have not yet been invoiced; an issued invoice’s withholding, collection, and payout snapshot is not rewritten. In 2026, if the selected invoice group’s VAT-inclusive total exceeds TRY 12,000, 5/10 VAT withholding for food service (code 604) applies: invoice gross is unchanged, the withheld VAT remains the Buyer’s VAT 2 responsibility, and the bank-payable amount is gross less withheld VAT. The app then creates a durable in-app payment notification for active company admins; a current native installation receives push, while critical SMS fallback is used only when no current push installation exists, never together for the same event. POİEX issues the intermediation invoice and handles collection. After an EFT/bank transfer, a company admin may report the payment date and an optional receipt; this report is not bank-collection confirmation, debt discharge, or authorization of the Seller payout. A report that does not match the bank record may be rejected with an audited reason, after which the company can report again. Separate commercial contracts prevail for payment, collection, and payout terms where signed.

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.

Before the deadline, the Seller may view and print the current named delivery roster and package counts as a draft only after explicitly acknowledging that the list can still change. The screen and every person label, packing slip, group separator, and delivery receipt are marked DRAFT with the generation time and selection deadline. Final production printing opens after all selection deadlines have passed.

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.

For a live menu, the Seller’s per-person payout including VAT is the operational price anchor; entries made through the meal amount excluding VAT or the Buyer’s total including VAT are normalized to that amount. The applicable iştebu! yemek service fee (PHB) is added on top. When an assignment is created, the payout, effective PHB, Buyer total, and formula version are frozen as a snapshot; later rate changes do not alter earlier assignments or invoices. The cent-rounding rules are set out in the Payment, Collection and Payout Terms.

The optional company delivery-point picker uses Google Maps. 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. Map use is subject to the Google Maps Additional Terms of Service. Google’s data practices are described in its Privacy Policy and our Privacy Policy. The point is optional; administrators may select manually without granting device location permission. Caterer directions links open the external Google Maps app or website. 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.

Current card-funded orders use a saved card. Saving card and payment details starts no payment; after returning to the basket, you confirm each order amount separately. The save action accepts its adjacent card-storage disclosure. The first payment also attempts non-3DS preauthorization and opens verification on a supported issuer response. Removing a card does not cancel an already confirmed order or authorization; existing order deadlines and cancellation rules apply. Card storage does not authorize automatic charges for subsequent orders.

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.

4. Food and allergen information

Menu and allergen information depends on Seller-provided data. Users with serious allergies or special dietary needs should confirm with their company contact and the Seller rather than relying only on in-app information.

5. Unacceptable use

Attempting to access an unauthorized company or user account.
Creating misleading order, delivery, invoice, or feedback records.
Running automation, scraping, reverse engineering, or security testing that disrupts the system.
Uploading or sharing third parties’ personal data without authorization.

6. Service continuity and changes

iştebu! yemek is operated to run with reasonable continuity; access may be interrupted temporarily due to maintenance, security, supplier failure, internet outages, or force majeure. Product features, role permissions, and screens may change over time.

7. Intellectual property

The iştebu! yemek brand, software, interfaces, texts, and visual assets belong to POİEX or its licensors. Users are granted only a limited, non-transferable right of use solely to benefit from the service.

8. Limitation of liability

Subject to liabilities that cannot lawfully be excluded (intent, gross negligence, KVKK personal-data obligations, harm to life or health):

POİEX’s total liability for any claim arising from these Terms or use of the service is capped at the net service fees paid by the affected customer to POİEX in the 12 months preceding the event giving rise to the claim.
POİEX is not liable for indirect, consequential, lost-profit, lost-business, reputational, data-loss-related, or punitive damages.
Liability for food, allergen, hygiene, delivery, or service-quality issues sits with the Seller. iştebu! yemek provides coordination infrastructure only.

9. Termination

The company customer may end the service relationship under these Terms at any time via the app or written notice, without cause; there is no fixed term or minimum commitment. Days whose selection deadline has not yet passed are cancelled and not billed; days past their selection deadline are delivered and included in the invoice, because production has already started.
POİEX reserves the right to end the service relationship for quality, food-safety, document-compliance, or breach reasons.
Termination of Seller agreements signed with Sellers is governed by the relevant Seller agreement; these Terms of Use do not replace the Seller agreement.
A material breach not cured within 15 days entitles the other party to terminate immediately.
After account closure, users may exercise KVKK Article 11 rights via privacy@istebuyemek.com, and may delete their own account at any time via Profile → Privacy & Data → Delete Account. Data subject to legal or accounting retention obligations is preserved for the applicable retention period.

10. Governing law and jurisdiction

These Terms are governed by the laws of the Republic of Türkiye. The courts and enforcement offices of Ankara shall have exclusive jurisdiction over any disputes arising from these Terms or use of the service, without prejudice to the jurisdiction rules of Law No. 6502 on Consumer Protection where applicable.

11. Contact

Questions can be sent to hello@istebuyemek.com.

Up to three photos may be attached separately to each dish and delivery review. Photos are shared with the relevant Seller. Do not include faces or personal information. Camera use, retention and data-request details are in the Privacy Policy.

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.

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.

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.

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.

Meals added by operations

For a support request or operational correction, authorized operations staff may add a meal before or after its deadline without collecting payment. The operator, reason and payment responsibility are recorded. Company orders can follow the contribution agreement or allocate the whole amount to the company or person. Community meals are fully payable by the individual. Company bulk and guest orders do not consume an individual’s contribution allowance.

A finalized unpaid personal share prevents the person from placing a normal new order. 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. Authorization or an uncertain result does not clear the balance; verified capture is required. Adding a meal in operations does not automatically charge a card.

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.

For approved full and partial delivery issues on committed orders, the payment state determines whether unpaid liability is removed, a card hold is released or captured money is returned to the original card. Company credit can offset obligations or be repaid by bank transfer even after the company leaves. Reporting windows, operations review and preservation of payment evidence are set out in Delivery and Returns; mandatory statutory rights remain unaffected.

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.