Çoğu e-pin satıcısı mesafeli satış sözleşmesini şöyle düşünür: internetten bir metin bulunur, içindeki firma adı değiştirilir, sitenin altına bir link olarak konur, iş biter. Gerçekte olan ise şudur: tekstil ya da beyaz eşya satan bir mağaza için yazılmış, kargo, iade adresi, ambalaj ve teslim tutanağı kavramları üzerine kurulu bir metin, yıllarca binlerce dijital siparişin hukuki zeminini oluşturur. İşler yolundayken kimse bunu fark etmez.
Sorun, tek bir kodun "çalışmadı" dendiği anda başlar. Müşteri bankasına gider, banka senden belge ister, sen de sözleşmeni açıp okursun ve orada dijital ürünün nasıl teslim edildiğine, ne zaman tüketilmiş sayıldığına, cayma hakkının hangi anda ortadan kalktığına dair tek bir cümle bulunmadığını görürsün. Bu yazıda, e-pin ve dijital ürün satan bir işletmenin sözleşmesinde gerçekten bulunması gereken maddeleri, bu maddelerin kullandığın e-pin scripti ile nasıl konuşması gerektiğini ve kanıt zincirini nasıl kurduğunu adım adım açıyoruz.
Sözleşmen aslında fiziksel ürün için mi yazılmış?
Bir metni dijital satışa uygun kılan şey başlığı değil, içindeki fiil zamanlarıdır. Klasik şablonlarda teslim "kargoya verilme" veya "alıcıya elden ulaştırılma" ile tanımlanır. Senin ürününde kargo yoktur; teslim, bir kodun ekranda görünmesi veya bir e-postanın gönderilmesiyle gerçekleşir. Sözleşme bunu yazmıyorsa, teslim anının ne zaman olduğunu belirleme yetkisini karşı tarafa bırakmış olursun.
Kontrol etmenin en hızlı yolu kelime aramaktır. Metninde kargo, taşıyıcı, ambalaj, iade adresi, teslim tutanağı gibi ifadeler geçiyor ve bunların dijital karşılıkları tanımlanmamışsa, elindeki belge senin işini anlatmıyor demektir. İyi kurulmuş bir dijital ürün satış yazılımı bu metni sipariş akışının bir parçası gibi ele alır; kötü kurulmuş bir düzende sözleşme, kimsenin açmadığı bir footer bağlantısıdır.
Dijital ürünü hukuken nasıl tanımlarsın?
Sözleşmenin ürün tanımı bölümü, sattığın şeyin ne olduğunu bir yabancıya anlatacak kadar açık olmalı. "100 TL değerinde oyun kodu" yeterli bir tanım değildir. Tanım şunları içermelidir: ürünün türü (tek kullanımlık alfanümerik kod, hesap bakiyesi yüklemesi, abonelik süresi), geçerli olduğu platform ve bölge, geçerlilik süresi varsa bu süre, kullanım için gereken ön koşullar ve kodun tek kullanımlık olduğu, görüntülendikten sonra iptal edilemeyeceği bilgisi.
Bölge kısıtı özellikle kritiktir. Türkiye bölgesi için satılan bir kodun başka bir bölgedeki hesapta çalışmaması ürün kusuru değildir; ancak bunu sözleşmede ve ürün sayfasında yazmadıysan, müşteri açısından haklı bir şikâyet konusu haline gelir. E-pin satış scripti tarafında bu alanları ürün şablonuna gömdüğünde, her yeni ürün otomatik olarak doğru uyarıyla yayına girer.
| Madde | Şablonlarda gelen hali | Dijital ürün için doğru hali | Eksikse riski |
|---|---|---|---|
| Ürün tanımı | Ürün adı ve fiyat | Tür, platform, bölge, geçerlilik, tek kullanımlık ibaresi | Yanlış bölge şikâyeti, ürün kusuru iddiası |
| Teslim | Kargo ile alıcıya teslim | Kodun panelde görüntülenmesi veya e-posta iletimi anı | Teslim anının tartışmaya açılması |
| Teslim süresi | 30 gün içinde | Ödeme onayının ardından anında; stok yoksa azami süre ve iade | Gecikmede belirsizlik, kesin vade tartışması |
| Cayma hakkı | 14 gün koşulsuz | İfaya başlanmasıyla istisna, açık rıza kaydı ile birlikte | İstisnanın geçersiz sayılması |
| Ayıplı ifa | Ürün değişimi | Kod doğrulama prosedürü, platform hata ekranı talebi | Her şikâyette peşin iade baskısı |
| Kayıt ve delil | Yok | IP, zaman damgası, görüntüleme logu, e-posta teslim kaydı | İtirazda kanıtsız kalma |
Teslim anını kim belirliyor: sen mi, script mi?
Dijital satışta en pahalı belirsizlik, teslimin tam olarak hangi saniyede gerçekleştiğidir. Üç farklı an vardır: ödemenin onaylandığı an, kodun sipariş kaydına atandığı an ve müşterinin kodu gerçekten gördüğü an. Sözleşmende hangisini teslim saydığını yazmalısın; ve yazdığın an, yazılımının kayıt tuttuğu an ile aynı olmalı.
Sağlam pratik şudur: teslim, kodun müşteriye ilk kez görünür hale geldiği an sayılır ve bu an sisteme ayrıca yazılır. Pinova gibi bu iş için tasarlanmış bir e-pin yazılımı kullanıyorsan, sipariş kaydında ödeme onayı ile kod açılışı ayrı zaman damgalarıyla durur. Böylece "ben hiç görmedim" iddiasına karşı elinde tarih, saat, IP ve oturum bilgisi olur. Sözleşmenin ilgili maddesi de bu kaydı delil olarak tanımlar.
Dijital ürün şikâyetlerinin kaynak dağılımı
- Kod kullanılmış / ikinci kez kullanım denemesi 45%
- Yanlış bölge veya platform seçimi 25%
- Teslim gecikmesi ve stok sorunu 20%
- Gerçek tedarikçi kaynaklı hatalı kod 10%
Kod ifşa olduğunda sorumluluk zinciri nerede kopar?
Müşteri kodu ekranda gördü, ekran görüntüsü aldı, arkadaşına gösterdi ve kod kullanıldı. Şimdi sana dönüp "çalışmadı" diyor. Bu senaryoda seni koruyan şey iyi niyet değil, sözleşmedeki ifşa ve saklama yükümlülüğü maddesidir. Bu madde, kodun görüntülendikten sonra gizliliğini korumanın alıcıya ait olduğunu, üçüncü kişilere aktarılan kodların sorumluluğunun satıcıda olmadığını açıkça yazar.
Aynı maddenin bir de teknik ayağı vardır. Tedarikçiden gelen kodu düz metin olarak veritabanında tutuyorsan, ifşa iddiasında kendi sistemin de şüpheli hale gelir. Kodların şifreli saklandığı, yalnızca sipariş sahibinin oturumunda çözüldüğü bir dijital ürün satış scripti kurgusu, hem savunmanı hem de personel kaynaklı sızıntı riskini aynı hamlede kapatır.
Metnini her güncellediğinde yeni bir sürüm numarası ver ve siparişe o anki sürümün kimliğini yaz. Altı ay sonra gelen bir itirazda, müşterinin hangi metni onayladığını tartışmasız gösterebilmen gerekir.
Kanıt olmadan haklı olmak neden yetmez?
Hukuken haklı olmak ile itirazı kazanmak farklı şeylerdir. Banka veya tüketici hakem heyeti senin ne düşündüğünü değil, neyi belgeleyebildiğini değerlendirir. Bu yüzden sözleşmenin delil maddesi, sistem kayıtlarını taraflar arasında geçerli delil olarak tanımlamalı ve bu kayıtların neleri içerdiğini saymalıdır.
Pratikte bir itiraz dosyası şunları içerir: sipariş özeti, ödeme referansı, sözleşme onay kaydı (IP ve zaman damgalı), cayma hakkı bilgilendirmesinin onay kaydı, kodun görüntülenme logu ve varsa e-posta teslim kaydı. Bu altı parçayı tek ekrandan dışa aktarabiliyorsan, itiraz süreci bir kriz değil rutin bir işlemdir. Aktaramıyorsan, her itiraz saatler süren bir arkeoloji çalışmasına döner.
| Kontrol | Nerede olmalı | Durum sorusu | Öncelik |
|---|---|---|---|
| Dijital ürün tanımı maddesi | Sözleşme + ürün sayfası | Bölge ve tek kullanımlık ibaresi var mı? | Yüksek |
| Teslim anı tanımı | Sözleşme + sipariş kaydı | Metindeki an ile logdaki an aynı mı? | Yüksek |
| Cayma istisnası bildirimi | Ödeme adımı | Ayrı ve işaretlenmemiş bir onay olarak mı duruyor? | Yüksek |
| İfşa sorumluluğu maddesi | Sözleşme | Üçüncü kişiye aktarım açıkça yazılı mı? | Orta |
| Delil ve kayıt maddesi | Sözleşme | Hangi logların delil sayıldığı listelenmiş mi? | Orta |
| Sözleşme sürüm mührü | Sipariş kaydı | Eski siparişin metni geri çağrılabiliyor mu? | Orta |
| Şikâyet prosedürü | Sözleşme + destek akışı | Hata ekranı talebi standart mı? | Düşük |
Sözleşme metnini yazılıma nasıl bağlarsın?
Metni düzeltmek işin kolay yarısıdır. Zor yarısı, o metnin her siparişte fiilen uygulanmasını sağlamaktır. Bunun için üç bağlantı noktası kurarsın. Birincisi, sözleşme ve ön bilgilendirme formunun ödeme adımında dinamik olarak, sipariş kalemleriyle birlikte üretilmesi. İkincisi, onay anının IP ve zaman damgasıyla kaydedilmesi. Üçüncüsü, siparişin özet e-postasında metnin kalıcı bir kopyasının müşteriye gitmesi.
Bu üç bağlantı kurulduğunda, sözleşmen bir savunma belgesi olmaktan çıkıp işleyen bir sürecin parçası olur. Doğru kurulmuş bir e-pin satış yazılımı bunu yönetici panelinden ayar seviyesinde yapmanı sağlar; her ürün için ayrı metin, her kategori için ayrı uyarı, her sürüm için ayrı kayıt. Kodla uğraşmadan, tek yerden. Özellikler tarafında hangi kayıtların tutulduğunu tek tek görebilirsin.
Sözleşmeni bir metin dosyası değil, çalışan bir süreç yap
Ürün bazlı bilgilendirme, sürüm mühürlü onay kaydı ve tek tuşla itiraz dosyası. Pinova bunları hazır getirir.
Hazır bir mesafeli satış sözleşmesi şablonunu kullanmam yeterli mi?
Yeterli değil. Şablonlar fiziksel teslim üzerine kuruludur. Dijital ürün tanımı, teslim anı, ifşa sorumluluğu ve delil maddelerini kendi iş modeline göre eklemen, ardından bir hukukçuya doğrulatman gerekir.
Teslim anını "ödeme onayı" olarak yazmak daha mı güvenli?
Kâğıt üzerinde avantajlı görünür ama müşteri kodu hiç görmediyse savunması güçlüdür. Daha sağlıklısı, teslimi kodun görüntülendiği an olarak tanımlamak ve o anı kayıt altına almaktır.
Kodu gördükten sonra paylaşan müşteriye karşı ne yapabilirim?
Sözleşmende gizliliği koruma yükümlülüğü ve üçüncü kişiye aktarım maddesi varsa, görüntüleme logu ile birlikte itirazda güçlü bir dosya sunabilirsin. Bu madde yoksa kanıtın da bağlamı zayıflar.
Sözleşmeyi güncellediğimde eski siparişler ne olur?
Eski siparişler onay anındaki metne tabidir. Bu yüzden her siparişte sözleşme sürümünü kaydetmek, geriye dönük tartışmaları bitiren en basit önlemdir.
Sözleşme maddelerini düzeltmek bir öğleden sonranın işi; onları her siparişte otomatik uygulayan bir altyapı kurmak ise mimari bir tercihtir. Pinova'nın sipariş kaydında hangi alanların tutulduğunu, ön bilgilendirme formunun ödeme adımında nasıl üretildiğini ve itiraz dosyasının nasıl dışa aktarıldığını görmek istiyorsan canlı demo üzerinden kendi test siparişini oluşturup kayıtları kendi gözünle incele; fiyat tarafında da hangi paketin bu modülleri kapsadığını karşılaştırabilirsin.