Bahis Yazılımı Rehberi: Modüller, Mimari ve Tedarikçi Seçimi

Bahis yazılımı tek parça bir uygulama değildir

“Bahis yazılımı” denince çoğu insan oyuncunun karşısına çıkan web sitesini düşünür. Oysa arayüz, sistemin sadece görünen yüzüdür. Player Account Management oyuncu profilini ve durumunu, cüzdan para hareketlerini, sportsbook bahsin yaşam döngüsünü, casino aggregator ise oyun oturumlarını yönetir. Bonus, CRM, affiliate, ödeme, KYC, fraud, müşteri desteği ve raporlama katmanları da aynı oyuncu ve işlem verisini kullanır.

Bütün modüllerin tek tedarikçiden gelmesi entegrasyonu kolaylaştırır, ama her bileşenin aynı seviyede olacağını garanti etmez. Farklı firmalardan en iyi ürünleri seçmek daha güçlü özellikler getirebilir; buna karşılık veri modeli, kimlik, yetkilendirme ve hata yönetimi karmaşıklaşır. Spinolf mimari çalışmada, hangi yeteneğin platform çekirdeğinde duracağına ve hangisinin API ile bağlanacağına operasyonun kontrol ihtiyacına bakarak karar verir.

• Oyuncu hesabı ve kimlik yönetimi (PAM)
• Merkezi cüzdan ve muhasebe defteri
• Sportsbook ile casino ürün katmanı
• Bonus, CRM, ödeme ve raporlama bileşenleri

Cüzdan, bakiye göstergesinden fazlasıdır

Ekranda tek bir tutar görünse de arka planda gerçek para, bonus, bekleyen çekim, açık bahisler ve farklı para birimleri yer alabilir. Her değişiklik silinemeyen bir ledger satırı olarak kaydedilmeli; güncel bakiye bu hareketlerin doğrulanabilir toplamı olmalıdır. Bir operatör bakiyeyi elle düzelteceği zaman eski rakamın üzerine yazmamalı; gerekçe, yetki ve onay bilgisi taşıyan yeni bir finansal olay açmalıdır.

Sportsbook settlement’ı, casino kazancı, ödeme webhook’u ya da bonus ödülü aynı anda ulaştığında yarış durumu ve mükerrer işlem riski ortaya çıkar. Çözüm; benzersiz işlem kimliği, idempotency, atomik güncelleme ve doğru kilitleme mekanizmasıdır. Çok para birimli yapılarda kur dönüşümü ve yuvarlama politikası en başta kararlaştırılır. Finans ekibinin sağlayıcı ve PSP raporlarıyla her gün mutabakat yapabilmesi için cüzdan verisi işlem düzeyinde dışarı alınabilmelidir.

• Geri alınamayan işlem defteri
• Gerçek, bonus ve bekleyen bakiyenin ayrı tutulması
• Tekrarlanmaya dayanıklı, atomik işlem akışı
• Kur ve yuvarlama politikası

Backoffice işleri hızlandırmalı, risk üretmemeli

Etkileyici bir oyuncu arayüzü, zayıf bir backoffice’i telafi edemez. Destek ekibi oyuncunun geçmişini, finans ekibi ödemenin durumunu, risk ekibi de bahis ve cihaz bağlantılarını hızla görebilmelidir. Her rol, yalnızca işi için gerekli veriye ve işleme erişmelidir. Bakiye düzeltme, çekim onayı, bonus tanımlama, limit değişikliği ve hesap açma gibi riskli eylemler dört göz ilkesiyle ikinci bir onaya bağlanabilir.

Denetim kaydı, “kullanıcı bir işlem yaptı” notundan ibaret olmamalıdır; önceki ve sonraki değer, zaman, IP adresi, gerekçe ve ilgili talep numarasını da içermelidir. Hassas KYC verileri maskelenmeli, bu verilerin görüntülenmesi de kayda geçmelidir. Arama ekranı yalnızca isimle değil; oyuncu ID, işlem ID, cihaz, ödeme referansı ve kupon numarasıyla da çalışmalıdır. Spinolf’in operasyon araçlarındaki amaç daha çok buton eklemek değil, doğru kişinin sorunu daha az adımda ve izlenebilir şekilde çözmesidir.

• Rol ve marka düzeyinde erişim yetkisi
• Riskli işlemlerde ikinci onay
• Ayrıntılı denetim izi
• Oyuncu, işlem ve kupon üzerinden çapraz sorgu

Satın almada demo yerine kabul ölçütü kullanın

Satış demosu, en iyi hazırlanmış akışı gösterir. Gerçek değerlendirme ise başarısız ödeme, geciken settlement, yoğun maç trafiği, çoklu hesap ve destek yükseltmesi gibi zorlu durumlarla yapılmalıdır. Her gereksinim ölçülebilir bir kabul koşuluna bağlanır; örneğin belirli bir yük altında cüzdan gecikmesi, raporun hazırlanma süresi, kritik olaya müdahale süresi ya da yeni marka açabilme yeteneği. “Yüksek performanslı” veya “tamamen özelleştirilebilir” gibi ifadeler tek başına sınanamaz.

Sözleşmede SLA, bakım penceresi, veri çıkarma hakkı, API sürüm politikası, güvenlik olayı bildirimi, yedekleme, felaket kurtarma ve fesih desteği yer almalıdır. Oyuncu ve işlem verisinin kime ait olduğu, ham veriye erişim ve sağlayıcı değişiminde taşınacak kayıtlar açıkça belirtilir. Özel geliştirme taleplerinin fiyatlandırma ve önceliklendirme düzeni de önemlidir. İlk yıl ucuz görünen bir yazılım, her küçük değişiklik için ayrı ücret alıyorsa büyüdükçe pahalıya gelir.

• Gerçek kullanım koşullarında kabul senaryoları
• Sayısal performans hedefi ve SLA
• Ham veriye ve API’ye erişim
• Sözleşme sonunda veri taşıma ve geçiş desteği

Mimari, büyümeye ve mevzuat değişimine hazır olmalı

İlk gün tek marka ve tek para birimiyle çalışan bir platform, ilerleyen dönemde farklı ülke, alan adı, lisans ve ödeme yapılarını desteklemek zorunda kalabilir. Çok markalı kurguda oyuncu hesabı, limit, bonus, içerik ve raporlama verisinin markalar arasında nasıl ayrıştırıldığı belirleyicidir. Düzenleyici yeni bir rapor ya da oyuncu koruma kuralı getirdiğinde bütün sistemi baştan yazmak yerine yalnızca ilgili modülü değiştirebilmek gerekir.

Modülerlik, mikroservis kullanmaya indirgenemez. Servis sınırları, olayların sahipliği, sürümleme ve hata anındaki davranış açıkça tanımlanmalıdır. Merkezi log, metrik, tracing ve alarm olmadan dağıtık mimaride sorun çözmek zorlaşır. Güvenlik testleri, erişim anahtarı yönetimi, yedekleme ve kurtarma tatbikatları düzenli olarak yapılır. Kapasite planı sıradan bir günün ortalamasına göre değil, büyük spor karşılaşmalarında, bonus kampanyalarında ve popüler oyun çıkışlarında görülen zirve trafiğe göre hazırlanır. Kritik bir üçüncü taraf servisi çöktüğünde bütün sitenin düşmesi yerine yalnızca ilgili ürünün kontrollü biçimde kapatılması amaçlanır. Teknik ekip ayrıca staging ile üretim arasındaki yapılandırma farklarını, gizli anahtar rotasyonunu ve geri dönüş planını sürekli denemelidir. Her kritik modülün iş sahibi, teknik sorumlusu ve kesinti anında karar verecek kişi yayına çıkmadan isimleriyle belirlenmelidir. Spinolf; hazır ürünü, API entegrasyonunu ve özel geliştirmeyi aynı büyüme planında birleştirerek operatörün ihtiyaç duymadığı teknik karmaşıklığı satın almasını önlemeyi hedefler.

• Çok marka, pazar ve para birimi desteği
• Modül ve olay sorumluluğu
• Log, metrik, izleme ve alarm altyapısı
• Yedekten dönüş ve felaket kurtarma denemeleri

Uygulamaya dönük 90 günlük plan

İlk ay pazar araştırmasına, hukuki görüşe, kapsam dokümanına, finansal modele ve sağlayıcı kısa listesine ayrılır. Sonraki otuz gün entegrasyon, tasarım, ödeme, içerik ve uyum politikalarıyla geçer. Son otuz günde uçtan uca kabul testleri, güvenlik denetimi, ekip eğitimi ve sınırlı bir soft launch gerçekleştirilir. Her aşamanın çıkış koşulu yazılı olmalı; lisans ya da ödeme onayı gecikirse pazarlama harcaması kendiliğinden ertelenmelidir.

Yayına almak bir varış noktası değil, ölçüm evresinin başlangıcıdır. İlk haftalarda hata oranı, para yatırma başarısı, çekim süresi, KYC tamamlanma oranı, destek talepleri, bonus gideri ve net gelir her gün gözden geçirilir. Haftalık ürün toplantısında oyuncu geri bildirimleri ile teknik olaylar aynı öncelik listesinde yer alır. Böyle bir düzen, hızlı büyürken uyumu ve oyuncu güvenini korumanıza yardımcı olur.