Çoğu e-pin satıcısı tedarikçiyle ilişkiyi ticari bir konu sanır: fiyat, stok, ödeme vadesi, bayi iskontosu. Sözleşme varsa bile içinde tek bir konu vardır, o da paradır. Oysa tedarikçine her sipariş iletiminde giden şey sadece ürün talebi değil; çoğu zaman müşterinin e-postası, oyun içi kullanıcı adı, telefonu veya sipariş numarası da beraber gider. O anda tedarikçin senin adına veri işleyen bir tarafa dönüşür ve bu ilişkinin yazılı bir çerçevesi yoksa, olası bir sızmada muhatap sensin.
Ödeme sağlayıcısında durum bir adım daha karışık. Bazı sağlayıcılar senin talimatınla çalışan bir işleyen gibi davranır, bazıları ise kendi yasal yükümlülükleri nedeniyle bağımsız karar verici konumundadır. Bu ayrımı bilmeden imzalanan sözleşme, sorumluluğu kâğıt üzerinde doğru dağıtmaz. Doğru kurgulanmış bir e-pin satış scripti burada işini kolaylaştırır: hangi entegrasyona hangi alanların gittiğini tek ekranda gösterir, böylece sözleşme ekini tahminle değil gerçek veri akışıyla yazarsın. Aşağıda bu eki nasıl kuracağını, hangi maddelerin pazarlık dışı olduğunu ve entegrasyon başına neyin doğrulanacağını açıyoruz.
Tedarikçin "veri işleyen" mi, yoksa ayrı bir sorumlu mu?
Ayrım basit bir soruyla netleşir: veriyi ne için kullanacağına kim karar veriyor? Sen sipariş iletiyorsun, tedarikçi bunu yalnızca kodu teslim etmek için kullanıyorsa işleyendir; senin talimatınla hareket eder. Ama aynı tedarikçi müşteri e-postasını kendi pazarlama listesine ekliyorsa, o veri üzerinde kendi amacını belirlemiş olur ve bağımsız sorumlu hâline gelir. İkinci durumda sözleşmede yalnızca gizlilik değil, amaç sınırlaması da açıkça yazılmalıdır: "Aktarılan veriler yalnızca sipariş ifası için kullanılır, hiçbir pazarlama faaliyetinde işlenemez." Bu tek cümle, ileride müşterinin başka bir yerden gelen tanıtım e-postasıyla sana dönmesini engeller. Kullandığın dijital ürün satış scripti tedarikçiye gönderilen alanları kısıtlayabiliyorsa, ilişkiyi daha da sağlam kurarsın: gitmeyen veri, korunması gerekmeyen veridir.
Hangi entegrasyona gerçekten hangi veri gidiyor?
Sözleşme yazmadan önce envanter çıkarmak zorunludur, çünkü çoğu satıcı ne gönderdiğini tam bilmez. Entegrasyon dokümanları "opsiyonel" diye işaretlediği alanları çoğu kurulumda otomatik doldurur ve müşterinin telefon numarası, ihtiyaç olmadığı hâlde tedarikçiye ulaşır. Envanteri çıkarmanın en hızlı yolu, panelin giden istek kayıtlarına bakmaktır. Aşağıdaki tablo tipik bir e-pin kurulumunda akışın nasıl göründüğünü gösteriyor; kendi listeni bunun üstüne kurabilirsin.
| Dış taraf | Aktarılan alanlar | Rolü | Gerekli belge |
|---|---|---|---|
| E-pin tedarikçisi / bayi API | Sipariş no, ürün kodu, oyun kullanıcı adı | Veri işleyen | Veri işleyen eki + gizlilik |
| Ödeme sağlayıcısı | Ad, e-posta, tutar, IP | Genelde ayrı sorumlu | Ortak çerçeve + aydınlatmada isim |
| E-posta / SMS servisi | E-posta, telefon, ad | Veri işleyen | Veri işleyen eki |
| Analiz ve reklam aracı | Çerez kimliği, davranış | Ayrı sorumlu | Rıza + aydınlatmada isim |
| Sunucu / barındırma | Tüm veritabanı | Veri işleyen | Veri işleyen eki + yer bilgisi |
| Fatura / muhasebe yazılımı | Ad, adres, tutar, vergi no | Veri işleyen | Veri işleyen eki |
Veri işleyen ekinde pazarlık dışı maddeler hangileri?
Ek uzun olmak zorunda değil, ama beş başlık mutlaka bulunmalı. Birincisi talimatla bağlılık: işleyen yalnızca senin yazılı talimatın çerçevesinde işler. İkincisi alt işleyen bildirimi; tedarikçin işi başka bir firmaya devrediyorsa bunu önceden bilmen ve itiraz hakkın olmalı. Üçüncüsü güvenlik tedbirleri: şifreleme, erişim kontrolü, log tutma gibi somut maddeler; "gerekli tedbirler alınır" cümlesi hiçbir şey ifade etmez. Dördüncüsü ihlal bildirimi ve süresi; "gecikmeksizin" yerine somut bir saat yazdırmaya çalış. Beşincisi sözleşme sonu: ilişki bittiğinde verinin silinmesi ya da iade edilmesi ve bunun yazılı olarak teyidi. Bu beş madde, iyi bir e-pin yazılımı ile birlikte kullanıldığında kâğıt üstündeki söz ile sistemdeki davranışı hizalar; özellikler tarafında entegrasyon bazlı alan kısıtlamasını görürsün.
Sözleşme eklerinde en sık eksik kalan maddeler
- Alt işleyen bildirimi 38%
- İhlal bildirim süresi 28%
- Sözleşme sonu silme teyidi 20%
- Somut güvenlik tedbirleri 14%
Yurt dışındaki sağlayıcıyla çalışmak ne değiştirir?
E-pin işinde tedarikçiler ve API sağlayıcıları sıklıkla yurt dışındadır; bu tek başına engel değil ama ek bir gereklilik doğurur. Verinin yurt dışına aktarıldığını aydınlatma metninde açıkça yazmak, aktarım için uygun bir hukuki zemin kurmak ve mümkünse verinin fiziksel olarak nerede tutulduğunu sözleşmede belirtmek gerekir. Pratik bir taktik de şudur: aktarılan alanı azalt. Tedarikçinin kodu teslim etmek için müşteri e-postasına ihtiyacı yoksa, ona sadece sipariş numarası gönder ve teslimi kendi panelinden yap. Aktarılan veri küçüldükçe hem sözleşme yükü hem risk küçülür. Panelinin dijital ürün satış yazılımı tarafında bu "minimum alan" ayarını entegrasyon başına yapabiliyorsan, hukuki tartışmanın büyük kısmını teknik bir ayarla kapatmış olursun.
Her entegrasyonun panel kaydına sözleşme tarihi, sürümü ve sorumlu kişi alanı ekle. Yeni bir tedarikçi eklerken bu alan boşsa kurulum tamamlanmasın; uyum böylece hatırlamaya değil sürece bağlanır.
Ödeme sağlayıcısıyla ilişkide hangi hata en pahalıya gelir?
En pahalı hata, kart verisiyle temas kurmaya çalışmaktır. Kart numarasını kendi formunda toplayıp sağlayıcıya iletmek, teknik olarak mümkün olsa bile seni tamamen başka bir yükümlülük setinin içine sokar. Doğru yol, ödemeyi sağlayıcının kendi sayfasında ya da güvenli çerçevesinde tamamlamak ve senin sisteminde yalnızca işlem sonucunu tutmaktır: işlem numarası, tutar, durum, son dört hane. İkinci sık hata, iade ve itiraz süreçlerinde müşteri verisini e-posta üzerinden dağıtmaktır; destek ekibin sipariş ekran görüntülerini yazışmaya eklediğinde veri kontrolsüz çoğalır. Bunun çözümü de süreçtir: itiraz dosyasını panel içinden, bağlantı ve süreli erişimle paylaş. Fiyat tarafında bu tür süreç özelliklerinin hazır gelmesi, aynı işi sonradan yazdırmaktan belirgin şekilde düşüktür.
Bu ilişkileri nasıl düzenli denetlersin?
Sözleşme imzalandıktan sonra dosyaya konur ve bir daha açılmaz; asıl sorun budur. Tedarikçi API'sine yeni bir alan eklendiğinde, sağlayıcı alt yükleniciyle çalışmaya başladığında ya da sen yeni bir mail servisi kurduğunda dünkü sözleşme bugünü karşılamaz. Aşağıdaki liste, bu kontrolü basit ve tekrarlanabilir hâle getirir.
| Kontrol | Nasıl doğrularsın | Sıklık | Kritiklik |
|---|---|---|---|
| Her entegrasyonun eki var mı | Panel entegrasyon listesi ile dosyayı karşılaştır | 3 ayda 1 | Yüksek |
| Giden alanlar sözleşmeyle aynı mı | Son 20 isteğin gövdesini incele | 3 ayda 1 | Yüksek |
| Alt işleyen değişikliği bildirildi mi | Sağlayıcı duyuru sayfası / e-posta arşivi | 6 ayda 1 | Orta |
| Aydınlatma metninde isimler güncel mi | Aktif entegrasyonlarla listeyi eşle | 6 ayda 1 | Yüksek |
| Ayrılan tedarikçide veri silindi mi | Yazılı silme teyidi dosyada | Her fesihte | Yüksek |
| API anahtarları döndürüldü mü | Anahtar oluşturma tarihleri | 6 ayda 1 | Orta |
Entegrasyonlarını sözleşmeyle birlikte yönet
Hangi tarafa hangi alan gidiyor, eki imzalı mı, anahtarı ne zaman döndü? Hepsi tek panelde görünsün.
Küçük bir tedarikçiyle de sözleşme eki şart mı?
Evet, hatta daha önemli. Büyük sağlayıcıların standart metinleri vardır; küçük tedarikçide hiç yoktur ve sızma olduğunda muhatap sensin. Tek sayfalık bir ek, karşı tarafı zorlamayacak kadar kısa ama seni koruyacak kadar somut olabilir.
Ödeme sağlayıcısı kendi sözleşmesini dayatıyor, ne yapayım?
Genelde metni değiştiremezsin ama okumak zorundasın. Amacın, onların hangi veriyi hangi rolle işlediğini öğrenmek ve bunu kendi aydınlatma metnine doğru yazmak. Rol yanlış yazıldığında sorumluluk dağılımı da yanlış anlatılmış olur.
Tedarikçi müşteri e-postasını istiyor, vermek zorunda mıyım?
Teslim akışına bağlı. Kod tedarikçi tarafından doğrudan müşteriye gönderiliyorsa gerekir; kodu sen teslim ediyorsan gerekmez. İkinci modeli seçmek hem riski hem sözleşme yükünü azaltır.
Sözleşmeyi feshedince veriyi sildiğini nasıl kanıtlarım?
Yazılı silme teyidi isteyerek. Fesih bildiriminde "aktarılan tüm verilerin 30 gün içinde silinip yazılı teyit verilmesi" cümlesi bulunsun; gelen teyidi entegrasyon kaydına ekle. Denetimde sorulan ilk belge bu olur.
Tedarikçi ve ödeme tarafındaki veri ilişkisi, iyi kurulduğunda görünmez olur; kötü kurulduğunda ise ilk sorunda tek başına seni bırakır. Entegrasyon başına giden alanları, imzalı ek kaydını ve anahtar döndürme geçmişini aynı ekranda görmenin nasıl bir şey olduğunu denemek istiyorsan canlı demo üzerinden panele girip bir tedarikçi entegrasyonu tanımlayabilir, sonra bu düzeni kendi sözleşme dosyanla eşleştirebilirsin.