Oyuncu kasada 2 milyon TL işlem yaptı.
CMS bunu gördü.
CRM 15 dakika sonra gördü.
Otel yanlış oyuncu hesabına oda yazdı.
Finans aynı işlemi iki kez aldı.
Bütün sistemler “çalışıyor” olabilir.
Operasyon yine de yanlıştır.
Casino sistemleri entegrasyonu, iki uygulamayı yalnız kabloyla bağlamak değildir. Slot, kasa, otel, CRM ve finans arasında gerçekleşen tek bir iş olayının bütün sistemlerde aynı kimlik, tutar, zaman ve durumla izlenmesini sağlamaktır.
Bu yazıdaki mimari örnekler geneldir. Finansal kayıt, kişisel veri, güvenlik ve oyun sistemi bağlantıları ilgili teknik ve yasal gerekliliklerle doğrulanmalıdır.
Önce iş olayını tanımlayın
Her entegrasyon için “hangi tabloyu kopyalıyoruz?” yerine “hangi olay gerçekleşti?” diye sorun.
Örnek olaylar:
- Oyuncu oluşturuldu/güncellendi
- Slot oturumu başladı/bitti
- Kasa yatırma veya çekme tamamlandı
- Marker açıldı/ödendi
- Comp onaylandı/kullanıldı/iptal edildi
- Otel rezervasyonu kullanıldı/no-show oldu
- Jackpot doğrulandı/ödendi
- Finansal gün kapandı
Olay; benzersiz kimlik, kaynak sistem, zaman damgası, sürüm, tutar/para birimi ve durum taşımalıdır.
Casino sistemleri entegrasyonu için otorite matrisi
| Alan | Otorite | Tüketiciler |
|---|---|---|
| Doğrulanmış oyuncu kimliği | KYC/CRM ana kayıt | CMS, kasa, otel |
| Slot oturumu/meter | Slot sistemi | CMS, BI, finans |
| Kasa işlemi | Cage | CMS, AML, finans |
| Oda kullanımı | PMS | CMS, comp maliyeti, CRM |
| Onaylı yevmiye | ERP/GL | Raporlama |
İki sistem aynı alanın efendisi olursa döngüsel güncelleme ve veri çatışması çıkar.
Kaynak sistemlerin otorite sınırları ve entegrasyon yetenekleri, casino management system seçimi sırasında temel mimari kriterler olarak değerlendirilmelidir.
Tekil oyuncu kimliği
Ad-soyad eşleştirmesi entegrasyon değildir.
Grup çapında kalıcı bir oyuncu kimliği ve sistem bazında çapraz referans gerekir:
Enterprise Player ID ↔︎ CMS ID ↔︎ Kasa ID ↔︎ PMS ID ↔︎ CRM ID
Birleştirme ve ayırma işlemleri loglanmalı, geçmiş işlem zinciri korunmalı ve şüpheli eşleşmeler otomatik birleştirilmemelidir.
Ortak kimlik, veri sözlüğü ve tutarlı tanımlar, veriye dayalı casino yönetiminin güvenilir raporlama temelini oluşturur.
Yönetim hatası: Telefon veya e-posta eşleşti diye iki oyuncu hesabını sessizce birleştirmek.
Gerçek zamanlı mı, batch mi?
Her veri milisaniyelik olmak zorunda değildir.
Gerçek zamanlıya yakın
- Kasa ve kredi durumları
- Self-exclusion/oyuncu koruma kısıtları
- Dolandırıcılık ve güvenlik uyarıları
- Aktif comp bütçesi
- Jackpot olayları
Batch uygun olabilir
- Gün sonu finans yevmiyesi
- Tarihsel segment hesapları
- Arşiv raporları
- Maliyet dağıtımları
Gecikme SLA’sı her akış için yazılmalıdır. “Güncel” ifadesi 5 saniye mi, 15 dakika mı, ertesi gün mü açık olmalıdır.
Mükerrer işlem ve idempotency
Ağ hatasında gönderici aynı olayı yeniden yollar. Alıcı her denemeyi yeni işlem sayarsa finansal kayıt iki katına çıkar.
İşlem Anahtarı = Kaynak Sistem + Benzersiz Olay Kimliği + Olay Sürümü
Alıcı aynı anahtarı tekrar gördüğünde yeni kayıt oluşturmak yerine önceki sonucu döndürmelidir. Düzeltme gerekiyorsa eski olayı silmek yerine yeni sürüm veya ters kayıt üretilmelidir.
Hata kuyruğu ve yeniden deneme
Entegrasyon hatası görünmez olmamalıdır.
- Geçici hata: kontrollü yeniden deneme
- Kalıcı veri hatası: karantina kuyruğu
- Şema uyumsuzluğu: sürüm alarmı
- Yetki hatası: güvenlik olayı
- Zaman aşımı: durum sorgulama, kör tekrar değil
Her olayın kaynak ve hedefte korelasyon kimliği bulunmalıdır. Böylece bir kasa işlemi uçtan uca izlenebilir.
Finansal uzlaştırma
Teknik “başarılı” mesaj finansal doğruluk kanıtı değildir.
Günlük kontrol:
| Akış | Kaynak adet/tutar | Hedef adet/tutar | Fark | En eski açık olay |
|---|---|---|---|---|
| Kasa → Finans | 12.450 / 84 mn | 12.449 / 83,8 mn | 1 / 200 bin | 35 dk |
| PMS → CMS | 620 / 9,2 mn | 618 / 9,0 mn | 2 / 200 bin | 4 sa |
| CMS → CRM | 18.300 olay | 18.300 | 0 | 0 |
Adet, tutar, para birimi ve durum birlikte uzlaştırılmalıdır.
Yetkiler, işlem logları, hata kuyrukları ve günlük uzlaştırmalar casino iç kontrol sistemi içinde açık sorumluluklar ve kontrol kanıtlarıyla tanımlanmalıdır.
Şema ve sürüm yönetimi
Yeni alan eklemek genellikle güvenlidir; alan anlamını değiştirmek değildir.
Entegrasyon sözleşmesi:
- Şema sürümü
- Zorunlu/opsiyonel alan
- Veri tipi ve uzunluk
- Kod listesi
- Saat dilimi
- Para birimi ve yuvarlama
- Geriye dönük uyumluluk
- Kullanımdan kaldırma süresi
içermelidir.
Entegrasyon sağlık paneli
- Başarılı/başarısız olay
- Gecikme yüzdelikleri
- Yeniden deneme sayısı
- Karantina kuyruğu
- Kaynak-hedef uzlaştırma farkı
- Sertifika/token bitişi
- Şema sürümü
- Son başarılı olay zamanı
- Sahip ve çözüm süresi
Başarısız olaylar, gecikmeler ve uzlaştırma farkları, yönetimin aynı gün aksiyon alabilmesi için günlük casino yönetim raporuna istisna ve sorumlu bilgisiyle aktarılmalıdır.
Sonuç: Veri akışı değil, işlem bütünlüğü
Slot, kasa, otel, CRM ve finans birbirine bağlandığında tek amaç daha fazla veri taşımak değildir.
Her iş olayının doğru, tekil, zamanında ve uzlaştırılabilir kalması gerekir.
İyi entegrasyon görünmezdir çünkü çalışır. Mükemmel entegrasyon ise bozulduğunda hangi olayın nerede kaldığını, finansal etkisini ve nasıl geri kazanılacağını açıkça gösterir.