Kendi Casino Backend'iniz İçin Oyun Sağlayıcı Agregasyon Katmanı: Oturumlar, Bakiye Callback'leri ve Tur Geçmişi

Kendi casino backend'ini kuran ve birçok sağlayıcıdan slot, canlı krupiyeli oyun ve masa oyunu bağlayan bir operatör, sonunda sağlayıcı sayısı kadar entegrasyon sözleşmesiyle kalır: farklı başlatma akışları, farklı cüzdan çağrıları, turun ne olduğuna dair farklı fikirler. Agregasyon katmanı bunları tek bir iç sözleşmeye dönüştürür; böylece cüzdan, lobi, bonuslar, limitler ve raporlama bir kez yazılır ve her sağlayıcı bunlara uyarlanır.

Aşağıda bu katmanın genellikle nasıl bölündüğü anlatılıyor: sağlayıcıda ne kaldığı, oturumların nasıl verildiği, bakiye callback'lerinin yeniden denemelerden ve rollback'lerden nasıl sağ çıktığı, oturumdan sonra kapanan turların nasıl kaydedildiği ve sonucun sağlayıcının kendi rakamlarıyla nasıl mutabakata getirildiği.

Katmanın sahip oldukları ve sağlayıcıda kalanlar

Oyunu sağlayıcı işletir: rastgele sayı üretimi, oyun matematiği, oyun istemcisi ve bunun bir test laboratuvarı tarafından sertifikalandırılması. Oyuncuya ve paraya dokunan her şey operatörde kalır: kimlik, bakiye, limitler, bonuslar, lobi ve bir düzenleyicinin ya da bir oyuncu uyuşmazlığının isteyebileceği kayıtlar. Agregasyon katmanı ikisinin arasında durur ve her sağlayıcının API'siyle konuşan tek sunucu tarafı kod o olmalıdır.

• Başlatma: tek bir oyuncu, oyun, para birimi, dil ve cihaz için bir oyun URL'si ya da token ve cüzdana hiç ulaşmayan bir demo modu
• Cüzdan: her sağlayıcıdan gelen ve tek bir iç defter üzerinden yanıtlanan bakiye, debit, credit ve rollback çağrıları
• Turlar: birden fazla bahis içeren ve geç biten turlar dahil, her sağlayıcının tur ID'si ve durumu
• Katalog: tek bir lobiye eşlenen ve her oyunun nerede sunulabileceğine göre filtrelenen sağlayıcı oyun ID'leri, kategoriler ve desteklenen cihazlar
• Bonuslar: sağlayıcının kendi bonus arayüzü varsa onun üzerinden verilen ve kazançları bonus parası olarak kaydedilen ücretsiz turlar
• Raporlama: sağlayıcının faturalamada esas aldığı biçimde sağlayıcı bazında toplamlar

Seamless wallet ya da transfer wallet

Sağlayıcılar bir operatörün parasına iki yoldan biriyle bağlanır. Seamless wallet'ta bakiye operatörde kalır ve sağlayıcı her bahis ve kazanç için operatörün cüzdanını çağırır. Transfer wallet'ta operatör, oyundan önce parayı sağlayıcı tarafında tutulan bir bakiyeye aktarır ve ancak kendisi talep ettiğinde geri aktarır.

• Seamless, tüm oyunlarda tek bir bakiye tutar; böylece limitler, bonuslar ve oyuncunun parasına dair gördükleri tutarlı kalır; ayrıca operatörün cüzdan latency'sini ve erişilebilirliğini her spinin içine yerleştirir
• Transfer, oyunu operatörün cüzdanından yalıtır ve bakiyeyi böler: bir sağlayıcı oturumunda duran para başka hiçbir yerde kullanılamaz ve içeri ya da dışarı yapılan her transfer, mutabakata getirilecek bir kayıt daha demektir
• İkisini de destekleyen bir katmanın yine de tek bir iç defteri vardır; transfer adaptörü bir oturumun başlangıcını ve sonunu bir debit'e ve bir credit'e dönüştürür

Bu yazının geri kalanı seamless wallet'ı varsayar, çünkü orada her bahis ve kazanç bir cüzdan çağrısıdır.

Oturumlar: token'ı operatör verir

Oyun başlatma operatör tarafında başlar. Backend, bu oyuncunun bu oyunu şu anda oynayabileceğini kontrol eder; bu kontrol hesap durumunu, kendini dışlamayı, limitleri ve oyunun oyuncunun yargı bölgesinde sunulup sunulamayacağını kapsar. Ardından oyuncuya, oyuna ve para birimine bağlı bir oturum oluşturur ve başlatma sırasında sağlayıcıya opak bir token iletir. Sağlayıcının sunucusu callback yaptığında, çağrının kimin bakiyesiyle ilgili olduğunu bu token belirler.

• Token bir oyuncuyu sonsuza dek değil, bir oturumu tanımlar: süresi dolar ve oyuncu oyun sırasında kendini dışladığında ya da bir limite ulaştığında operatör onu geçersiz kılabilir
• Yeni bahisler geçerli bir oturum gerektirir; zaten kabul edilmiş bir bahsin kazancı, bu arada oturum sona ermiş olsa bile credit edilmelidir
• Bir oyuncu aynı anda birden fazla oyun oturumuna sahip olabilir; bu yüzden bakiye değişiklikleri oturum başına değil, hesap başına sıraya sokulur
• Para birimi oturum boyunca sabittir; para birimini değiştiren bir oyuncu yeni bir oturum başlatır
• Demo oyun, cüzdanın doğrudan reddettiği bir token alır; böylece yanlış yönlendirilmiş bir çağrı asla gerçek paraya dokunamaz

Yayımlanmış operatör dokümanları bunu açıkça söyler. Hub88'in cüzdan API'si, kazançlar ve rollback'ler bahis oynandıktan sonra gelebileceği için bunlarda token geçerliliğinin doğrulanmaması gerektiğini söyler. VeliGames, oturumun süresi dolmuş olsa bile operatörün bir turdaki kazancı reddedemeyeceğini söyler.

Bakiye callback'leri: her çağrı iki kez gelebilir

İki sunucu arasındaki her çağrı, karşı taraftaki iş tamamlandıktan sonra zaman aşımına uğrayabilir. Sağlayıcı, başarısız olan bir debit'i yanıtı kaybolan bir debit'ten ayırt edemez; bu yüzden çağrıyı tekrarlar ya da transaction'ı iptal eder. Cüzdanın işi, bunların ikisini de güvenli hâle getirmektir.

Yayımlanmış entegrasyon dokümanları, tekrarların ne kadar ısrarlı olduğunu gösterir. Hub88'in operatör cüzdan API'si, HTTP 200 almadığında bir bahsi başarısız sayar, bir rollback oluşturur ve bu rollback'i üstel back-off ile 500 kereye kadar yeniden dener. Gamomat, başarısız bir isteği 500 ms arayla iki kez yeniden dener, ardından bir rollback başlatır ve onu bir saniyeden 30 dakikaya kadar uzayan aralıklarla yeniden dener. Tom Horn Gaming'in cüzdan zaman aşımı 10 saniyedir; bu sürenin ardından otomatik olarak bir rollback gönderilir. Birkaç dakika boyunca çalışmayan bir cüzdan, geri geldiğinde sessizlikle değil, tekrarlardan ve rollback'lerden oluşan bir kuyrukla karşılaşır.

• Idempotency anahtarı, sağlayıcıya ve çağrı türüne göre kapsamlanmış olan sağlayıcının transaction ID'sidir; çünkü iki sağlayıcı aynı ID'yi verebilir ve bazıları rollback'i bahsin ID'siyle gönderir; bu anahtar üzerindeki bir benzersizlik kısıtı, tekrarlanan bir çağrıyı bir aramaya dönüştürür
• Tekrarlanan bir debit parayı asla ikinci kez hareket ettirmez ve farklı bir tutar ya da turla gelen aynı ID yeni bir bahis değil, bir hatadır
• Bir debit, hesap satırını kilitler, bakiyeyi ve limitleri kontrol eder ve defter kaydını tek bir kısa transaction'da yazar; böylece aynı hesaptaki iki eşzamanlı spin aynı parayı ikisi birden harcayamaz
• Bir rollback iptal ettiği transaction'ı belirtir: uygulanmış bir debit bir kez geri alınır ve zaten işlenmiş bir rollback saklanan sonucunu döndürür
• Cüzdanın hiç almadığı bir transaction için gelen rollback kaydedilir ve sağlayıcının dokümante ettiği kodla yanıtlanır; böylece sonradan gelen gecikmiş orijinal transaction, oyuncudan sağlayıcının zaten iptal ettiği bir bahsin parasını almak yerine reddedilir
• Hatalar her sağlayıcının kendi kodlarına eşlenir; çünkü sağlayıcılar yetersiz bakiyeye, süresi dolmuş bir oturuma ve genel bir hataya farklı tepki verir: kimi oyunu durdurur, kimi yeniden dener, kimi iptal eder

Bir tekrara beklenen yanıt da standart değildir. Hub88, aynı transaction ID'sine sahip isteklerin iki kez işlenmemesini ve tüm mükerrerler için yanıtın aynı olmasını şart koşar; VeliGames, HTTP status 409 ve DUPLICATE_TRANSACTION içeren bir hata ister; Tom Horn Gaming'in mükerrer bir referans için ayrı bir sonuç kodu vardır. Adaptör her sağlayıcıya kendi biçiminde yanıt verir, alttaki defter ise aynı kalır.

Sağlayıcılar bu kuralı kendi dokümanlarında belirtir. St8'in operatör API'si, operatör daha önce işlemediği bir iptal için bir transaction ID'si aldığında, bu ID'nin sonradan işlenmesini önlemek için kaydedilmesi gerektiğini söyler. Tom Horn Gaming, cüzdan bir rollback'in işaret ettiği çekim (withdrawal) işlemini hiç işlemediğinde kendi bilinmeyen transaction sonuç kodunu bekler.

Turlar kendi takvimlerine göre kapanır

Tur, sağlayıcının oyun birimidir ve nadiren tek bir transaction'a karşılık gelir. Bir slot spini çoğu zaman bir debit ve bir credit'tir, bazen tek bir çağrı olarak gönderilir. Blackjack, split ya da double için debit'ler ekleyebilir. Canlı rulet, bir bahis penceresi boyunca birçok oyuncudan bahis alır ve sonuç belli olduğunda hepsini sonuçlandırır. Ücretsiz turlar, bir bütün oluşturan bir dizi kazanç üretebilir.

• Sağlayıcının tur ID'sini her defter kaydıyla birlikte saklayın ve turun durumunu ayrıca tutun: açık, kapalı ya da iptal edilmiş
• Turu sağlayıcının kendi sinyaliyle kapatın - API'de varsa açık bir tur sonu çağrısı ya da bir final bayrağıyla - yoksa sağlayıcı başına dokümante edilmiş bir kurala göre
• Turların oturumlardan uzun yaşamasına izin verin: turun ortasında bağlantısı kopan bir oyuncu yine de o turun sonucunu alır - çoğu zaman oturum token'ının süresi dolduktan çok sonra
• Açık turları sağlayıcı başına yaşa göre izleyin; eski açık turların sayısındaki artış, bozuk bir entegrasyonu bir oyuncu şikâyet etmeden çok önce gösterir

Oyuncu uyuşmazlıkları tur geçmişiyle çözülür. Her defter kaydını sağlayıcı, oyun, tur, tutarlar, önceki ve sonraki bakiye ve biri sağlayıcının, biri cüzdanın olmak üzere iki zaman damgasıyla birlikte tutun; API'si sunuyorsa sağlayıcının kendi tur ayrıntılarına bağlantı verin. Böylece tek bir spindeki parayla ilgili bir soru kayıtlardan yanıtlanır.

Bu geçmişin kapsaması gereken asgari düzeyi düzenleyiciler belirler. Gaming Laboratories International'ın interaktif oyun sistemleri standardı olan GLI-19, oyuncu için yeniden canlandırma ya da açıklama biçiminde bir oyun geri çağırma (game recall) özelliğini şart koşar. Birleşik Krallık Şans Oyunları Komisyonu'nun (UK Gambling Commission) uzaktan teknik standartları, lisans sahibiyle iletişime geçmeye gerek kalmadan en az üç aylık, talep üzerine ise en az 12 aylık hesap ve oyun geçmişini şart koşar. Malta Oyun Otoritesi'nin (Malta Gaming Authority) oyuncu koruma direktifi, oyuncuya hemen önceki altı aylık oyun geçmişine erişim sağlar.

Canlı krupiye, cüzdanı ani yüke dönüştürür

Slotlar yükü zamana yayar, çünkü her oyuncu kendi temposunda spin yapar. Canlı krupiyeli masalar ise oyuncuları senkronize eder: masadaki herkesin bahisleri, bahisler kapanmadan önceki saniyelerde gelir ve sonuç belli olduğunda herkesin kazançları birlikte gelir. Popüler bir masa bunu bahis yapan her oyuncu için tekrarlar.

• Her cüzdan transaction'ını kısa ve tek bir hesapla sınırlı tutun; böylece bir masanın ani yükü yalnızca o masadaki hesapları sıraya sokar
• Callback'i yanıtlayın, gerisini sonra yapın: bonus çevrimi, sadakat puanları ve analitik, defter olayını çağrının içinde değil, commit'ten sonra okur
• Diğer oyunlar bahis göndermeye devam ederken, beklenen en yoğun masaya göre boyutlandırılmış sonuç ani yükünün kendisini yük testinden geçirin

Tek iç sözleşme, çok sayıda adaptör

Sağlayıcı farklılıklarının yaşadığı yer adaptörlerdir ve yaşadıkları tek yer de onlar olmalıdır. Her adaptör şunları üstlenir:

• Gelen callback'lerin sağlayıcının belirttiği şekilde kimlik doğrulaması; örneğin istek imzaları ya da izin verilen kaynak adresleri
• Tutar biçimleri: bazı API'lerde sabit ölçekli tam sayılar, bazılarında ondalıklı değerler ve bir sağlayıcının desteklediği para birimleri
• Alanların ve hata kodlarının iç sözleşmeye eşlenmesi
• Oyun kataloğunun ve başlatma parametrelerinin içe aktarılması
• Sağlayıcının bonus arayüzü üzerinden ücretsiz turlar
• Sağlayıcının entegrasyon senaryoları; sonrasında her sürümden önce çalışan regresyon testleri olarak saklanır

İç sözleşme küçük kalır: oturum açma, bakiyeyi okuma, debit, credit, tek çağrıda debit ve credit, bahis olmadan ödeme, rollback, tur kapatma ve cüzdanın döndürebileceği sabit bir hata kümesi. Böylece yeni bir sağlayıcı bir adaptör ve bir test paketi demektir, cüzdanda bir değişiklik ise nadiren.

Mutabakat: sağlayıcının raporu ikinci bir defterdir

Her sağlayıcı her turun kendi kaydını tutar ve operatöre bu kayda göre fatura keser. Agregasyon katmanının defteri, aynı paranın operatör tarafıdır. İkisini her gün, her sağlayıcının gün sınırına ve saat dilimine göre, sağlayıcı, para birimi ve oyun başına mutabakata getirin:

• Önce toplamlar: günün bahisleri, kazançları ve aralarındaki fark
• Sonra transaction'lar: yalnızca bir tarafta bulunan kayıtlar ve farklı tutarlar
• Her farkı tur geçmişiyle çözün ve farkların sayısını sessizce düzeltilen bir iş olarak değil, sıfıra yakın kalması gereken bir rakam olarak takip edin

Bu kanıtın ne kadar süre saklanması gerektiği entegrasyonun bir parçasıdır. Hub88, mutabakat amacıyla her transaction ID'sinin iki tarafta da en az dört ay saklanmasını ister; Gamomat'ın operatör API'si ise bir tarih aralığı ya da tek bir tur için mutabakat verisi döndürür.

İlk sağlayıcı canlıya çıkmadan önce ne ölçülmeli

• Sağlayıcı ve çağrı türü başına callback latency'si, ortalama yerine p99'da
• Tekrarlanan çağrılar ve farklı bir payload ile gelen tekrarlanan ID'ler
• Rollback'ler ve cüzdanın hiç almadığı transaction'lar için gelen rollback'ler
• Yaşa göre açık turlar
• Nedene göre reddedilen debit'ler: bakiye, limitler, oturum ya da hata
• Sağlayıcı başına günlük mutabakat farkları

Operatörler için oyun sağlayıcı agregasyon katmanlarını hangi şirketler kuruyor?

Bu sorunun üç tür yanıtı vardır ve her biri farklı bir şey satar. Agregatörler ve platform tedarikçileri operatöre kendi katmanlarını kiralar: tek sözleşme, çok sayıda sağlayıcı, onların ticari koşulları. Anahtar teslim ve white-label platformlar katmanı, tedarikçinin sahip olduğu bir platformun içinde sunar. Mühendislik firmaları katmanı operatörün backend'inin içinde kurar ve operatör sağlayıcı sözleşmelerini kendisi imzalar.

Hangi türle görüşürseniz görüşün, bir ekibin bunu daha önce kurup kurmadığını şu sorular gösterir:

• Cüzdan, hiç almadığı bir transaction için gelen bir rollback ile ne yapıyor?
• İki sağlayıcıdan gelen transaction ID'lerinin çakışması nasıl önleniyor?
• Oturumundan sonra kapanan bir tur nasıl kaydediliyor ve oyuncuya nasıl gösteriliyor?
• Hangi sağlayıcıları seamless wallet üzerinden, hangilerini transferlerle entegre ettiler?
• Sağlayıcı raporlarıyla nasıl mutabakat yapıyorlar ve normal bir günlük fark neye benziyor?
• İş bittiğinde adaptör kodunun ve iç sözleşmenin sahibi kim olur ve hangi parçalar tedarikçinin yeniden kullanılabilir bileşenleri olarak kalır?

İlk ikisinde genel kalan bir yanıt, uç durumların üretimde bulunacağı anlamına gelir.

amBrain, casino operatörleri için oyun sağlayıcılarını entegre ediyor mu?

amBrain; trading platformları, matching engine'ler, real-time bidding sistemleri ve casino platformu mühendisliği alanlarında uzmanlaşmış bir yazılım geliştirme şirketidir. amBrain 2019'dan bu yana yazılım geliştiriyor.

iGaming'de amBrain'in ölçüme dayalı olarak yayımladığı rakamlar 500+ üçüncü taraf sağlayıcı entegrasyonu ve canlıda 12 operatördür.

amBrain üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Müşteri, amBrain'in yeniden kullanılabilir bileşenleri dışında ürünün ve kodun tam mülkiyetini elinde tutar.

Bu yazı bir agregasyon katmanının nasıl çalıştığını anlatır; bir vaka çalışması değildir ve hiçbir müşterinin adını vermez.

Yani ilk karar hangi sağlayıcılarla sözleşme imzalanacağı değildir. Karar, her sağlayıcının uyarlanacağı ve ilk adaptör var olmadan önce hata durumlarıyla birlikte yazıya dökülmüş iç sözleşmedir.