Seamless Wallet ve Transfer Wallet Arasındaki Fark

İki model, iki farklı sorumluluk dağılımı

Transfer wallet modelinde oyuncu, oyun oynamak için bakiyesini operatör cüzdanından sağlayıcı cüzdanına taşır; oyun bittiğinde geri çeker. Seamless modelde ise tek bir cüzdan vardır, operatörün cüzdanı, ve her bahis ile her kazanç o cüzdana anlık olarak API çağrısıyla yazılır. Fark teknik bir detay gibi görünür ama oyuncu deneyimini, destek yükünü ve mutabakatı doğrudan belirler.

Seamless modelde oyuncu hiçbir zaman "oyun bakiyesi" diye ikinci bir bakiye görmez; sportsbook, slot ve canlı casino aynı parayı paylaşır. Bedeli şudur: bahis anında sizin cüzdan servisiniz yanıt vermek zorundadır. Transfer modelinde operatör servisi bir süre düşse oyun devam eder, ama oyuncu iki bakiye arasında para taşımak zorunda kalır ve "param nerede" destek talepleri başlar.

• Oyuncunun kaç bakiye gördüğü
• Oyun sırasında hangi servisin kritik yolda olduğu
• Ürünler arası tek bakiye ihtiyacı
• Destek tarafında beklenen talep tipi

Seamless entegrasyonun gerçek gereksinimi: dayanıklılık

Seamless cüzdan uçlarınız oyunun her spin'inde çağrılır. Bu yüzden ölçüt ortalama yanıt süresi değil, en kötü yüzdelik dilimdir. Pratikte hedef, bahis ve kazanç uçlarında p99 yanıt süresini düşük onlu milisaniyelerde tutmak ve zaman aşımı durumunda ne olacağını önceden yazmaktır. Sağlayıcı zaman aşımında genellikle isteği tekrarlar; aynı işlem iki kez işlenirse oyuncuya iki kez para yazılır.

Bunun tek çözümü idempotency. Her işlem sağlayıcının verdiği benzersiz kimlikle saklanır ve aynı kimlik ikinci kez geldiğinde yeni bir kayıt açılmaz, ilk sonucun aynısı döner. Buna bir de "rollback" ucu eklenir: sağlayıcı bir bahsi iptal ettiğinde para geri yazılır, ama aynı rollback iki kez geldiğinde ikinci kez yazılmaz. Bu üç davranış (yaz, tekrar isteğe aynı cevabı ver, iptali bir kez uygula) entegrasyonun tamamını belirler.

• Bahis ve kazanç uçlarında p99 yanıt süresi hedefi
• İşlem kimliğine dayalı idempotency kaydı
• Rollback ve çift rollback davranışı
• Zaman aşımında sağlayıcının tekrar politikası

Takılı oyunlar ve terk edilmiş turlar

Her iki modelde de aynı sorun ortaya çıkar: oyuncu bir freespin turunun ya da bonus özelliğinin ortasında bağlantıyı kaybeder. Oyun tarafında tur açık kalır, kazanç "pending" durumda bekler. Bu kayıtlar kendiliğinden kapanmazsa oyuncu parasını hiç görmez ve destek tarafında elle kapatma biriktirir. Entegrasyonun kabul testine "yarım kalan tur" senaryosu mutlaka girmeli.

Doğru çözüm, açık turları tarayan ve sağlayıcının tur durumu ucuna sorarak sonucu kesinleştiren bir süpürücü iştir. Süpürücünün iki kuralı olmalı: yalnızca sağlayıcının kesinleştirdiği sonucu yazmak ve aynı turu asla iki kez ödememek. Bu iş olmadan geçen her ay, ay sonunda elle düzeltilen bir kuyruk bırakır.

• Açık tur tarama işinin varlığı ve sıklığı
• Sağlayıcının tur durumu sorgulama ucu
• Çift ödeme koruması ve denetim kaydı
• Kabul testinde bağlantı kopması senaryosu

Mutabakat: kimin rakamı doğru?

Seamless modelde bahis ve kazanç kaydı sizde tutulur; sağlayıcıda da aynı işlemlerin bir kopyası vardır. İki tarafın toplamı her gün eşleşmelidir. Eşleşmediğinde fark genellikle zaman aşımı sonrası tekrar, saat dilimi kayması ya da iptal edilmiş turlardan gelir. Günlük otomatik mutabakat raporu olmayan bir entegrasyonda bu farklar aylar sonra, çoğu zaman bir ödeme tartışmasında ortaya çıkar.

Transfer wallet modelinde mutabakat daha basittir, çünkü yalnızca para transferlerini karşılaştırırsınız. Ancak oyun içi kayıtlar sağlayıcıda kaldığı için oyuncu şikâyetlerinde kendi veritabanınızdan cevap veremezsiniz. Hangi modeli seçerseniz seçin, işlem seviyesinde indirilebilir rapor ve en az 12 aylık geçmiş sözleşmeye yazılmalı.

• Günlük otomatik mutabakat raporu
• İşlem seviyesinde indirilebilir kayıt
• Fark toleransı ve eskalasyon süreci
• Rapor geçmişinin saklama süresi

Hangisi hangi operatör için doğru

Tek bakiye, ürünler arası bonus ve sorunsuz oyuncu deneyimi istiyorsanız seamless tek mantıklı seçim; bugün piyasadaki entegrasyonların büyük kısmı da bu modeli varsayıyor. Karşılığında kendi cüzdan servisinizin yüksek erişilebilirlikte, düşük gecikmeli ve idempotent olmasını sağlamanız gerekir. Bu bir altyapı taahhüdüdür, bir yapılandırma seçeneği değil.

Transfer wallet, cüzdan servisinizin olgunlaşmadığı ilk dönemde ya da tek bir sağlayıcıyla sınırlı bir denemede makul bir ara çözüm olabilir. Ancak ürün sayısı arttıkça oyuncu deneyimi ve destek maliyeti bu modeli pahalı hale getirir. Planınız büyümeyi içeriyorsa, seamless'a geçişi ilk günden yol haritasına yazın; sonradan geçiş, canlı bakiyeleri taşımak anlamına gelir.

• Cüzdan servisinin erişilebilirlik hedefi
• Ürün sayısı ve ortak bonus ihtiyacı
• Geçiş planı ve canlı bakiye taşıma riski
• Sağlayıcının desteklediği modeller

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.