Bahis Platformu Entegrasyonları: Ödeme, Oran ve CRM Bağlantıları

Her entegrasyon bir bağımlılık, her bağımlılık bir risk noktasıdır. Bir operatörün teknik ekibinde çalışırken bunu ilk gün öğreniyorsunuz: platformun kendi kodunuz ne kadar temiz olursa olsun, dışarıdan gelen her veri akışı sizin çalışma zamanınızın bir parçası haline geliyor. Bu yazıda PlaybetAi gibi turnkey ve white label çözümlerle kurulan bir bahis platformunda ödeme sağlayıcıları, oran beslemeleri ve CRM araçlarının nasıl bağlandığını, hangi noktalarda kırıldığını ve bu kırılmaları test ederek nasıl önlediğimizi anlatacağım. Amaç teorik bir mimari çizimi değil; gerçek trafik altında çalışan bir sistemde entegrasyon katmanını ayakta tutma pratiği.

API Katmanı: Tüm Entegrasyonların Ortak Zemini

Bir bahis platformunda entegrasyon yüzeyi üç ana eksende toplanıyor: para giriş-çıkışı, oran ve sonuç verisi, kullanıcı iletişimi. Bu üç eksenin ortak zemini API katmanı. PlaybetAi tarafında olduğu gibi turnkey bir altyapıda bu katman genellikle hazır gelir, ancak operatör olarak siz yine de her uç noktanın sözleşmesini (contract) bilmek zorundasınız. Hangi endpoint idempotent, hangisi değil? Hangi çağrı senkron, hangisi asenkron kuyruğa düşüyor? Bu soruların cevabı, olay anında panik yapıp yapmayacağınızı belirliyor.

Kendi ekibimizde ilk kural şu: her dış servis için bir “bağımlılık envanteri” tutuyoruz. Bu envanterde servis adı, sorumlu kişi, kritiklik seviyesi, timeout değerleri, retry politikası ve son başarısız olduğu tarih yer alıyor. Bir ödeme sağlayıcısı üç dakika yanıt vermediğinde ne olacağını bu envanterden okuyoruz. Oran beslemesi geciktiğinde hangi maçların askıya alınacağını yine buradan biliyoruz. Envanter güncel değilse, entegrasyon da güvenilir değil.

Ödeme Sağlayıcı Entegrasyonu: Para Akışının Kırılma Noktaları

Ödeme entegrasyonu, bir bahis platformunda en çok hata üreten alandır. Sebebi basit: para hareketi geri alınamaz ve kullanıcı sabırsızdır. Bir yatırım isteği geldiğinde üç ayrı sistem konuşur: kullanıcı arayüzü, platformun finans yönetimi modülü ve dış ödeme sağlayıcısı. Bu üçlü arasındaki her mesaj kaybı, ya askıda kalan bir bakiye ya da çift kayıt üretir.

En sık gördüğüm hata, webhook ile dönen sonucun senkron yanıtla çakışması. Kullanıcı ödeme sayfasından döndüğünde platform “başarılı” diyor, ama sağlayıcının webhook’u iki saniye sonra “beklemede” gönderiyor. İki farklı gerçeği aynı anda yaşamamak için tek bir doğruluk kaynağı seçmek gerekiyor. Bizim yaklaşımımız: nihai durumu her zaman webhook belirler, senkron yanıt yalnızca kullanıcıya gösterilecek geçici mesajı üretir. Bu kural yazılı olmadığı sürece her geliştirici kendi mantığını kurar ve tutarsızlık kaçınılmaz olur.

İkinci kırılma noktası para birimi ve yuvarlama. Farklı sağlayıcılar farklı ondalık hassasiyetle çalışır. 100.005 gibi bir tutar bir yerde 100.00, başka yerde 100.01 olabilir. Finans yönetimi tarafında tek bir para birimi politikası ve tek bir yuvarlama fonksiyonu tanımlamadıysanız, mutabakat (reconciliation) sırasında açıklanamayan farklar birikir. Bu farklar küçük görünür ama denetimde büyük baş ağrısı yapar.

Üçüncü nokta, iade ve ters ibraz (chargeback) akışı. Ödeme almak kadar geri almak da bir entegrasyondur. Sağlayıcının iade API’si çoğu zaman yatırma API’sinden farklı kimlik doğrulama kullanır. Bu yüzden iade senaryolarını ayrı bir test paketi olarak ele alıyoruz. Test ortamında iade denemeyen ekip, canlıda ilk iade talebinde kilitlenir.

Oran Beslemeleri: Gecikme, Tutarlılık ve Askıya Alma

Oran beslemesi, platformun nabzıdır. Besleme geciktiğinde kullanıcı eski oranı görür, siz ise yeni oranı kabul etmiş olursunuz; bu da doğrudan finansal risk demektir. Bu yüzden oran entegrasyonunda üç metriği sürekli izliyoruz: besleme gecikmesi, saniyedeki güncelleme sayısı ve reddedilen bahis oranı. Bu üç metrikten biri bozulduğunda otomatik askıya alma devreye girer.

Besleme sağlayıcıları genellikle iki formatta veri gönderir: tam maç listesi (snapshot) ve değişiklik akışı (delta). İkisini karıştırmak klasik bir hatadır. Snapshot’ı delta gibi işlerseniz, maç listesini her seferinde sıfırlarsınız. Delta’yı snapshot gibi işlerseniz, kaldırılan maçları sistemde bırakırsınız. Bu yüzden her iki akış için ayrı işleyiciler ve ayrı doğrulama kuralları yazıyoruz. Bir maçın durumu “kapalı”ya döndüğünde, o maça ait tüm açık bahislerin anında işaretlenmesi gerekiyor; bu adım atlanırsa kullanıcı kapanmış bir maça bahis oynayabilir.

Oran tutarlılığında bir diğer tuzak, çoklu sağlayıcı kullanımı. Yedeklilik için iki farklı besleme bağladığınızda, aynı maç için iki farklı oran gelebilir. Hangisinin kazanacağını önceden tanımlamazsanız, kullanıcıya gösterilen oran ile bahis kabul edilen oran ayrışır. Bizim çözümümüz: birincil sağlayıcıyı net biçimde tanımlamak, ikincil sağlayıcıyı yalnızca birincil düştüğünde devreye almak ve geçiş anını loglamak. Geçiş anında kısa bir askıya alma penceresi açmak, tutarsız oran kabul etmekten çok daha az maliyetlidir.

CRM ve Kullanıcı Verisi Entegrasyonu: Segmentasyonun Omurgası

CRM entegrasyonu çoğu operatörün hafife aldığı ama en çok geri dönüş sağlayan alandır. Buradaki temel soru şu: kullanıcı davranışını hangi olaylar (event) üzerinden takip ediyorsunuz? Kayıt, ilk yatırım, ilk bahis, kayıp serisi, terk edilen sepet, destek talebi. Bu olayları platformdan CRM’e doğru akan bir kuyruk üzerinden göndermek, CRM’in kampanya motorunu besler.

En sık yapılan hata, CRM’i yalnızca e-posta gönderme aracı olarak görmek. Oysa doğru kurguda CRM, kullanıcı yaşam döngüsünün karar merkezidir. Biz olayları gönderirken üç kurala uyuyoruz: her olayda kullanıcı kimliği tekil olmalı, olay zaman damgası platformun saat diliminde tutarlı olmalı, ve aynı olay iki kez gönderilse bile CRM tarafında tekilleştirilebilmeli. Bu son madde özellikle önemli; kuyruk yeniden denemeleri kaçınılmazdır ve mükerrer olaylar yanlış segmentasyon üretir.

Veri gizliliği tarafında ise CRM entegrasyonu, platformun en hassas veri köprüsüdür. Kullanıcı kimlik bilgileri, ödeme geçmişi ve davranış verisi aynı akışta taşınır. Bu yüzden alan bazlı maskeleme uyguluyoruz: CRM’e giden olaylarda tam kart bilgisi, tam kimlik numarası gibi alanlar asla yer almaz. Yalnızca kampanya için gerekli olan türetilmiş etiketler gönderilir. Bu, hem yasal uyum hem de sızıntı durumunda hasarın sınırlanması açısından kritik.

Finans Yönetimi Modülü ile Mutabakat Akışı

Finans yönetimi, tüm entegrasyonların kesiştiği yerdir. Ödeme sağlayıcılarından gelen hareketler, oran beslemesinden doğan bahis sonuçları ve CRM’den gelen kampanya maliyetleri aynı defterde buluşur. Bu defterin doğru olması, entegrasyonların doğru olmasına bağlıdır. Tersi de geçerli: entegrasyonlardan biri sessizce bozulduğunda ilk belirti genellikle finans tarafında görülür.

Mutabakat akışını günlük, saatlik ve anlık olmak üzere üç katmanda çalıştırıyoruz. Günlük mutabakat sağlayıcı ekstreleriyle platform defterini karşılaştırır. Saatlik mutabakat, açık kalan işlemleri yakalar. Anlık kontrol ise her işlem sonrası bakiye tutarlılığını doğrular. Bu üç katman birbirinin yedeği değil, tamamlayıcısıdır. Yalnızca günlük mutabakatla çalışan bir platform, bir gün boyunca yanlış bakiye gösterebilir ve bunu ancak ertesi sabah fark eder.

Jackpot yönetimi ve slot tarafındaki entegrasyonlar da aynı deftere bağlanır. Bir jackpot ödemesi, finans modülünde ayrı bir hareket olarak izlenmelidir; aksi halde oyun tarafındaki kazanç ile finans tarafındaki çıkış eşleşmez. Bu eşleşmeyi otomatikleştirmek, manuel kontrolün kaçıracağı farkları ortadan kaldırır.

Test Stratejisi: Entegrasyonu Kırmadan Yayına Almak

Entegrasyon testi, birim testinden farklı bir disiplindir. Burada test ettiğiniz şey kendi kodunuz değil, iki sistem arasındaki sözleşmenin gerçek hayatta tutup tutmadığıdır. Bu yüzden test ortamının canlıya mümkün olduğunca benzemesi gerekir. Sahte (mock) sağlayıcılarla başlamak doğru, ama yayına almadan önce gerçek sağlayıcının kum havuzu (sandbox) ortamında en az bir tam döngü çalıştırmak şart.

Test paketimizde dört senaryo mutlaka bulunur: mutlu yol, zaman aşımı, kısmi başarı ve mükerrer istek. Mutlu yol zaten herkesin test ettiği şey. Asıl değer diğer üçünde. Zaman aşımında sistem ne yapıyor? Kısmi başarıda hangi kayıt tutuluyor? Mükerrer istek geldiğinde ikinci kez para çekiliyor mu? Bu sorulara yanıt veremeyen bir entegrasyon, yayına hazır değildir.

Bir de gözlemlenebilirlik (observability) konusu var. Her entegrasyon çağrısı için bir iz kimliği (trace id) üretiyoruz ve bu kimliği hem platform loglarına hem sağlayıcıya gönderilen isteğe ekliyoruz. Böylece bir kullanıcı şikayeti geldiğinde, o işlemin hangi sağlayıcı çağrısına denk geldiğini saniyeler içinde bulabiliyoruz. Log olmadan entegrasyon yönetimi, karanlıkta tamir denemesi yapmaktır.

Yayına Alma ve Devreye Girme: Kademeli Geçişin Önemi

Yeni bir entegrasyonu bir anda tüm trafiğe açmak, en pahalı hatadır. Biz kademeli geçiş uyguluyoruz: önce toplam trafiğin küçük bir yüzdesi, sonra belirli bir kullanıcı segmenti, sonra tüm kullanıcılar. Her aşamada aynı metrikleri izliyoruz ve geri alma (rollback) planı hazır tutuyoruz. Geri alma planı olmayan bir yayın, aslında bir yayın değildir.

Kademeli geçişin bir diğer faydası, sağlayıcı tarafındaki limitleri keşfetmek. Bir ödeme sağlayıcısı saniyede belirli sayıda istek kabul eder; bunu canlıda tüm trafikle öğrenmek istemezsiniz. Küçük bir yüzdeyle başlayıp limitleri ölçmek, hem sağlayıcıyla ilişkinizi korur hem de kesinti riskini azaltır.

Son olarak, entegrasyonların bakımı süreklidir. Sağlayıcılar API sürümlerini değiştirir, alan adlarını günceller, kimlik doğrulama yöntemlerini sıkılaştırır. Bu değişiklikleri takip etmek için her sağlayıcı için bir “değişiklik aboneliği” tutuyoruz. Sürüm notlarını okuyan bir ekip, yarın çökecek bir entegrasyonu bugün onarır.

Sık Sorulan Sorular

Bir bahis platformunda ödeme entegrasyonu neden en riskli alandır?

Çünkü para hareketi geri alınamaz ve kullanıcı beklentisi anlıktır. Webhook ile senkron yanıt arasındaki tutarsızlık, para birimi yuvarlama farkları ve iade akışının ayrı kimlik doğrulama kullanması, en sık karşılaşılan kırılma noktalarıdır. Tek bir doğruluk kaynağı belirlemek ve iade senaryolarını ayrı test etmek riski büyük ölçüde azaltır.

Oran beslemesinde çoklu sağlayıcı kullanmak gerekli mi?

Yedeklilik açısından faydalıdır, ancak birincil ve ikincil sağlayıcı net biçimde tanımlanmazsa aynı maç için iki farklı oran oluşur. Bu durumda kullanıcıya gösterilen oran ile kabul edilen oran ayrışır. Doğru yaklaşım, ikincil sağlayıcıyı yalnızca birincil düştüğünde devreye almak ve geçiş anında kısa bir askıya alma penceresi açmaktır.

CRM entegrasyonunda en kritik kural nedir?

Olayların tekilleştirilebilir olmasıdır. Kuyruk yeniden denemeleri kaçınılmaz olduğu için aynı olay birden fazla kez gönderilebilir. CRM tarafında tekilleştirme yoksa mükerrer olaylar yanlış segmentasyon üretir ve kampanya motoru yanlış kullanıcıya yanlış mesaj gönderir. Ayrıca hassas alanların maskelenmesi hem yasal uyum hem de veri güvenliği için şarttır.

Yeni bir entegrasyonu doğrudan tüm trafiğe açabilir miyim?

Önerilmez. Kademeli geçiş, hem hataların etkisini sınırlar hem de sağlayıcı tarafındaki istek limitlerini güvenli biçimde keşfetmenizi sağlar. Her aşamada aynı metrikleri izlemek ve hazır bir geri alma planı tutmak, yayına almayı bir kumar olmaktan çıkarır.