Çoğu kişi sanal numara işini tek bir soruyla özetlemeye çalışır: “Bu iş yasal mı, değil mi?” Oysa bu soru daha sorulduğu anda yanlış yere bakıyor demektir. Çünkü sahada kapanan paneller, dondurulan ödeme hesapları ve gelen resmi yazıların neredeyse tamamı “sanal numara satmak” yüzünden değil, o satışın nasıl kayıtlandığı yüzünden başına gelir. Sınır ürünün kendisinde değil, ürünün etrafındaki kayıt disiplininde çizilir.
Bunu bir kez gördüğünde işin tonu değişir. Aynı hizmeti satan iki işletmeden biri yıllardır sorunsuz çalışırken diğeri altı ayda kapanıyorsa aradaki fark fiyat, tedarikçi ya da reklam değildir. Fark, birinin her doğrulama isteğini kim istedi, hangi servis içindi, hangi IP’den geldi, ne kadar süre erişilebilir kaldı diye zincirleyerek tutması; diğerinin ise bunu “gereksiz yük” sayıp silmesidir. Bu yazıda o zinciri tek tek kuracağız ve bir e-pin scripti üzerinde hangi alanların gerçekten savunma değeri taşıdığını göstereceğim.
“Sanal numara satışı yasak mı?” sorusu neden seni yanlış yere götürüyor?
Türkiye’de numara tahsisi, abonelik ve elektronik haberleşme hizmeti sunma yetkisi düzenlenmiş bir alandır. Ama senin sattığın şey çoğu zaman abonelik değil; üçüncü taraf bir platform üzerinden tek kullanımlık doğrulama erişimi. Bu ikisi hukuken aynı kefeye konmaz. Sorun, ikisi arasındaki çizginin sözleşmelerinde ve ürün açıklamalarında görünmemesidir. Müşterine “kendi numaran olacak” diye satarsan kendini abonelik satıyor gibi konumlandırırsın; “bir servis için tek seferlik kod alacaksın” diye satarsan aracılık ettiğin hizmetin sınırını doğru çizersin.
İkinci mesele kullanım amacıdır. Aynı ürün, bir kurumsal müşterinin test otomasyonunda kullandığında olağan; başkasının kimliğiyle hesap açmak için kullanıldığında suça araç olur. Sen niyeti okuyamazsın, ama niyeti sınırlayan kurallar koyabilirsin: hangi servisler satışa açık, hangileri kapalı, aynı kullanıcı aynı servis için kaç kez numara alabilir, hangi ülke havuzları devre dışı. Bu kararların tamamı ürün tarafında verilir ve bir dijital ürün satış scripti içinde kural olarak yaşamalıdır, destek ekibinin hafızasında değil.
Elektronik haberleşme ve tüketici mevzuatı seni tam olarak nereden yakalar?
Pratikte üç kapı var. Birincisi hizmet tanımı: kendini “operatör” gibi anlatan, numara portföyü satıyormuş gibi görünen bir vitrin, gereksiz bir düzenleme tartışmasının içine girer. İkincisi mesafeli satış yükümlülükleri: dijital içerik ve hizmetlerde ön bilgilendirme, cayma hakkının kapsamı ve anında ifa onayı net yazılmadıysa her iade talebi senin aleyhine yorumlanır. Üçüncüsü de kayıt saklama: bir talep geldiğinde “kimin, ne zaman, hangi servis için” sorusuna cevap veremiyorsan iyi niyet iddiası havada kalır.
Bu üç kapıdan geçmek pahalı bir iş değil. Pahalı olan, üçünü de sonradan düzeltmeye çalışmak. Ürün açıklamasında tek bir cümleyi değiştirmek bedava; altı ay sonra ödeme sağlayıcına yazıp itiraz yönetmek ise hem zaman hem itibar kaybı. Sınır, ürünü kurduğun gün çizilir.
KVKK açısından sattığın şey numara değil, kişisel veri geçidi mi?
Burada çoğu işletme sahibi tökezler. Doğrulama kodu geldiği anda sistemine bir SMS metni düşer. O metin, bazı servislerde kullanıcı adı, sipariş bilgisi hatta isim parçası taşır. Yani sen farkında olmadan üçüncü kişilere ait veriyi işleyen taraf haline gelirsin. Bu noktada iki yükümlülük doğar: veriyi amaçla sınırlı tutmak ve süreyle sınırlı saklamak.
Uygulaması basittir. Gelen mesaj gövdesini ham haliyle sonsuza kadar tutmak yerine, kodu çıkar, gövdeyi maskele, belirlenmiş süre sonunda otomatik sil. Ama silme politikasının bir istisnası olmalı: itiraz ve şikâyet dosyaları. O yüzden iki ayrı saat işletirsin; içerik kısa ömürlü, işlem meta verisi uzun ömürlü. İyi kurulmuş bir e-pin satış yazılımı bu ikisini aynı tabloda karıştırmaz.
| Risk katmanı | Somut tetikleyici | Muhtemel sonuç | Ürün tarafındaki panzehir |
|---|---|---|---|
| Hizmet tanımı | Abonelik/operatör izlenimi veren vitrin dili | Gereksiz düzenleme tartışması | Ürün şablonunda sabit hizmet tanımı |
| Kayıt yetersizliği | Talep anında log bulunamaması | İyi niyet savunmasının çökmesi | Değiştirilemez işlem günlüğü |
| Veri saklama | SMS gövdesinin süresiz tutulması | KVKK ihlali iddiası | Maskeleme + otomatik imha |
| Ödeme riski | Yüksek itiraz ve zincirleme iade | Hesap dondurma, rezerv | Limit, hız kısıtı, risk skoru |
| Kötüye kullanım | Yasaklı servis için toplu talep | Platform şikâyeti, IP blokajı | Servis kara listesi, kota |
| Tüketici şikâyeti | Cayma hakkının belirsizliği | İade zorunluluğu, ceza | Anında ifa onay kaydı |
Ödeme sağlayıcın seni neden mevzuattan önce cezalandırır?
Gerçek şu: çoğu işletme bir denetimle değil, bir ödeme kesintisiyle kapanır. Doğrulama hizmetleri yüksek itiraz oranı ürettiği için bankalar ve ödeme kuruluşları bu dikeyi baştan riskli sayar. İtiraz oranın eşiği geçtiği gün gelen e-posta tartışmaya açık olmaz; ya rezerv konur ya hesap durur.
Bunu düşürmenin yolu sihir değil, ölçüm. Aynı karttan gelen art arda küçük siparişler, hesap açılışından dakikalar sonra yapılan yüksek hacimli alım, birbirinden farklı isimlerle aynı cihaz parmak izi… Bunların her biri bir risk sinyali. Sinyali yakalayıp işlemi manuel onaya düşürmek, o siparişten kazanacağın kârdan kat kat değerlidir. Mimariyi kurarken özellik listesine bakıp “risk kuralı yazabiliyor muyum” sorusunu sormak, panel seçiminde fiyattan önce gelir.
Doğrulama satışında kapanma nedenlerinin dağılımı
- Ödeme/itiraz kaynaklı kesinti 45%
- Kayıt ve belge eksikliği 25%
- Platform şikâyeti ve blokaj 20%
- Diğer operasyonel nedenler 10%
Scriptin hangi kayıtları tutmazsa yarın savunmasız kalırsın?
Bir talep geldiğinde sana sorulacak sorular tahmin edilebilir: bu işlemi kim yaptı, hangi hesapla ödedi, hangi servis seçildi, numara ne kadar süre kullanıldı, kod teslim edildi mi, iade oldu mu. Bu altı sorunun cevabı tek ekranda çıkmıyorsa sorun hukukta değil, mimarindedir.
Bu yüzden işlem günlüğü sonradan düzenlenemez olmalı; admin dahil kimse geçmişe dönüp bir kaydı sessizce değiştirememeli. Değişiklik gerekiyorsa üstüne yeni bir kayıt yazılmalı. Böylece dosyan “biz böyle yaptık” beyanından “bak, sistem şunu kaydetmiş” kanıtına dönüşür. Aradaki fark, iki cümle değil, iki ayrı sonuçtur.
Sipariş ekranına tek satır ekle: kullanıcı hangi servis için aldığını kendi seçsin. Bu seçim hem kota kuralını hem savunmanı besler; niyet beyanı sende kayıtlı olur.
Riski satıştan vazgeçmeden nasıl daraltırsın?
Amaç ürünü öldürmek değil, satılabilir kısmını izole etmek. Yüksek riskli servisleri kataloğundan çıkarırsın, kalan kısmı kademeli limitlerle satarsın: yeni kullanıcı düşük kota, doğrulanmış müşteri yüksek kota. Kurumsal talebe ayrı bir kanal açarsın; sözleşmeli müşteri hem daha az itiraz üretir hem daha yüksek bilet ortalaması getirir.
Bir de fiyatlamayı riske göre kurmak var. Riskli havuzu ucuza satmak, kendine en kötü müşteri kitlesini satın almaktır. Doğru kurgu bunun tersidir: riski yüksek olan pahalı, denetimi kolay olan rekabetçi. Fiyat kurgusunu bu mantıkla yeniden yazdığında ciro biraz düşse bile net kârın ve panel ömrün uzar. Uzun ömür, bu dikeyde en pahalı metriktir.
| Kontrol | Ne zaman bakılır | Hazır sayılma ölçütü |
|---|---|---|
| Hizmet tanımı metni | Lansman öncesi | Abonelik/operatör imasız, tek sayfa |
| Anında ifa ve cayma onayı | Her siparişte | Zaman damgalı onay kaydı var |
| SMS gövdesi maskeleme | Kurulumda | Kod dışındaki içerik saklanmıyor |
| Otomatik imha görevi | Haftalık | Görev başarıyla çalışıyor, log tutuyor |
| Servis kara listesi | Aylık | Yasaklı servisler satın alınamıyor |
| Risk kuralları | Aylık | Hız, kart, cihaz kuralları aktif |
| İtiraz dosya şablonu | Çeyreklik | Tek tıkla işlem dökümü çıkıyor |
| Yetki ayrımı | Çeyreklik | Destek personeli log silemiyor |
Kayıt disiplinini ürünün içine gömmek istiyorsan
Pinova, doğrulama ve dijital ürün satışında işlem günlüğü, risk kuralları ve otomatik imha politikalarını tek panelde yönetmen için kurulmuş bir lisanslı satış yazılımıdır.
Sanal numara satmak için özel bir izin almam gerekiyor mu?
Sattığın şey abonelik ya da numara tahsisi değil, üçüncü taraf bir servis üzerinden tek kullanımlık doğrulama erişimiyse bu bir aracılık faaliyetidir. Kritik olan vitrin dilinin operatör izlenimi vermemesi ve sözleşme metinlerinin hizmeti doğru tanımlamasıdır.
Gelen SMS içeriklerini ne kadar süre tutmalıyım?
İçeriği mümkün olan en kısa süre tut, kodu çıkardıktan sonra gövdeyi maskele. İşlem meta verisini ise itiraz ve şikâyet süreçleri için daha uzun sakla. İki veriyi ayrı saklama süreleriyle yönetmek en güvenli yaklaşımdır.
Ödeme hesabımın dondurulmasını nasıl önlerim?
İtiraz oranını eşiğin altında tutarak. Hız kısıtı, kart ve cihaz bazlı kurallar, yeni kullanıcıya düşük limit ve şüpheli siparişte manuel onay bu oranı belirgin şekilde düşürür.
Müşteri kodu aldıktan sonra iade isterse ne olur?
Dijital hizmette anında ifa onayı zaman damgalı biçimde alınmışsa iade talebini reddetme zeminin güçlüdür. Onay kaydı yoksa tartışma büyük olasılıkla senin aleyhine sonuçlanır.
Bu işi uzun yıllar sürdürenlerin ortak özelliği cesaret değil, kayıt titizliğidir. Ürünü sadeleştir, riski fiyatla, her işlemi kanıtlanabilir hale getir; geri kalanı zamanla oturur. Kendi panelinde bu kayıt zincirinin nasıl göründüğünü merak ediyorsan canlı demo üzerinden sipariş, günlük ve risk ekranlarını dolaşıp kendi akışınla karşılaştırabilirsin.

