Bahis Sitesi Yazılımı: Modüller, Mimari ve Satın Alma Rehberi

Bahis sitesi yazılımı tek bir uygulama değildir

Bahis sitesi yazılımı dendiğinde çoğu kişinin aklına oyuncunun gördüğü web sitesi gelir. Oysa arayüz, sistemin yalnızca görünen katmanıdır. Player Account Management oyuncu profilini ve durumunu; cüzdan para hareketlerini; sportsbook bahis yaşam döngüsünü; casino aggregator oyun oturumlarını yönetir. Bonus, CRM, affiliate, ödeme, KYC, fraud, müşteri desteği ve raporlama servisleri de aynı oyuncu ve işlem verisi üzerinde çalışır.

Modüllerin tek tedarikçiden gelmesi entegrasyonu kolaylaştırabilir fakat her parçanın aynı kalitede olduğu anlamına gelmez. Farklı sağlayıcılardan best-of-breed ürün seçmek daha güçlü özellikler sunabilir, bunun karşılığında veri modeli, kimlik, yetki ve hata yönetimi karmaşıklaşır. Flexrix mimari çalışmada hangi yeteneğin platform çekirdeğinde kalacağını ve hangi ürünün API ile bağlanacağını operasyonun kontrol ihtiyacına göre belirler.

• PAM ve oyuncu kimliği
• Merkezi cüzdan ve ledger
• Sportsbook/casino ürün katmanı
• Bonus, CRM, ödeme ve raporlama

Cüzdan bakiyeden daha fazlasını tutar

Cüzdan ekranında tek sayı görünse de arka planda gerçek para, bonus, bekleyen çekim, açık bahis ve farklı para birimleri bulunabilir. Her değişiklik silinmeyen bir ledger kaydıyla tutulmalı; mevcut bakiye bu işlemlerin doğrulanabilir sonucu olmalıdır. Bir operatörün manuel olarak bakiyeyi değiştirmesi eski değeri güncellemek yerine sebep, yetki ve onay bilgisi taşıyan yeni finansal olay oluşturmalıdır.

Sportsbook settlement, casino win, ödeme webhook’u veya bonus ödülü aynı anda geldiğinde yarış koşulları ve çift işlem riski doğar. Benzersiz işlem kimliği, idempotency, atomik güncelleme ve doğru kilitleme gerekir. Çoklu para biriminde kur dönüşümü ve yuvarlama politikası baştan tanımlanır. Finans ekibinin sağlayıcı ve PSP raporlarıyla günlük mutabakat yapabilmesi için cüzdan verisi işlem seviyesinde dışa aktarılmalıdır.

• Değiştirilemez işlem defteri
• Gerçek/bonus/bekleyen bakiye ayrımı
• Idempotent ve atomik işlemler
• Para birimi ve yuvarlama kuralları

Backoffice operasyonu hızlandırmalı, risk yaratmamalı

Güçlü oyuncu arayüzü, kötü backoffice operasyonunu telafi edemez. Destek ekibi oyuncu geçmişini, finans ekibi ödeme durumunu, risk ekibi bahis ve cihaz ilişkisini hızlı görmelidir. Her rol yalnızca ihtiyacı olan veriye ve aksiyona erişmeli. Bakiye düzeltme, çekim onayı, bonus tanımlama, limit değişikliği ve hesap açma gibi yüksek riskli işlemler dört göz prensibiyle ikinci onay isteyebilir.

Audit log yalnızca “kullanıcı işlem yaptı” kaydı değildir; önceki ve sonraki değer, zaman, IP, gerekçe ve referans talebi içermelidir. Hassas KYC verileri maskelenmeli ve görüntüleme de loglanmalıdır. Arama ekranı isim dışında oyuncu ID, işlem ID, cihaz, ödeme referansı ve kupon numarasıyla çalışmalı. Flexrix operasyon araçlarında amaç daha fazla buton değil, doğru kişinin sorunu daha az adımla ve denetlenebilir biçimde çözmesidir.

• Rol ve marka bazlı yetki
• Yüksek riskli aksiyonda çift onay
• Ayrıntılı audit log
• Oyuncu/işlem/kupon çapraz araması

Satın alırken demo yerine kabul kriteri kullanın

Satış demosu en iyi hazırlanmış akışı gösterir. Gerçek satın alma testi ise başarısız ödeme, gecikmiş settlement, yoğun maç trafiği, çoklu hesap ve destek eskalasyonu gibi zor senaryolardan oluşmalıdır. Her gereksinime ölçülebilir kabul kriteri yazılır: örneğin belirli trafik altında cüzdan gecikmesi, raporun oluşma süresi, kritik olay müdahale süresi veya yeni marka açma yeteneği. “Yüksek performanslı” ve “tam özelleştirilebilir” gibi ifadeler tek başına test edilemez.

Sözleşmede SLA, bakım penceresi, veri dışa aktarımı, API sürüm politikası, güvenlik olayı bildirimi, yedekleme, felaket kurtarma ve fesih desteği bulunmalı. Oyuncu ve işlem verisinin sahibi, ham veriye erişim ve sağlayıcı değişiminde taşınacak kayıtlar açıkça yazılır. Özel geliştirme taleplerinin fiyatlama ve öncelik süreci de önemlidir. İlk yıl ucuz olan yazılım, her küçük değişiklikte ayrı ücret istiyorsa büyüdükçe pahalılaşır.

• Gerçek kullanım kabul senaryoları
• Ölçülebilir performans ve SLA
• Ham veri/API erişimi
• Fesih ve veri taşıma desteği

Mimari büyüme ve regülasyon değişikliğine dayanmalı

İlk gün tek marka ve tek para birimiyle çalışan platform gelecekte farklı ülke, domain, lisans ve ödeme yapısını desteklemek zorunda kalabilir. Çoklu marka kurgusunda oyuncu hesabı, limit, bonus, içerik ve raporlama verisinin markalar arasında nasıl ayrıldığı önemlidir. Regülatör yeni rapor veya oyuncu koruma kuralı istediğinde bütün sistemi yeniden yazmak yerine ilgili modülün değiştirilebilmesi gerekir.

Modülerlik yalnızca mikroservis kullanmak değildir. Servis sınırları, olay sahipliği, versiyonlama ve başarısızlık davranışı anlaşılır olmalı. Merkezi log, metrik, tracing ve alarm olmadan dağıtık mimari sorun çözmeyi zorlaştırır. Güvenlik testleri, erişim anahtarı yönetimi, yedekleme ve kurtarma tatbikatları düzenli yürütülür. Kapasite planı normal gün ortalamasına göre değil büyük spor karşılaşmaları, bonus kampanyaları ve popüler oyun lansmanlarında oluşacak zirve trafiğe göre hazırlanır. Kritik üçüncü taraf servis devre dışı kaldığında bütün sitenin çökmesi yerine kontrollü olarak yalnızca ilgili ürünün kapanması hedeflenir. Teknik ekip ayrıca staging ve üretim ortamları arasındaki konfigürasyon farklarını, gizli anahtar rotasyonunu ve geri alma planını düzenli olarak test etmelidir. Her kritik modülün iş sahibi, teknik sahibi ve kesinti anındaki karar yetkilisi canlıya geçmeden isim bazında belirlenmelidir. Flexrix; hazır ürün, API entegrasyonu ve özel geliştirmeyi aynı büyüme planına bağlayarak operatörün ihtiyaç duymadığı teknik karmaşıklığı satın almamasını hedefler.

• Çoklu marka/pazar/para birimi
• Modül ve olay sahipliği
• Log, metrik, tracing ve alarm
• Yedekleme ve kurtarma testleri

90 günlük uygulanabilir yol haritası

İlk 30 günde pazar araştırması, hukuk görüşü, kapsam belgesi, finansal model ve sağlayıcı kısa listesi tamamlanır. 31–60. günler entegrasyon, tasarım, ödeme, içerik ve uyum politikalarına ayrılır. 61–90. günlerde uçtan uca kabul testleri, güvenlik kontrolleri, ekip eğitimi ve sınırlı soft launch yürütülür. Her fazın çıkış kriteri yazılı olmalı; lisans veya ödeme onayı gecikirse pazarlama bütçesi otomatik olarak ertelenmelidir.

Canlıya geçiş bir bitiş değil ölçüm döneminin başlangıcıdır. İlk haftalarda hata oranı, para yatırma başarısı, çekim süresi, KYC tamamlanma oranı, destek talepleri, bonus maliyeti ve net gelir günlük izlenir. Haftalık ürün toplantısı oyuncu geri bildirimi ile teknik olayları aynı öncelik listesinde birleştirir. Bu disiplin, hızlı büyürken uyum ve oyuncu güvenini korur.