Özel okullarda tahsilat çoğunlukla elektronik tablolarda ve mesajlaşma gruplarında yürür. Bu okulda tanıtım sitesi, sanal POS'lu veli ödeme paneli ve toplu SMS altyapısı birlikte kuruldu; ödeme, takip ve bilgilendirme aynı kaydın üzerinde buluştu.
Tekirdağ Sınav Koleji için üç parça kuruldu: kayıt dönemine yönelik statik tanıtım sitesi, velilerin okul ücretini kredi kartı veya havale ile ödeyebildiği Docker üzerinde çalışan bir ödeme paneli ve öğrenci rehberine bağlı bir toplu SMS paneli. Ödeme tarafında iki banka sanal POS'u (Vakıfbank ve Garanti) canlı olarak entegre edildi; havale bildirimleri için okul yönetimine onay/red akışı eklendi. Sistem 285 öğrenci ve 353 veli kaydıyla çalışıyor.
Özel okul aramaları güçlü biçimde mevsimlik ve yereldir. Veliler "Tekirdağ özel okul", "Süleymanpaşa anaokulu" gibi ifadelerle arar ve kayıt dönemi dışında bu aramalar neredeyse durur. Site bu davranışa göre kuruldu: kampüs, kademeler (anaokulu, ilkokul, ortaokul, Anadolu ve Fen Lisesi) ve ön kayıt akışı öne çıkarıldı.
Site statik HTML olarak üretiliyor — bir üretici betikten. Bu tercihin nedeni okul sitelerinin tipik yaşam döngüsü: içerik yılda birkaç kez değişir, ama site kayıt döneminde yoğun trafik alır ve hiçbir zaman bakımsız kalmamalıdır. Statik bir site güncellenmemiş eklenti yüzünden ele geçirilmez, veritabanı çökmesi yaşamaz ve trafikte zorlanmaz.
Site Cloudflare arkasında yayında; bu yüzden içerik güncellemelerinde önbellek temizliği sürecin parçası. IndexNow ile arama motorlarına değişiklik bildirimi de kurulumun içinde.
Bu projede sıklıkla atlanan ama en kritik adımlardan biri şuydu: banka sanal POS başvurusu, sitede belirli yasal sayfaların bulunmasını şart koşuyor.
Mesafeli satış sözleşmesi, gizlilik politikası, iptal ve iade koşulları, teslimat/hizmet bilgisi, iletişim bilgileri ve KVKK aydınlatma metni yoksa başvuru ilerlemiyor. Bu sayfalar sonradan eklenen bir formalite değil, ödeme altyapısının ön koşulu. Bu yüzden altı yasal sayfa daha tanıtım sitesi yayına alınırken hazırlandı.
Ödeme sistemi kuracak her işletme için pratik sonuç: yasal sayfaları POS başvurusundan önce yayına alın. Aksi hâlde teknik iş biter, sistem başvuru bekler.
Ödeme paneli, tanıtım sitesinden ayrı bir uygulama olarak, Docker üzerinde çalışıyor. Panelin temel işleyişi:
Sanal POS tarafında iki banka birden canlı: Vakıfbank ve Garanti. İki POS'un birlikte bulunması yalnızca yedeklilik değil, aynı zamanda taksit ve komisyon esnekliği sağlıyor — kampanyalı taksit imkânı bankaya göre değişiyor.
Türkiye'de okul ödemelerinin önemli bir kısmı hâlâ havale/EFT ile yapılıyor. Bu, sistem açısından kart ödemesinden daha zor bir durum: para bankaya gidiyor ama sistem bunu kendiliğinden bilmiyor.
Bunun için panele havale bildirimi ve yönetici onay/red akışı eklendi. Veli havaleyi yaptıktan sonra sistemden bildirim oluşturuyor; okul yönetimi banka hesabıyla karşılaştırıp onaylıyor ya da reddediyor. Onaylanan bildirim taksite işleniyor.
Bu özellik eklendiğinde işleme alınmayı bekleyen yirmiden fazla bildirim birikmişti — yani ihtiyaç varsayımsal değildi, sistemde gerçekten sıkışmış bir iş vardı. Bildirimlerin okul yönetimine ulaşması için birden çok alıcıya e-posta gönderimi de kuruldu; tek kişiye bağlı bir sürecin izinli veya meşgul olduğu gün tıkanmaması için.
Okul iletişiminin büyük kısmı SMS ile yürüyor: ödeme hatırlatması, duyuru, acil bilgilendirme. Bunun için NetGSM REST API üzerinde çalışan bir toplu SMS paneli geliştirildi ve öğrenci rehberine bağlandı.
Kritik tasarım kararı, SMS panelini ayrı bir rehberle değil ödeme sistemindeki öğrenci kayıtlarıyla aynı veriden beslemek oldu. İki ayrı liste tutulduğunda listeler kaçınılmaz olarak ayrışır: numarası değişen veli bir listede güncellenir, diğerinde kalır. Tek kaynak kullanıldığında ödeme hatırlatması doğru kişiye gider.
Sistem 285 öğrenci kaydına karşılık 341 telefon numarasıyla senkron çalışıyor — bir öğrencinin birden fazla ulaşılabilir velisi olabildiği için bu iki sayı doğal olarak farklı.
Ödeme paneli ayrı bir alt alan adında yayında. Burada dikkat gerektiren bir ayrıntı çıktı: Cloudflare'in ücretsiz Universal SSL sertifikası yalnızca birinci seviye alt alan adlarını kapsar. Yani odeme.alanadi.com kapsanır, www.odeme.alanadi.com kapsanmaz.
Veliler adres çubuğuna alışkanlıkla "www" yazdığı için bu ayrıntı gerçek bir hata kaynağıydı: ödeme sayfasına ulaşmaya çalışan veli sertifika uyarısı görüyordu. Çözüm, sunucu üzerinde ikinci seviye adı da kapsayan bir sertifika almak ve www adresini kalıcı yönlendirmeyle asıl adrese göndermek oldu. Sertifika yenileme zinciri de bu değişiklikten sonra ayrıca doğrulandı — bir kez çalışan sertifika, yenilenmediği gün çalışmayan sertifikadır.
Okul bugün tahsilatını, taksit takibini ve veli bilgilendirmesini tek sistemden yürütüyor. Kart ödemeleri iki banka POS'u üzerinden anında işleniyor, havale bildirimleri yönetici onayıyla kayda geçiyor, hatırlatmalar aynı öğrenci verisinden SMS olarak gidiyor.
Devredilebilir ders: okul ödeme sistemi kurarken en riskli kısım kod değil sıra. Yasal sayfalar POS başvurusundan önce hazır olmalı, SMS rehberi ödeme verisiyle aynı kaynaktan beslenmeli ve sertifika kapsamı ödeme alt alan adının tam adresiyle test edilmeli. Bu üç madde atlandığında sistem teknik olarak "bitmiş" ama pratikte kullanılamaz durumda kalır.
Süreç teknikten çok evraksal. Banka, sitenizde mesafeli satış sözleşmesi, gizlilik politikası, iptal-iade koşulları, teslimat/hizmet bilgisi, iletişim ve KVKK aydınlatma metni bulunmasını şart koşar. Bu sayfalar hazır değilse başvuru ilerlemez. Teknik entegrasyon, onay çıktıktan sonra genellikle daha kısa sürer.
Otomatik banka mutabakatı kurmadan da çözülebilir: veli sistemden havale bildirimi oluşturur, okul yönetimi banka ekstresiyle karşılaştırıp onaylar veya reddeder. Onaylanan bildirim ilgili taksite işlenir. Bildirimin birden fazla yöneticiye e-posta olarak gitmesi, sürecin tek kişiye bağlı kalmasını önler.
Olur ama iki ayrı öğrenci listesi tutmuş olursunuz ve bu listeler zamanla mutlaka ayrışır. Numarası değişen veli birinde güncellenir, diğerinde kalır; ödeme hatırlatması yanlış kişiye gider. Doğru kurulum, SMS panelinin ödeme sistemindeki öğrenci kayıtlarını doğrudan kullanmasıdır.
İki farklı risk ve bakım profili var. Tanıtım sitesi halka açık, sık okunan, nadiren değişen bir yüzey; ödeme paneli kişisel veri ve para hareketi taşıyan kapalı bir uygulama. Ayrı tutulduğunda tanıtım sitesinde yapılan bir değişiklik ödeme sistemini riske atmaz, panel güncellemesi de siteyi kesintiye uğratmaz.