Güvenlik

Sanal Numara ve Doğrulama Servisi Satışının Kimsenin Yüksek Sesle Söylemediği Yasal Sınırı: Paneli Kapatan O Tek Kayıt Eksikliği Nerede Saklı?

Sanal numara ve SMS doğrulama satışında yasal sınır tam olarak nerede başlıyor? Kayıt, KVKK ve ödeme riskini e-pin scripti tarafında nasıl yönetirsin?

Sanal Numara ve Doğrulama Servisi Satışının Kimsenin Yüksek Sesle Söylemediği Yasal Sınırı: Paneli Kapatan O Tek Kayıt Eksikliği Nerede Saklı?

Ç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.

%71İtirazlı işlemde kayıt yetersizliği
48 saatResmi talebe ortalama yanıt süresi
3 katKayıtsız panelde hesap dondurma oranı
%9Doğrulama satışında ortalama iade payı

“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 tetikleyiciMuhtemel sonuçÜrün tarafındaki panzehir
Hizmet tanımıAbonelik/operatör izlenimi veren vitrin diliGereksiz düzenleme tartışmasıÜrün şablonunda sabit hizmet tanımı
Kayıt yetersizliğiTalep anında log bulunamamasıİyi niyet savunmasının çökmesiDeğiştirilemez işlem günlüğü
Veri saklamaSMS gövdesinin süresiz tutulmasıKVKK ihlali iddiasıMaskeleme + otomatik imha
Ödeme riskiYüksek itiraz ve zincirleme iadeHesap dondurma, rezervLimit, hız kısıtı, risk skoru
Kötüye kullanımYasaklı servis için toplu talepPlatform şikâyeti, IP blokajıServis kara listesi, kota
Tüketici şikâyetiCayma hakkının belirsizliğiİade zorunluluğu, cezaAnı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.

Küçük ayar, büyük koruma

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.

KontrolNe zaman bakılırHazır sayılma ölçütü
Hizmet tanımı metniLansman öncesiAbonelik/operatör imasız, tek sayfa
Anında ifa ve cayma onayıHer siparişteZaman damgalı onay kaydı var
SMS gövdesi maskelemeKurulumdaKod dışındaki içerik saklanmıyor
Otomatik imha göreviHaftalıkGörev başarıyla çalışıyor, log tutuyor
Servis kara listesiAylıkYasaklı servisler satın alınamıyor
Risk kurallarıAylıkHız, kart, cihaz kuralları aktif
İtiraz dosya şablonuÇeyreklikTek tıkla işlem dökümü çıkıyor
Yetki ayrımıÇeyreklikDestek 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.

Daha Fazlasını Keşfedin

Dijital ürün satışı ve otomasyon üzerine güncel rehberlere göz atın.

Tüm Yazıları Gör →
Bu yazıyı paylaşın
Bu yazıyı beğendiniz mi?
Teşekkürler!
← Tüm yazılar