Restoranlar için sipariş uygulaması, restoran paneli ve teslimat akışı

Ödeme alındı ile restoran onayladı neden ayrı durumlar?

Sipariş uygulamalarında sık yapılan hata, ödeme başarılı olduğu anda siparişi onaylanmış saymak. Oysa restoran o ürünü o saatte hazırlayamayabilir, teslimat adresi bölge dışında kalabilir ya da mutfak kapanmış olabilir. Ödeme alınmış ama restoranın haberi olmayan bir sipariş, müşteri için en kötü senaryo.

Karaman mobil uygulamasında create-order siparişi her zaman pending durumunda açıyor. iyzico-webhook ve garanti-webhook ödemeyi işliyor ama restoran onayının yerine geçmiyor; onay ya da ret restoranın panelinden geliyor. Kapıda ödeme seçilen siparişler de aynı akıştan geçiyor, bu yüzden restoranın gördüğü ekran ödeme yöntemine göre değişmiyor.

Durum geçişleri yetkili role bağlı ve her geçiş tek bir geçmiş kaydı yazıyor. Kuralı arayüze değil veritabanına koyduk: onay ve ret geçişleri satır güvenliği altında çalışıyor ve restoran rolüyle koşan yerel bir veritabanı testinden geçti. Geçişi yalnız yetkili rol yapabiliyor ve kim neyi ne zaman değiştirdi sorusunun cevabı her zaman kayıtlı.

Mutfakta yeni sipariş nasıl fark ediliyor?

Restoran mutfağında yeni sipariş fark edilmezse müşteri bekler. Karaman restoran paneli için sahadan gelen istekler de tam bu noktadaydı: sipariş sesi, adisyon yazdırma ve teslimat bölgesini restoranın kendisinin çizebilmesi.

Yeni ve bekleyen siparişler realtime aboneliğiyle takip ediliyor; bağlantı koptuğunda sipariş kaçmasın diye yanında 15 saniyelik bir sorgu da çalışıyor. Tarayıcılar kullanıcı etkileşimi olmadan ses çalmaya izin vermediği için panelde ses iznini açan ayrı bir buton var; izin bir kez verildiğinde yeni sipariş sesle duyuruluyor.

Sipariş detayında 58 ve 80 mm adisyon seçimi ve yazdırma var. Adisyonda kalemler, varyantlar, müşteri notu, adres, ödeme yöntemi ve toplam yer alıyor. Ayrı bir yazıcı yazılımı gerekmiyor; yazdırma panelin içinden yapılıyor.

Panel ekranları göreve göre ayrıldı: sipariş, menü, kurye, rapor ve ayarlar. Eylül 2026 sürümüyle müşterinin geri bildirim listesindeki dokuz madde kapatıldı; mobil hamburger menü ve yatay taşma düzeltmeleri de bu sürümde geldi.

Teslimat bölgesi haritada nasıl çiziliyor ve nasıl doğrulanıyor?

Teslimat bölgesini metin olarak tutmak (semt listesi, posta kodu) gerçek hayatta tutmuyor; restoranın kuryesinin gittiği alan çoğu zaman bir semt sınırına denk gelmiyor. Karaman’da bölge bir poligon ve restoran onu panelde kendisi çiziyor: nokta ekleme, son noktayı geri alma ve mevcut poligonu düzenleme destekleniyor.

Çizilen şekle güvenilmiyor. Bölgeler geography_helpers ve delivery_zone_rpc migration’larıyla PostGIS’te tutuluyor ve sunucu kaydetmeden önce geçerli bir Polygon olup olmadığını denetliyor; geçersiz bir şekil kayda girmiyor. Müşterinin adresi bölge içinde mi sorusu da istemcide değil sunucuda cevaplanıyor ve kural tek yerde duruyor.

Komisyon aynı veride hesaplanıyor: oran, sipariş toplamı üzerinden uygulanıyor (200 TL × %10 = 20 TL). Bekleyen komisyonlar için ayrı bir düzeltme migration’ı yazıldı; düzeltme veritabanında izlenebilir kaldı.

Bu yapı tek restoran için de, bir şehirdeki birçok restoran için de aynı: her restoran kendi bölgesini çiziyor, platform yalnız kuralları koruyor.

Mevcut site ve kullanıcı hesaplarıyla mobil uygulama nasıl birleşiyor?

Karaman.com’un mobil uygulamadan önce de kullanıcı hesapları, restoranları ve bir API’si vardı. Mobil uygulama bunları yeniden kurmadan, şehir portalını ve yemek siparişini aynı deneyimde sunmalıydı.

Bir köprü Edge Function’ı, bridge-session, karaman.com JWT’sini doğrulayıp Supabase profiline eşliyor. Sitenin gerçek e-postası kullanılıyor; daha önce oluşmuş sentetik profil e-postaları temizlendi. Uygulamanın içinde Karaman API anahtarı yok, çağrılar karaman-proxy üzerinden gidiyor.

Kod bir monorepo: Expo SDK 55 uygulaması ve ortak paketler (API istemcisi, tipler, yardımcılar). Mağaza derlemesini müşteri kendi Expo ve Firebase hesaplarından alıyor, bu yüzden kaynakta hiçbir gizli anahtar bulunmuyor. Production profili mock veriyle derlemeyi reddediyor; test verisiyle mağazaya çıkan bir sürüm mümkün değil.

Teslim Eylül 2026’da kaynak, kurulum talimatı ve sunucu yayın notlarıyla yapıldı. Uygulamanın şehir tarafında haber akışı, turistik yerler, nöbetçi eczane, hava durumu ve toplu taşıma saatleri; sipariş tarafında restoranlar, sipariş takibi ve kampanyalar var.

Yönetim panelinde komisyon, kampanya ve bildirim nasıl yönetiliyor?

Restoranın kendi paneli ile platformu yöneten panel ayrı arayüzler, ama aynı Supabase projesini paylaşıyor. Karaman yönetim panelinde ekranlar göreve göre ayrıldı: restoranlar (oluşturma ve mevcut bilgileri yükleyen düzenleme), kullanıcılar, siparişler, komisyonlar, kampanyalar, reklam bantları, yorum moderasyonu, ödeme ayarları, uygulama sürümleri ve raporlar.

Push bildirimleri, kayıtlı ve misafir kullanıcı segmentlerine, kategori tercihine göre gidiyor. Misafire ulaşabilmek için cihaz kaydı hesaptan bağımsız tutuluyor; yinelenen ve eski token’lar ayıklanıyor.

Reklam bantlarının bitiş tarihi ve aktiflik durumu var; süresi geçmiş ya da pasif bant mobilde hiç gösterilmiyor ve kimsenin elle kaldırmasını beklemiyor. Uygulama sürümleri panelden yönetiliyor.

Şehir hizmetleri de aynı panelde, kendi bölümlerinde: toplu taşıma saatleri, ATM’ler, şarj istasyonları ve su çeşmeleri. Tek bir restoran için bu kadar geniş bir panel gerekmez; kapsamı işletmenin büyüklüğüne göre keşifte birlikte çiziyoruz.

Toplama, kurye ve yöneticinin aynı siparişe baktığı operasyonlar

Yemek ve taze ürün teslimatında sipariş tek kişinin işi değil. HalApp’ta müşteri, toplayıcı, sürücü, yönetici ve admin aynı siparişin farklı aşamalarına bakıyordu. Beş ayrı uygulama hem maliyeti hem tutarsızlığı artırırdı; tek uygulama ise her rolü kendi işine odaklı tutmak zorundaydı.

Çözüm tek bir Expo uygulamasında beş rol, her biri kendi rota grubunda. Müşteri katalog, sepet, sipariş takibi ve bildirimleri görüyor; toplayıcı sipariş hazırlıyor; sürücü harita üzerinde rota ve teslimatları görüyor; yönetici onayları ve müşterileri, admin pano, personel ve ürünleri yönetiyor. Rol girişte belirleniyor ve gezinme ona göre kuruluyor, bu yüzden sürücü hiçbir zaman ürün yönetimi ekranına düşmüyor.

Durum yönetiminde zustand, stilde NativeWind, haritada react-native-maps kullanıldı. Katalog, sepet, sipariş hazırlama, teslimat ve onay akışları iOS ve Android için tek kod tabanında müşteriye teslim edildi; proje arşivde.

Restoranınızın kendi kuryesi, paket servis ekibi ya da merkez mutfaktan şubelere dağıtımı varsa bu rol ayrımı doğrudan uygulanabiliyor.

Siparişten önce: mekân keşfi ve tarif içeriği

Her yemek projesi bir sipariş akışı değil. Düzce Biz, şehirdeki mekânları, kampanyaları ve etkinlikleri tek uygulamada toplayan kendi ürünümüz. Expo mobil uygulama, Next.js 16 üzerinde işletme ve admin panelleri ve Firebase Cloud Functions tek bir monorepo’da. Mekânlar harita ve listede kategori, mesafe ve şu an açık olma durumuna göre süzülüyor.

İşletme uygulamadan başvuruyor; admin onaylayınca onApplicationApproved tetikleyicisi hesabı ve profili açıyor. Sunucuda zamanlanmış işler var: cleanupExpiredCampaigns süresi dolan kampanyaları kaldırıyor, notifyClosingSoonFavorites favori mekân kapanmak üzereyken kullanıcıya haber veriyor, calculateBusinessRating her yeni yorumda puanı yeniden hesaplıyor.

Dine Divine ise şefler için bir iOS tarif platformu. Şef tarifleri adım adım yönergelere bölündü: her adım tek ekran ve tek iş. Topluluk kendi tariflerini paylaşabiliyor, ama seçkin kütüphane ayrı bir alan ve topluluk içeriğiyle karışmıyor.

Restoranınız için menü, kampanya ya da sadakat tarafı sipariş kadar önemliyse bu iki ürünün kararları başlangıç noktası oluyor.

Sık sorulan sorular

İLGİLİ STÜDYO NOTLARI