Kiralık Bahis Sisteminde Entegrasyon: Ödeme, Oran ve CRM Bağlantıları

Kiralık bir bahis sisteminde entegrasyon sancılarının büyük kısmı eksik özelliklerden değil, belirsiz sınırlardan kaynaklanır. Çekirdek platformu satın almazsınız; kiralarsınız. Dolayısıyla ödeme sağlayıcısı, oran beslemesi ve CRM katmanı gibi dış servislerle konuşan taraf genellikle siz olursunuz, ama bu konuşmanın nerede başlayıp nerede bittiği sözleşmede çoğu zaman net değildir. Bir Açık sistem bahis sitesi altyapısı üzerinde çalışırken en çok zaman kaybettiren şey, “bu iş kimin sorumluluğunda?” sorusunun her entegrasyonda yeniden sorulmasıdır. Bu yazıda, teknik lider gözüyle, kiralık bir platformda ödeme, oran ve CRM bağlantılarının gerçekte nasıl oturduğunu ve her katmanda tedarikçiyle önceden hangi soruları netleştirmeniz gerektiğini anlatıyorum.

Entegrasyon Katmanlarını Ayırmak Neden Hayati?

Kiralık sistemlerde en pahalı hata, tüm dış bağlantıları tek bir “entegrasyon” başlığı altında düşünmektir. Oysa ödeme, oran ve CRM birbirinden tamamen farklı hata toleranslarına, farklı gecikme bütçelerine ve farklı sahiplik modellerine sahiptir. Ödeme katmanında bir saniyelik belirsizlik doğrudan para kaybıdır. Oran katmanında 300 milisaniyelik gecikme kullanıcı deneyimini bozar ama felaket değildir. CRM katmanında ise bir günlük gecikme çoğu zaman tolere edilebilir; yeter ki veri kaybolmasın.

Bu üç katmanı ayrı ayrı ele almadığınızda, tedarikçi size tek bir SLA verir ve bu SLA genellikle en yavaş katmana göre yazılır. Sonuçta ödeme akışınız gereğinden yavaş, oran akışınız gereğinden kırılgan olur. Doğru yaklaşım, her katman için ayrı bir sahiplik matrisi çıkarmaktır: kim API anahtarını yönetiyor, kim hata durumunda ilk müdahaleyi yapıyor, kim logları tutuyor, kim kullanıcıya mesaj veriyor. Bu matris sözleşmeye eklenmediği sürece, canlıya çıktığınız ilk hafta sonu herkes birbirini suçlar.

Ödeme Sağlayıcıları: En Yüksek Riskli Bağlantı

Ödeme entegrasyonu, kiralık bir bahis sisteminde neredeyse her zaman en karmaşık parçadır. Çünkü burada üç ayrı taraf vardır: platformun kendisi, ödeme sağlayıcısı ve para akışını izleyen finans modülü. Kiralık modelde finans modülü çoğu zaman platformun içindedir ama ödeme sağlayıcısıyla konuşan webhook’ları sizin tarafınızda yazmanız gerekir.

İlk netleştirmeniz gereken soru şudur: para yatırma ve çekme akışlarında idempotency anahtarını kim üretiyor? Eğer platform bu anahtarı üretmiyorsa ve siz üretiyorsanız, aynı işlemin iki kez işlenmesi riski tamamen sizin omuzlarınızdadır. İkinci soru, başarısız işlemlerde bakiyenin ne zaman düşüldüğüdür. Bazı kiralık sistemler önce bakiyeyi düşürüp sonra sağlayıcıdan onay bekler; bu modelde sağlayıcı zaman aşımına uğrarsa kullanıcı parasını görmez ama bakiyesi de eksilmiş olur. Üçüncü soru ise mutabakat: günlük kapanışta platformdaki toplam ile sağlayıcıdaki toplamı kim karşılaştırıyor?

Bu üç sorunun cevabı sözleşmede yazılı değilse, ödeme katmanını canlıya almadan önce mutlaka yazılı hale getirin. Ayrıca test ortamında sağlayıcının “başarılı ama gecikmeli”, “başarısız ama para çekilmiş” gibi uç senaryolarını simüle edin. Kiralık platformlarda bu senaryolar genellikle dokümante edilmemiştir ve ilk gerçek olayda panik yaratır.

Oran Beslemeleri: Gecikme, Kapsam ve Kesinti Yönetimi

Oran beslemesi, kiralık bir bahis sisteminin görünmez ama en çok konuşulan katmanıdır. Kullanıcı oranın nereden geldiğini bilmez; sadece güncel olup olmadığına bakar. Sizin için kritik olan üç metrik vardır: besleme gecikmesi, kapsam genişliği ve kesinti süresi.

Gecikme konusunda tedarikçiye sormanız gereken ilk şey, oranın kaynaktan kullanıcı ekranına kadar kaç saniyede ulaştığıdır. Bazı sağlayıcılar “gerçek zamanlı” der ama bu 5 saniyeye kadar çıkabilir; canlı bahis için bu kabul edilemez. İkinci soru, besleme kesildiğinde platformun ne yaptığıdır. Oranlar donuyor mu, son bilinen değer mi gösteriliyor, yoksa bahis tamamen mi kapanıyor? Bu davranış kiralık platformun çekirdeğinde tanımlıdır ve siz değiştiremezsiniz; ama en azından bilmeniz gerekir.

Kapsam konusunda ise hangi liglerin, hangi marketlerin ve hangi saat dilimlerinin dahil olduğunu netleştirin. Kiralık sistemlerde sık görülen bir tuzak, düşük öncelikli liglerin oranlarının gecikmeli gelmesidir. Kullanıcılarınızın yoğunlaştığı ligleri özellikle test edin. Son olarak, besleme sağlayıcısı ile platform arasındaki eşleştirme kurallarını isteyin: takım isimleri, market kodları ve bahis tipleri nasıl eşleniyor? Bu eşleştirme tablosu sizde yoksa, bir maçın oranları yanlış markete düşebilir ve bunu fark etmeniz saatler alabilir.

CRM Bağlantısı: Veri Akışının Görünmeyen Omurgası

CRM entegrasyonu, kiralık bahis sistemlerinde en çok hafife alınan katmandır. Çünkü CRM genellikle “sonradan bağlanır” diye düşünülür. Oysa kullanıcı kaydı, KYC durumu, ilk para yatırma, ilk bahis ve kayıp geri kazanım gibi tüm yaşam döngüsü olayları bu katmandan akar. Kiralık bir platformda bu olayların hangilerinin dışarıya açıldığı kritik bir sorudur.

Tedarikçiye sormanız gereken ilk soru, olay tabanlı bir yapı olup olmadığıdır. Eğer platform sadece günlük toplu veri veriyorsa, gerçek zamanlı kampanya yürütemezsiniz. İkinci soru, kullanıcı kimliğinin CRM tarafında nasıl eşleştiğidir. Platformdaki kullanıcı ID’si ile CRM’deki kişi ID’si arasında kalıcı bir bağ yoksa, aynı kullanıcıya iki kez hoş geldin bonusu gönderme riski doğar. Üçüncü soru ise geri yazma iznidir: CRM’den platforma segment etiketi gönderebiliyor musunuz, yoksa akış tek yönlü mü?

Bu katmanda en sık yaşanan sorun, olayların sırasının bozulmasıdır. Örneğin para yatırma olayı, kayıt olayından önce düşerse CRM yanlış bir yolculuk başlatır. Kiralık platformlarda bu tür sıralama garantileri genellikle verilmez; bu yüzden CRM tarafında tamponlama ve yeniden sıralama mantığı kurmanız gerekir. Bunu baştan planlamazsanız, ilk kampanya döneminde veri kalitesi çöker.

Tedarikçiyle Önceden Netleştirilmesi Gereken Sınırlar

Kiralık bir bahis sisteminde entegrasyonun başarısı, tedarikçiyle oturup konuştuğunuz ilk toplantıda belirlenir. Bu toplantıda üç belge çıkarmalısınız: sahiplik matrisi, hata senaryosu listesi ve veri akış şeması.

Sahiplik matrisi, her entegrasyon noktası için kimin neyden sorumlu olduğunu tek sayfada gösterir. Örneğin ödeme webhook’u çalışmazsa ilk kim bakar, oran beslemesi kesilirse kim bilgilendirilir, CRM olayı kaybolursa kim logları inceler. Hata senaryosu listesi, her katman için en az beş uç durumu ve beklenen davranışı tanımlar. Veri akış şeması ise hangi verinin nereden çıkıp nereye gittiğini, hangi noktada dönüştürüldüğünü ve hangi noktada saklandığını gösterir.

Bu üç belge olmadan canlıya çıkmak, kiralık sistemlerde neredeyse her zaman aynı sonucu verir: ilk büyük maç gecesinde ekip kör uçuş yapar. Ayrıca tedarikçiden yazılı SLA isteyin; sözlü taahhütler kiralık modelde bağlayıcı değildir. SLA’da yanıt süresi, çözüm süresi ve kesinti telafisi gibi maddelerin açıkça yazılması gerekir. Bunlar olmadan, teknik ekibiniz sürekli yangın söndürür ve ürün geliştirmeye zaman kalmaz.

Son olarak, entegrasyonların izlenebilirliğini baştan kurun. Her katman için ayrı log, ayrı alarm ve ayrı sağlık kontrolü tanımlayın. Kiralık bir platformda çekirdeği göremezsiniz; bu yüzden gördüğünüz her şeyi ölçmeniz gerekir. Ölçmediğiniz bir bağlantı, ilk kesintide sizi tamamen savunmasız bırakır.

Sıkça Sorulan Sorular

Kiralık bahis sisteminde ödeme sağlayıcısını değiştirmek ne kadar sürer?

Teknik olarak yeni sağlayıcının API’sini bağlamak birkaç gün sürebilir; ancak asıl süre mutabakat, test ve kullanıcı geçiş planlamasında harcanır. Kiralık platformda finans modülünün yeni sağlayıcıyı tanıması için tedarikçi tarafında yapılandırma gerekebilir. Bu yüzden gerçekçi süre iki ila dört hafta arasındadır. Canlıya geçişi düşük trafikli bir saat diliminde yapmanız ve eski sağlayıcıyı en az bir hafta yedekte tutmanız önerilir.

Oran beslemesi kesildiğinde kullanıcıya ne gösterilmeli?

Bu tamamen platformun çekirdek davranışına bağlıdır ve sizin değiştiremeyeceğiniz bir alandır. Bazı sistemler son bilinen oranı gösterip bahsi kapatır, bazıları ilgili marketi tamamen kaldırır. Kullanıcı açısından en az kafa karıştıran davranış, etkilenen marketlerin geçici olarak kapatılması ve kısa bir bilgilendirme gösterilmesidir. Tedarikçiden bu davranışın yazılı tanımını isteyin; sözlü açıklama yeterli değildir.

CRM entegrasyonunda en sık yapılan hata nedir?

Olay sırasının garanti edildiğini varsaymaktır. Kiralık sistemlerde olaylar çoğu zaman paralel akar ve sıra bozulabilir. Bu yüzden CRM tarafında her olayı bağımsız işleyebilecek, eksik veriyle bile doğru karar verebilecek bir yapı kurmak gerekir. Ayrıca kullanıcı kimliği eşleştirmesini kalıcı hale getirmeden kampanya başlatmak, mükerrer iletişim ve yanlış segmentasyon sorunlarına yol açar.

Tedarikçiden hangi teknik dokümanları istemeliyim?

En azından API referansı, webhook listesi, hata kodları tablosu, veri sözlüğü ve entegrasyon mimarisi şemasını isteyin. Bunlara ek olarak, bilinen sınırlamalar ve desteklenmeyen senaryolar listesini de talep edin. Kiralık modelde bu dokümanlar genellikle eksiktir; eksik olan her alanı kendi ekibinizin doldurması gerekeceğini baştan kabul edin.