Epin Satış Paneli Tedarikçi Sözleşmende Kimsenin Sana Göstermediği Teknik Ekler: İmzaladığın O Kağıt Neden Seni Korumuyor?

Çoğu panel sahibi tedarikçi sözleşmesini bir formalite sanır. Bayilik başvurusunu doldurur, karşı taraf iki sayfalık bir metin gönderir, altına imza atılır ve iş biter. İçinde ne yazdığını gerçekten okuyan kişi sayısı çok az; okuyanların büyük kısmı da yalnızca komisyon oranına, ön ödeme tutarına ve fesih maddesine bakar. Oysa o sözleşmenin ticari kısmı en zararsız bölümüdür. Seni gerçekten yakan şey, hiç yazılmamış olan teknik eklerdir.

Bunu bir gece yarısı öğrenirsin. Saat 23.40, kampanya trafiği tepede, tedarikçinin API'si yanıt vermiyor. Müşteriler ödeme yaptı, kod gelmedi, panelde sipariş "beklemede" kaldı. Sabah tedarikçiye yazdığında aldığın cevap tek cümle olur: "Sözleşmede kesintisiz hizmet taahhüdü yok." Haklıdır da. Çünkü uptime, yanıt süresi, tekrar denenebilirlik, kod geçerlilik süresi gibi maddeler bir e-pin satış scripti işletmecisinin hayatını belirlediği halde neredeyse hiçbir standart sözleşmede geçmez. Bu yazıda, imzadan önce eklemen gereken teknik ekleri madde madde açıyorum.

Sözleşmedeki "kesintisiz hizmet" ifadesi neden hiçbir şey ifade etmez?

Hukuk dili ile mühendislik dili aynı şey değildir. "Tedarikçi hizmetin kesintisiz sunulması için gerekli özeni gösterir" cümlesi, ölçülemediği için uygulanamaz. Teknik ek yazarken kurman gereken cümle şudur: hizmet erişilebilirliği takvim ayı bazında en az yüzde 99,5 olacak; ölçüm, tedarikçinin kendi paneli değil, senin tarafındaki sağlık kontrolü uç noktasına atılan dakikalık isteklerle yapılacak. Ölçümü kimin yaptığı, taahhüt oranının kendisinden daha önemlidir.

İkinci eksik, kesintinin tanımıdır. API ayakta ama sorgu 40 saniyede dönüyorsa bu teknik olarak kesinti değildir, ticari olarak tam bir felakettir. Bu yüzden ekte yanıt süresi tavanı da bulunmalı: sipariş oluşturma çağrısı p95 değerinde 3 saniyeyi, stok sorgusu 1,5 saniyeyi geçmeyecek. Bir dijital ürün satış yazılımı kullanıyorsan bu değerleri zaten loglarsın; loglamıyorsan sözleşmeyi tartışacak verin de yok demektir.

Aynı siparişi iki kere göndersen ne olur? Idempotency maddesi

Panelin zaman aşımına düştü, isteği tekrar gönderdin. Tedarikçi bunu iki ayrı sipariş sayıp iki kod düşerse, ikinci kodun bedelini kim öder? Teknik eki olmayan yüzlerce panelde bu soru her ay tartışma konusu olur. Çözümü basittir: her sipariş isteğinde senin ürettiğin tekil bir referans anahtarı gönderilir, tedarikçi aynı anahtarla gelen tekrarlı istekte yeni sipariş açmaz, ilk siparişin sonucunu döndürür. Bu maddeye "tekrarlı istek güvenliği" adını verip anahtarın en az 24 saat saklanacağını da yazmalısın.

Aynı bölümde iki şey daha netleşmeli. Birincisi, zaman aşımına düşen bir isteğin durumunu öğrenmek için bir sorgulama uç noktası olacak; ikincisi, belirsiz kalan siparişlerin ne kadar süre sonra otomatik iptal edileceği belirli olacak. İyi bir e-pin yazılımı bu döngüyü kendi kuyruğunda zaten yönetir, ama karşı taraf sözleşmeyle bağlı değilse senin kuyruk mantığının hiçbir hükmü kalmaz.

Kodun formatı ve geçerlilik süresi neden hukuki bir konudur?

Teslim edilen kodun uzunluğu, karakter seti, tire kullanımı, bölge kilidi ve son kullanma tarihi teknik detay gibi görünür. Gerçekte bunlar müşteri şikayeti üretim hattıdır. Bölge kilitli bir kodu Türkiye pazarına satarsan iade dalgası gelir; son kullanma tarihi altı hafta olan bir kodu stokta üç ay tutarsan zarar senin olur. Teknik ekte kod şeması örnekle tanımlanmalı, bölge bilgisi zorunlu alan yapılmalı ve minimum kalan geçerlilik süresi taahhüt edilmelidir.

Buraya bir de "değiştirme" maddesi eklenmeli: tedarikçi kod şemasını veya API alan adlarını değiştirecekse en az 15 gün önce yazılı bildirim yapacak ve eski şema geçiş süresince çalışmaya devam edecek. Habersiz alan adı değişikliği, panelini bir gecede satış yapamaz hale getirebilen en sinsi risktir.

Stok rezervasyonu kimin sorumluluğunda? Burada kimse konuşmuyor

Vitrininde "stokta var" yazıyorsa bunun teknik bir dayanağı olmalı. İki model vardır: tedarikçi sana stok adedini bildirir ve sen tahmin yürütürsün ya da tedarikçi sipariş öncesi rezervasyon verir. İlk modelde sorumluluk sende, ikincisinde onda. Sözleşme bunu yazmıyorsa varsayılan olarak sorumluluk sana geçer, çünkü müşteri parayı sana ödedi.

Teknik eke şu satırı koy: stok bilgisi en az 60 saniyede bir güncellenecek, kritik ürünlerde rezervasyon uç noktası sağlanacak ve rezervasyon süresi en az 10 dakika olacak. Ayrıca "stok sıfırlandığında tedarikçi bildirim (webhook) gönderecek" maddesi, gün içinde tükenen popüler ürünlerde iade oranını gözle görülür biçimde düşürür. Modern bir epin yazılım altyapısı bu bildirimi alıp ilgili ürünü otomatik pasife çeker; Pinova tarafında bu davranışı ürün bazında ayarlayabilirsin.

İade, hatalı kod ve chargeback: yükü kim taşıyor?

Dijital ürün satışında iade tartışmalıdır, ama hatalı kod tartışmalı değildir. Kullanılmış, bölge kilitli ya da hiç etkinleşmeyen bir kod geldiğinde bunun bedelini tedarikçinin karşılaması gerekir. Sözleşmede bu yalnızca "gerekli incelemeyi yapar" ifadesiyle geçiyorsa inceleme süresi belirsiz kalır. Ek şu üç rakamı içermeli: bildirim süresi (senin kaç gün içinde bildirmen gerektiği), çözüm süresi (onun kaç saatte kod değiştireceği) ve kanıt formatı (ekran görüntüsü, hata metni, platform yanıtı).

Kart itirazı tarafı daha keskindir. Bir müşteri ödemeyi itiraz ettiğinde bankaya teslim kanıtı sunman gerekir. Bu kanıtın içinde teslim zaman damgası, kodun maskelenmiş hali ve IP kaydı bulunur. Tedarikçiden "talep halinde 48 saat içinde teslim kanıtı sağlar" maddesini almadıysan itirazların önemli kısmını kaybedersin. Bu tek madde, yıllık cirosu orta ölçekli bir panelde bile kayda değer bir tutar demektir.

Test ortamı olmayan tedarikçiyle çalışmak neden kumar?

Yeni ürün ekleyeceksin, fiyat kuralını değiştireceksin ya da teslim şablonunu güncelleyeceksin. Test ortamı yoksa bunu canlıda, gerçek parayla denemek zorunda kalırsın. Teknik ekte "tedarikçi ücretsiz bir test ortamı ve en az üç adet test kodu sağlayacak" maddesi bulunmalı. Yanında rate limit de yazılmalı: dakikada kaç istek atabileceğini bilmiyorsan kampanya anında kendi trafiğin yüzünden engellenebilirsin.

Son olarak veri tarafını netleştir. Hangi müşteri verisini tedarikçiye gönderiyorsun? İdeal cevap: hiçbirini. Sipariş isteğinde ad, e-posta veya telefon paylaşmak zorunda kalıyorsan bu verinin saklama süresi ve amacı ekte yazılı olmalı. Kişisel veri tarafında sorumluluk zinciri her zaman senden başlar, çünkü müşteri ilişkisi seninle kurulmuştur. Aşağıdaki kontrol listesini imza öncesi tek tek işaretle.

Bu ekleri panelin gerçekten uygulayabiliyor mu?

Sözleşmeye eşik yazmak kolaydır; onu ölçmek ve otomatik davranışa çevirmek başka bir iştir. Yanıt süresi eşiğini yazdıysan panelinin istek sürelerini kaydetmesi gerekir. Çift teslim korumasını yazdıysan sipariş referanslarının tekil olması ve tekrarlı çağrıların bastırılması gerekir. Stok bildirimi maddesini yazdıysan gelen bildirimi işleyip ürünü pasife alacak bir mekanizman olmalı. Yani teknik ek, altyapı ile birlikte anlam kazanır.

Pinova'nın tedarikçi katmanı tam olarak bu nedenle şablon değil, kural tabanlı çalışır: her tedarikçi için ayrı zaman aşımı, tekrar deneme sayısı, sağlık eşiği ve yedek kaynak sırası tanımlarsın. Bir kaynak eşiği aştığında siparişler otomatik olarak ikinci kaynağa yönlenir ve sen sabah raporunda ne olduğunu görürsün. Böylece sözleşmedeki madde sadece bir cümle olmaktan çıkıp ölçülen ve uygulanan bir kural haline gelir. Ayrıntılar için özellikler bölümüne göz atabilirsin.

Tedarikçi ilişkisi güvenle değil, ölçümle yürür. Bugün yapacağın en kârlı iş, tek sayfalık bir teknik ek hazırlayıp bir sonraki görüşmede masaya koymak. Eşikleri panelinden çıkardığın gerçek verilerle doldurursan karşı tarafın itiraz alanı da kalmaz. Bu eşikleri ölçen, kural haline getiren ve kesintide otomatik yedek kaynağa geçen bir altyapıyı kendi gözünle görmek istersen canlı demo üzerinden tedarikçi ekranlarını inceleyebilir, fiyat tarafına da aynı sayfadan bakabilirsin.