Bayilik ağı kurmak kulağa hep aynı şekilde geliyor: panel aç, fiyat listesi ver, bakiye yükleyen satsın. İlk aylar da genelde böyle geçiyor. Sonra bir gün bir bayi, yükleme yaptığı bakiyenin iadesini istiyor. Bir başkası kendi müşterisine yanlış kod verdiğini söyleyip zararı senden talep ediyor. Üçüncüsü sana verdiğin fiyatları ekran görüntüsüyle rakiplerine gönderiyor. O an dosyayı açıyorsun ve içinde ne olduğunu fark ediyorsun: bir WhatsApp konuşması, bir havale dekontu ve panelde açılmış bir hesap.
Çoğu işletme sahibi bayi sözleşmesini formalite sanır. Oysa sözleşme, ihtilaf çıktığında hangi tarafın ne yükümlülük altında olduğunu belirleyen tek belgedir ve dijital ürün satışında bu belge fiziksel olarak imzalanmaya kalkılırsa bayilik süreci ölür. Kimse kargo bekleyip ıslak imzayla evrak göndermek için sana bayi olmaz. Bu yazıda bayi sözleşmesini dijital ürün satış scriptinin içine nasıl gömeceğini, hangi imza türünün yeterli olduğunu ve ihtilaf anında elinde nasıl bir delil zinciri kalacağını anlatıyorum.
Islak imza bayilik modelini neden yavaşlatıyor?
Bayilik işinin dinamiği hız üzerine kurulu. Sana başvuran kişi genellikle o gün satış yapmak istiyor; bir oyun topluluğunun yöneticisi, küçük bir internet kafe işletmecisi veya kendi mağazasını kurmuş bir satıcı. Ona "sözleşmeyi indir, çıktı al, imzala, tara, gönder" dediğinde sürece beş gün ekliyorsun ve başvuruların çoğunu o beş gün içinde kaybediyorsun. Kaybetmediklerinde ise elinde düşük çözünürlüklü, tarihi belirsiz, gerçekten o kişinin imzaladığı ispatlanamayan bir görüntü kalıyor.
İkinci sorun ölçeklenme. Yirmi bayi ile evrak takibi yapılabilir, iki yüz bayi ile yapılamaz. Hangi bayinin hangi sürüm sözleşmeyi imzaladığını, komisyon oranı değiştiğinde kimin yeni eki onayladığını takip etmek elle imkânsız hale gelir. Dijital imza akışı bu takibi otomatikleştirir: sözleşme sürümü, imza tarihi, imzalayan kimlik bilgisi ve onay kaydı aynı kaydın parçası olur.
Dijital imza, e-imza, KEP: hangisi senin için yeterli?
Terimler karışıyor ve satıcılar bu karışıklığı kullanıyor. Üç seviyeyi ayırt etmen yeterli. Birinci seviye basit elektronik onay: bayi bir kutucuğu işaretler, sistem bunu IP, tarayıcı bilgisi, zaman damgası ve sözleşme metninin özetiyle kaydeder. İkinci seviye doğrulanmış onay: aynı akışa telefon veya e-posta doğrulaması eklenir, yani onaylayan kişinin o iletişim kanalına erişimi kanıtlanır. Üçüncü seviye nitelikli elektronik imza, yani yasal olarak ıslak imzayla eşdeğer kabul edilen, akredite sağlayıcıdan alınmış sertifikaya dayalı imza.
Pratik tavsiye şu: standart bayilik ilişkisi için ikinci seviye çoğu durumda yeterli ve orantılı. Kritik olan imzanın türü değil, imzalananın hangi metin olduğunu ispatlayabilmen. Bunun yolu sözleşme metninin kriptografik özetini (SHA-256) imza kaydıyla birlikte saklamak. Böylece yıllar sonra "ben bunu imzalamadım, metin sonradan değişti" iddiası geldiğinde, saklanan özetle o günkü metnin birebir aynı olduğunu gösterebilirsin. Yüksek limitli kurumsal bayiler veya taahhütlü hacim anlaşmaları içinse nitelikli imzaya çıkmak makul.
| İmza seviyesi | Ne kanıtlar | Onboarding hızı | Uygun senaryo |
|---|---|---|---|
| Basit onay (checkbox + log) | Onay verildiğini, metnin hangisi olduğunu | Anında | Düşük limitli mikro bayi |
| Doğrulanmış onay (SMS/e-posta OTP) | Onaylayanın kanala erişimini | 1-2 dakika | Standart bayilik |
| Kimlik doğrulamalı onay | Kişi/şirket kimliğini | Aynı gün | Yüksek limitli bayi |
| Nitelikli elektronik imza | Islak imza eşdeğeri | 1-3 gün | Kurumsal, taahhütlü hacim |
| Islak imza + kargo | Klasik yazılı delil | 3-7 gün | Özel talep hâlinde |
Sözleşmede mutlaka bulunması gereken maddeler
Şablonlardan kopyalanan sözleşmelerin çoğu fiziksel ürün ticareti için yazılmış. Dijital ürün satışında ise ihtilaflar çok farklı yerlerden çıkıyor. Bakiye iadesi ilk sırada: bayi yüklediği bakiyeyi nakde çevirmek isterse ne olur? Cevabın sözleşmede net yazması lazım, yoksa her seferinde pazarlık yaparsın. Teslim edilmiş kodun iadesi ikinci sırada: kod bir kez görüntülendiğinde iade edilemez ilkesini, hangi istisnalarla uyguladığını açıkça yaz.
Üçüncüsü fiyat gizliliği ve yeniden satış kuralları. Bayiye verdiğin özel fiyatın ifşası, tüm ağının fiyat yapısını bozar; bunun sonucu sözleşmede tanımlı olmalı. Dördüncüsü sorumluluk sınırı: bayinin kendi müşterisiyle yaşadığı sorunda senin yükümlülüğün nerede bitiyor? Beşincisi kötüye kullanım ve dolandırıcılık maddesi: çalıntı kartla yapılan yüklemelerde, ters ibrazlarda ve sahte sipariş akınlarında hesabı askıya alma hakkını saklı tut. Kalanlar için aşağıdaki kontrol listesini kullan.
Bayi ihtilaflarının konu dağılımı
- Bakiye ve iade talepleri 38%
- Teslim edilen kod / ürün itirazı 28%
- Fiyat, komisyon, gizlilik 20%
- Hesap askıya alma 14%
İmza akışını scriptine nasıl gömersin?
Doğru kurgu, sözleşmeyi kayıt akışının içine yerleştirmek. Bayi başvurusunu doldurur, panelde hesabı açılır ama sözleşme onaylanmadan bakiye yükleme ve satın alma yetkisi kapalı kalır. Onay ekranında sözleşmenin tam metni gösterilir, aşağı kaydırma zorunlu tutulur, telefon doğrulama kodu istenir ve onay verildiği anda sistem şu beş veriyi tek bir kayda yazar: sözleşme sürüm numarası, metnin SHA-256 özeti, onay zaman damgası, IP ve doğrulanmış telefon/e-posta.
Sürüm yönetimi burada kritik. Komisyon oranını veya iade politikasını değiştirdiğinde yeni bir sürüm yayınlarsın ve sistem, eski sürümü imzalamış bayilere bir sonraki girişte yeni sürümü onaylatır. Onaylamayan bayinin yeni koşullara tabi olmadığını da bilirsin, çünkü kayıt hangi sürümde kaldığını gösterir. Bir dijital ürün satış yazılımında bu mekanizma sonradan eklenmesi zor bir şey değil; ama baştan düşünülmediğinde yüz bayi biriktikten sonra geri dönük onay toplamak eziyete dönüşür. Bayilik modülünün nasıl çalıştığını özellikler bölümünde, limit ve komisyon ayarlarının hangi pakette geldiğini fiyat tablosunda görebilirsin.
Sözleşmenin o günkü halinin SHA-256 özetini imza kaydına yaz. Yıllar sonra çıkan "metin değişti" iddiasına karşı en güçlü cevabın bu tek satırlık veri olur; arşivdeki PDF ise tek başına tarihlendirilemez.
Delil değeri: ihtilafta tam olarak ne göstereceksin?
Bir uyuşmazlık ciddileşirse karşı tarafa ve gerekirse hukuki mercilere sunacağın şey tek bir ekran görüntüsü değil, tutarlı bir zincir olmalı. Bu zincir şöyle kurulur: başvuru kaydı, doğrulanmış iletişim kanalı, onaylanan sözleşme sürümü ve özeti, onay anının zaman damgası, sonrasındaki bakiye hareketleri ve teslimat kayıtları. Her halka bir diğerini destekler; tek başına zayıf görünen veriler bir arada çok güçlü bir anlatı oluşturur.
Bu kayıtların değiştirilemez olması da önemli. Yönetici panelinden silinebilen veya elle düzenlenebilen bir onay kaydının delil değeri düşer. Onay ve teslimat kayıtlarını yalnızca eklenebilir bir tabloda tutmak, her kayda öncekinin özetini karıştırmak ve bu tabloyu düzenli olarak ayrı bir yere yedeklemek işi sağlama alır. Ayrıca saklama süresine dikkat et: ticari belgeler için uzun bir ufka bakman gerekir, dolayısıyla "altı ay sonra logları temizliyoruz" politikası ticari kayıtlar için uygun değildir.
| Sözleşme maddesi | Neden gerekli | Durum |
|---|---|---|
| Bakiye iade koşulları | En sık ihtilaf konusu | Zorunlu |
| Teslim edilmiş kodun iade edilemezliği | Zarar kaynağını kapatır | Zorunlu |
| Fiyat ve komisyon gizliliği | Ağ fiyat yapısını korur | Zorunlu |
| Sorumluluk sınırı | Bayinin müşteri sorununu ayırır | Zorunlu |
| Kötüye kullanım / askıya alma hakkı | Dolandırıcılık ve ters ibraz | Zorunlu |
| Marka ve içerik kullanım izni | Yanlış temsili engeller | Önerilir |
| Veri işleme ve gizlilik | Müşteri verisi sorumluluğu | Zorunlu |
| Fesih ve bakiye tasfiyesi | Ayrılık anını düzenler | Zorunlu |
| Sürüm değişikliği ve yeniden onay | Koşul güncellemesini geçerli kılar | Önerilir |
| Uyuşmazlık ve yetkili merci | Süreci öngörülebilir yapar | Zorunlu |
Bayiliği evrak işine boğmadan büyüt
Pinova, sözleşme onayını kayıt akışının içine alan, sürüm takibi ve değiştirilemez onay kaydı tutan bir e-pin satış yazılımı. Bayi ağını yavaşlatmadan hukuki zeminini kur.
Checkbox ile alınan onay hukuken geçerli mi?
Elektronik ortamda verilen onaylar delil olarak değerlendirilebilir; belirleyici olan onayın hangi metne verildiğini ve kim tarafından verildiğini ispatlayabilmendir. Bu yüzden metin özeti, zaman damgası ve doğrulanmış iletişim kanalını birlikte saklaman gerekir.
Her bayi için nitelikli elektronik imza şart mı?
Şart değil ve pratikte ölçeklenmez. Standart bayilik için doğrulanmış onay çoğu durumda orantılıdır. Yüksek limitli veya taahhütlü hacim anlaşmalarında nitelikli imzaya çıkmak mantıklı olur.
Komisyon oranını değiştirdiğimde eski sözleşme ne olur?
Eski sürüm, bayi yeni sürümü onaylayana kadar geçerli kalır. Doğru akış, yeni sürümü yayınlamak ve bir sonraki girişte onay istemek; onaylamayan bayinin işlem yetkisini yeni koşullar kabul edilene kadar sınırlamaktır.
Onay kayıtlarını ne kadar saklamalıyım?
Ticari kayıt niteliğinde olduğu için uzun bir ufka planla; birkaç aylık log temizleme politikaları bu kayıtlar için uygun değil. Onay ve teslimat kayıtlarını ayrı, salt eklenebilir bir yapıda ve düzenli yedeklerle tut.
Bayilik ağı, güvene dayanan ama belgeyle ayakta duran bir yapı. Sözleşmeyi imza akışıyla birlikte sistemin içine gömdüğünde hem başvuruları kaybetmeden büyürsün hem de ilk ciddi ihtilafta elin boş kalmaz. Onay akışının, sürüm takibinin ve bayi limit yönetiminin bir arada nasıl çalıştığını görmek istersen canlı demo üzerinden bir bayi hesabı açıp kayıt sürecini baştan sona deneyebilir, ardından kurulum adımına geçebilirsin.