Satılık SMM panel alımı neden sıradan bir site satın alımı değildir?
Satılık SMM panel ilanı; yalnızca bir alan adı ve web arayüzünün devri anlamına gelmez. İşin içinde yazılım lisansı, kaynak kod, sunucu, sağlayıcı API bağlantıları, müşteri hesapları, bakiye kayıtları, ödeme altyapısı, destek talepleri ve marka varlıkları bulunabilir. Bu parçaların her biri farklı bir sahibin kontrolünde olabilir ve farklı yükümlülük taşıyabilir.
Alıcının temel hedefi, “çalışıyor” görünen panelin satış sonrasında da aynı koşullarda işletilip işletilemeyeceğini anlamaktır. Satıcının hedefi ise kapsamı açıkça belgeleyerek devir sonrası anlaşmazlıkları azaltmaktır. İyi bir panel devri, teslim edilecek varlıkların tek tek tanımlandığı bir süreçtir.
Bu rehber yatırım veya hukuk danışmanlığı değildir. Yüksek bedelli işlemlerde sözleşme, kişisel veri ve vergi boyutu için ilgili uzmanlardan destek alınmalıdır. Teknik demo ve gelir ekranı tek başına mülkiyet ya da sürdürülebilirlik kanıtı sayılmamalıdır.
İlan başlığı ve satış kapsamı nasıl okunmalı?
“Hazır SMM panel”, “aktif müşterili panel” ve “SMM panel yazılımı” aynı ürün değildir. Hazır panel; çalışan site, domain ve operasyonu kapsayabilir. Aktif müşterili panelde kullanıcı kayıtları ile ticari geçmiş gündeme gelir. Yalnız yazılım satışı ise çoğu zaman lisans veya kaynak kod teslimidir; domain, marka ve müşteri tabanı dâhil olmayabilir.
İlan metninde hangi varlığın satıldığı açıkça listelenmelidir. Domain, logo, sosyal medya hesapları, e-posta adresleri, sunucu, veritabanı, kaynak kod, lisans, API bakiyesi, ödeme hesabı ve destek kanalları ayrı satırlar hâlinde yazılmalıdır. “Her şey dâhil” ifadesi ayrıntılı envanterin yerini tutmaz.
Hariç tutulan varlıklar da belirtilmeli
Satıcı bazı varlıkları devretmeyebilir. Kişisel banka hesabı, başka projelerle ortak kullanılan sunucu, geliştirici hesabı, üçüncü taraf API anahtarı veya lisans devre kapalı olabilir. Satışa dâhil olmayan unsurların yazılması, dâhil olanların yazılması kadar önemlidir.
Domain ve marka sahipliği nasıl doğrulanır?
Domainin yönetim panelini görmek, kayıt sahibi olduğunuzu tek başına kanıtlamaz. Registrar adı, kayıt ve yenileme tarihi, transfer kilidi, iletişim e-postası ve devir yöntemi kontrol edilmelidir. ICANN kurallarında transferi başlatma yetkisi kayıt sahibine veya yetkili irtibata bağlıdır; bazı yeni kayıt ve değişikliklerde 60 günlük transfer kısıtı uygulanabilir.
Satıştan önce domainin hangi kişi veya şirket adına kayıtlı olduğu doğrulanmalı; ödeme planı transfer takvimine göre kurulmalıdır. Auth/EPP kodu herkese açık mesajda paylaşılmamalı, yalnız güvenli devir adımında kullanılmalıdır. Transfer tamamlandıktan sonra iletişim bilgileri, nameserver ve yenileme ayarları alıcı tarafından kontrol edilmelidir.
Marka adı için ayrıca tescil ve kullanım hakkı araştırılmalıdır. Domainin devri, aynı isim üzerindeki marka hakkının otomatik devri değildir. Logo dosyaları, tasarım hakları ve sosyal medya kullanıcı adları sözleşmede ayrı varlıklar olarak tanımlanmalıdır.
Yazılım lisansı ve kaynak kod için hangi belgeler gerekir?
Panel yazılımı üçüncü taraf bir geliştiriciden alınmış olabilir. Lisans sözleşmesi yeniden satışa, domain değişikliğine veya sahiplik devrine izin vermiyorsa alıcı sistemi yasal ve teknik olarak sürdüremeyebilir. Fatura, lisans anahtarı, satın alma hesabı ve geliştiricinin devir prosedürü kontrol edilmelidir.
Kaynak kod teslim edilecekse yalnız ZIP dosyası almak yeterli değildir. Kullanılan framework ve sürümler, bağımlılıklar, cron görevleri, queue sistemi, ortam değişkenleri, kurulum adımları ve veritabanı şeması belgelenmelidir. Özel geliştirme varsa kodun hak sahipliği ve başka müşterilerle paylaşılıp paylaşılmadığı açıklanmalıdır.
Nulled veya kaynağı belirsiz yazılım riski
Lisans kontrolü kaldırılmış, izinsiz kopyalanmış veya kaynağı bilinmeyen paketlerde zararlı kod, arka kapı ve güncelleme sorunu bulunabilir. Dosya taraması tek başına güvence sağlamaz. Bağımsız kod incelemesi, bağımlılık envanteri ve temiz kurulum testi yapılmalıdır. Canlı çalışan demo, temiz kaynak kod kanıtı değildir.
Teknik durum tespiti nasıl yapılır?
İnceleme önce salt okunur veya sınırlı yetkili erişimle başlamalıdır. PHP veya diğer çalışma zamanı sürümü, veritabanı boyutu, disk kullanımı, CPU/RAM ihtiyacı, trafik, hata oranı, yedekleme ve güncelleme düzeni kaydedilmelidir. Panelin satıcının ortak sunucusunda çalışması hâlinde bağımsız taşınabilirlik ayrıca test edilmelidir.
OWASP yaklaşımı doğrultusunda kimlik doğrulama, yetkilendirme, gizli anahtar saklama, güvenlik günlüğü ve güncelleme yönetimi incelenmelidir. Yönetici panelinde iki faktörlü doğrulama var mı? Her kullanıcı yalnız kendi siparişini görebiliyor mu? API anahtarları düz metin mi tutuluyor? Başarısız girişler ve yönetici işlemleri loglanıyor mu? Bunlar satış sonrasında çıkabilecek kritik riskleri gösterir.
Yedekten geri yükleme testi
“Günlük yedek alınıyor” sözü, geri yüklenebilen yedek anlamına gelmez. Ayrı bir ortamda veritabanı ve dosya yedeğinin açıldığı gösterilmelidir. Yedeklerin şifreli saklanması, erişim yetkisi, saklama süresi ve son başarılı geri yükleme tarihi kayıt altına alınmalıdır.
Kurulum ve taşıma provası
Panel yeni sunucuda temiz biçimde kurulabiliyorsa teknik bağımlılıklar daha iyi anlaşılır. DNS değişmeden önce hosts kaydı veya geçici adresle temel işlevler test edilebilir. Giriş, sipariş, bakiye, destek bileti, cron, e-posta ve API durum sorgusu uçtan uca denenmelidir.
API sağlayıcıları ve bakiye nasıl incelenir?
Birçok SMM panel hizmetleri farklı toptan sağlayıcılardan API çeker. Bu bağlantıların satıcıya özel olup olmadığı, alıcıya devredilip devredilemeyeceği ve bakiyenin satış fiyatına dâhil olup olmadığı yazılmalıdır. Sağlayıcı hesabı devredilemiyorsa alıcı kendi hesabını açmalı ve servis eşleştirmelerini yeniden yapmalıdır.
Servis ID’leri, maliyetler, minimum siparişler ve refill koşulları değişebilir. Son 30–90 günlük siparişlerde hangi sağlayıcının ne kadar hata verdiği, partial ve cancel oranları, ortalama tamamlama süresi ve destek performansı karşılaştırılmalıdır. Tek bir güne ait başarılı sipariş ekranı yeterli değildir.
API anahtarları teslim sırasında yenilenmelidir. Eski anahtarlar iptal edilmeli, kaynak kod ve loglardaki kopyalar temizlenmeli, IP sınırlaması varsa güncellenmelidir. Satıcının devir sonrasında erişebildiği gizli anahtar bırakılmamalıdır.
Gelir, gider ve kârlılık nasıl doğrulanır?
Ciro ile kâr aynı değildir. Panel bakiyesine yüklenen para, henüz tamamlanmamış siparişler ve kullanıcıların içeride duran bakiyesi gelir gibi gösterilmemelidir. Dönem bazında tahsilat, sağlayıcı maliyeti, ödeme komisyonu, iade, chargeback, sunucu, yazılım lisansı, destek personeli ve vergi kalemleri ayrı hesaplanmalıdır.
Gelir kanıtı yalnız ekran görüntüsüne dayanmamalıdır. Ödeme kuruluşu raporları, banka hareketleri, fatura kayıtları ve panel veritabanındaki işlemler aynı tarih aralığında mutabık olmalıdır. Kişisel veriler maskelenerek örneklem alınabilir. Anormal sıçramalar, tek müşteriye bağımlılık ve kampanya kaynaklı geçici gelir ayrıca işaretlenmelidir.
Kullanıcı bakiyesi gizli borç olabilir
Müşterilerin paneldeki kullanılmamış bakiyesi, yeni sahibin gelecekte hizmet sağlama yükümlülüğüdür. Toplam bakiye satış fiyatına ek değer gibi değil, karşılığı bulunması gereken yükümlülük gibi ele alınmalıdır. Bekleyen siparişler, açık iadeler ve destek talepleri de devir kapanış listesine yazılmalıdır.
Müşteri verisi ve KVKK açısından nelere dikkat edilmeli?
Veritabanı; ad, e-posta, telefon, IP adresi, sipariş bağlantıları ve ödeme kayıtları gibi kişisel veriler içerebilir. “Panelle birlikte müşteri listesi” ifadesi otomatik olarak serbest aktarım hakkı vermez. Veri sorumlusu değişikliği, aydınlatma, hukuki sebep, saklama süresi ve güvenlik yükümlülükleri değerlendirilmelidir.
Gereksiz ve süresi dolmuş veriler devirden önce temizlenmeli; parolalar güvenli hash biçiminde olmalı; ödeme kartı verileri panel veritabanında tutulmamalıdır. E-posta listelerinin izin durumu ayrıca incelenmelidir. Bu bölüm için somut iş modeline göre KVKK uzmanından görüş almak en sağlıklı yoldur.
Ödeme altyapısı devredilebilir mi?
Sanal POS veya ödeme kuruluşu hesabı çoğunlukla sözleşme yapılan kişi ya da şirkete bağlıdır ve yalnız giriş bilgisi verilerek devredilemez. Alıcının kendi ticari hesabıyla yeni başvuru yapması gerekebilir. Bu süreç tamamlanmadan panelin kesintisiz gelir üretmeye devam edeceği varsayılmamalıdır.
Ödeme sayfasında kart verisinin kim tarafından işlendiği belirlenmelidir. PCI SSC, ödeme tamamen dış hizmet sağlayıcısına verilse bile satıcının uygun entegrasyon ve sağlayıcı yönetimi sorumluluklarının devam edebileceğini belirtir. Kart numarası, CVV veya hassas ödeme verileri kaynak kodda, loglarda ya da yerel veritabanında tutulmamalıdır.
Canlı demo güvenli biçimde nasıl yapılır?
Satıcı, gerçek yönetici parolasını paylaşmak yerine sınırlı yetkili demo hesabı açmalıdır. Demo verileri mümkünse anonimleştirilmeli; müşteri e-postaları, API anahtarları ve ödeme bilgileri gösterilmemelidir. Görüntülü görüşmede ekran paylaşımı kullanılacaksa hassas alanlar kapatılmalıdır.
Alıcı; kullanıcı oluşturma, bakiye hareketi, sipariş durumu, destek bileti ve rapor akışını gözlemlemelidir. Ancak canlı sistemde rastgele sipariş oluşturmak veya müşteri verisini dışarı aktarmak doğru değildir. Test senaryoları önceden kararlaştırılmalı ve işlem kayıtları sonradan temizlenmelidir.
Devir sözleşmesinde hangi başlıklar bulunmalı?
- Tarafların kimliği ve satış bedeli
[/*] - Devredilen ve devredilmeyen varlıkların ayrıntılı listesi
[/*] - Domain, marka, kaynak kod ve lisansın teslim yöntemi
[/*] - API hesapları, bakiye ve üçüncü taraf sözleşmelerinin durumu
[/*] - Müşteri bakiyeleri, bekleyen siparişler, iadeler ve chargeback sorumluluğu
[/*] - Kişisel veri aktarımı ve güvenlik yükümlülükleri
[/*] - Teknik destek, eğitim ve geçiş süresi
[/*] - Teslim kabul testleri ve ödeme takvimi
[/*] - Gizlilik, rekabet ve ihlal iddialarına ilişkin hükümler
[/*] - Uyuşmazlık ve fesih koşulları
[/*]
Sözleşmedeki her teslim maddesi ölçülebilir olmalıdır. “Panel eksiksiz devredilecektir” yerine domain hesabı, belirli commit veya paket, veritabanı yedeği, kurulum dokümanı ve erişim listesinin teslim edildiği yazılabilir. Ödeme, doğrulanmış teslim kilometre taşlarına bağlanmalıdır.
Güvenli devir sırası nasıl olmalı?
Önce varlık envanteri ve kanıtlar incelenir; ardından sözleşme ve kapanış kontrol listesi oluşturulur. Yeni sunucu ile ödeme hesabı hazırlanır. Kaynak kod temiz ortamda kurulur, veritabanı kontrollü biçimde aktarılır ve API bağlantıları alıcının anahtarlarıyla yenilenir.
Domain transferi ya da kayıt sahibi değişikliği doğrulandıktan sonra DNS yeni altyapıya yönlendirilir. E-posta, destek ve sosyal medya hesapları rol bazlı aktarılır. Tüm yönetici parolaları, oturum anahtarları ve kurtarma kodları değiştirilir. Eski erişimler kapatılır; ilk günlerde hata, sipariş ve ödeme günlükleri yakından izlenir.
Teslim kabul kontrolü
Alıcı; giriş, kayıt, ödeme, sipariş, iade, destek, e-posta, cron ve yedek işlevlerini kontrol eder. Domain ve marka varlıkları kendi hesabında görünmelidir. Kullanıcı bakiyesi ve muhasebe açılış rakamları iki tarafça imzalanmalıdır. Eksik kalan maddeler için süre ve sorumlu belirlenmelidir.
WebTicaret’te satılık SMM panel ilanı nasıl hazırlanmalı?
Hazır çalışan panel ve işletme devri ilanları SMM Panel Satışı kategorisinde açılmalıdır. Yalnız lisans, script veya modül satılıyorsa SMM Panel Yazılımı daha doğru alandır. API sağlayıcı teklifleri ise SMM API Hizmetleri altında yer almalıdır.
İlan başlığında panelin durumu ve satış biçimi açık yazılmalı; açıklamada aktif kullanıcı, doğrulanabilir gelir dönemi, yazılım/lisans, domain, sunucu, API, destek ve fiyat kapsamı belirtilmelidir. Müşteri verileri veya yönetici bilgileri herkese açık alanda paylaşılmamalıdır.
Sonuç: Satın alınan şey kod değil, sürdürülebilir bir operasyondur
Satılık SMM panel değerlendirirken arayüz görünümü ve toplam kullanıcı sayısı karar vermek için yeterli değildir. Domain ve marka sahipliği, devredilebilir lisans, temiz kaynak kod, API sürekliliği, gerçek kârlılık, müşteri bakiyeleri, veri koruma, ödeme altyapısı ve destek yükü birlikte incelenmelidir.
Kanıtlanamayan gelir değerleme hesabına katılmamalı; devredilemeyen varlık satış kapsamına yazılmamalıdır. Küçük ayrıntıları kapanıştan önce belgelemek, satış sonrasındaki büyük anlaşmazlıkları önler. Teknik test, hukuki kontrol ve aşamalı ödeme bir araya geldiğinde hem alıcı hem satıcı için daha güvenli ve şeffaf bir devir mümkün olur.