Bonus Teknik Analizi: Ödeme Yöntemleri, KYC ve API Akışları.

Giriş

Bu rehber, "bonus teknik analizi" çerçevesinde online promosyonların arka plandaki mühendislik akışlarını, ödeme yöntemi kısıtlarının nasıl uygulandığını, KYC süreçlerinin teknik entegrasyonunu ve API mimarilerini uygulamalı şekilde açıklar. İçerik, ürün sahipleri, backend geliştiricileri ve operasyon ekipleri için pratik adımlar içerir.

Temel Kavramlar

Bonus ve cüzdan ayrımı

Çoğu sistemde iki ayrı bakiye türü olur: çekilebilir bakiye (withdrawable) ve bonus/pending bakiye. Bonus tipi (ücretsiz çevirme, eşleşen bonus vb.) sistemde ayrı bir "bonus ledger" içinde tutulur. Teknik olarak bonus, doğrudan çekilebilir bakiyeye dönüştürülene kadar kısıtlı bir nesne olarak değerlendirilir.

Mutabakat ve işlem idempotency

Ödeme sağlayıcılarından gelen callback'ler tekrarlanabilir olabilir; bu yüzden idempotent işleme (aynı ödeme bildiriminin birden çok kez işlenmesinin önlenmesi) ve günlük mutabakat tabloları kritik öneme sahiptir.

Bonus Yaşam Döngüsü: Teknik Akış (Adım Adım)

Kullanıcı tetikler: Kullanıcı bir promosyonu seçer veya bir kampanya otomatik olarak tetiklenir (ör. ilk depozito).
Ödeme başlatma: Kullanıcı ödeme yapar; front-end ödeme sağlayıcısına yönlendirir veya API çağrısı başlatılır.
Ödeme doğrulama: Ödeme sağlayıcıdan gelen callback/helezon bilgilendirmesi alınır ve işlem idempotency ile ledger'a kaydedilir.
KYC / kimlik durumu kontrolü: Kullanıcının KYC durumu kontrol edilir. Eğer doğrulama gerekli ise bonus beklemeye alınır.
Risk ve kurallar kontrolü: Ödeme yöntemi, coğrafi konum, önceki davranış ve kampanya kuralları değerlendirilir; olumsuz bir sonuç varsa bonus reddedilebilir veya elle incelemeye yönlendirilebilir.
Bonus kredilendirme: Tüm kontroller geçerse bonus, bonus ledger'da "pending" veya doğrudan kullanıcıya atanır (iş modeline göre).
Wagering / kullanım dönemi: Bonusun kullanım koşulları (geçerlilik süresi, çevirme şartları) takip edilir; bu durumlar event-driven job'larla izlenir.
Bonusın dönüştürülmesi: Şartlar sağlandığında bonus bakiyesi çekilebilir hale getirilir ve ana bakiye ile mutabakat yapılır.
Mutabakat ve kayıt: Ödeme sağlayıcı ve operatör hesapları düzenli olarak rekonsile edilir; raporlar tutulur.

Ödeme Metod Kısıtları: Neler Kontrollü Olmalı?

Her ödeme metodunun getirdiği risk ve kısıtlama farklıdır. Aşağıdaki tablo, sık karşılaşılan metodlar ve önerilen kontrolleri özetler.

Ödeme Metodu	Sık Yapılan Kontroller	Operasyonel Karar Örneği
Kredi/Banka Kartı	3D Secure durumu, chargeback geçmişi, kart sahibi doğrulaması	Onay sonrası bonusu serbest bırak; yüksek chargeback geçmişi olan hesaplar için elle inceleme.
E-cüzdanlar (e‑wallet)	Cüzdan sağlayıcı kimliği, aynı sağlayıcı üzerinden hızlı para çıkışı riski	Bazı kampanyaları yalnızca bank transferi veya kart ile sınırlama tercih edilebilir.
Ön ödemeli kartlar / voucher	anonymity düzeyi, yükleme kaynağı	Yüksek anonimlik içeren yöntemlerde bonusu beklemeye alma veya kısıtlama.
Banka Havalesi	Hesap sahibi eşleşmesi, IBAN doğrulaması	Hesap isimleri uyuşmuyorsa manuel inceleme tetiklenebilir.

Uygulama Notları

Kuralları kampanya motorunda konfigüre edilebilir hale getirin (ör. ödeme metodu bazlı izin/ret).
Ödeme sağlayıcıdan gelen "settlement" ve "authorization" ayrımını ledger'a yansıtın.
Döviz dönüşümlerini merkezî bir servis üzerinden standartlaştırın.

KYC Akışı: Mühendislik ve Operasyon Adımları

KYC entegrasyonu tipik olarak üçüncü taraf doğrulama sağlayıcıları ile webhook tabanlı çalışır. Aşağıda tipik durumlar ve teknik öneriler yer alır.

Durum haritası (status mapping)

unverified / new: Henüz belge gelmemiş veya istenmemiş.
pending: Belge gönderildi, doğrulama bekleniyor.
verified / approved: KYC tamamlandı; bonus koşulları değerlendirmeye alınabilir.
rejected: Kimlik doğrulaması başarısız; otomatik red veya manuel inceleme tetiklenir.

Teknik öneriler

Webhook imzalama ve zaman damgası ile callback güvenliği sağlayın.
Doğrulama sonuçlarını idempotent şekilde işlemeyi garanti edin.
Veri minimizasyonu ilkesiyle yalnızca gerekli KYC alanlarını saklayın; hassas veriyi üçüncü tarafta bırakmayı tercih edin.
Manuel inceleme gerektiren durumlar için queue/uygulama iş akışı oluşturun.

API Entegrasyonu: Mimari Öneriler ve Örnek Uç Noktalar

Aşağıda tipik bir mimaride bulunması önerilen uç noktaların bir özeti verilmiştir. Gerçek isimler ve parametreler ürününüze göre değişecektir.

Endpoint	HTTP Metod	Amaç / Örnek Parametreler
/payment/initiate	POST	amount, currency, method, merchant_reference
/payment/callback	POST	provider_reference, status, amount, signature
/kyc/submit	POST	user_id, document_type, document_reference
/kyc/status	GET	user_id
/bonus/apply	POST	user_id, campaign_id, payment_reference
/wallet/credit	POST	user_id, amount, reason, ledger_type

Mimari notlar

API erişimi için token tabanlı kimlik doğrulama (ör. OAuth 2.0) ve rol bazlı erişim kontrolü önerilir.
Webhooks için imza doğrulama, IP allowlist ve retry/adalet mekanizmaları uygulayın.
Uç noktalar idempotent olmalı; payment callback'leri için unique provider_reference kullanın.

Güvenlik, Loglama ve Mutabakat

Güvenlik operasyona eşlik eder. Öneriler:

Tüm taşıma katmanında HTTPS (TLS) kullanın ve tokenleri güvenli saklayın.
Kart verileri ve hassas kimlik bilgilerini doğrudan saklamayın; PCI uyumu gerektiriyorsa uzman rehberliği alın.
İşlem günlükleri (audit logs) ve mutabakat raporları düzenli olarak kontrol edilmelidir.
Olay yönetimi ve alarmlar (ör. anormal işlem hızları, yüksek iade/iptal oranları) kurun.

Operasyonel Örnek Senaryo

Pratik bir akış örneği:

Kullanıcı kart ile $50 yatırır. Payment provider authorization ve settlement aşamalarını callback ile bildirir.
Sistem, kullanıcının KYC durumunu kontrol eder; eğer "pending" ise bonus "awaiting KYC" durumuna alınır.
KYC onayı geldikten sonra risk skoru kontrol edilir; düşük risk ise bonus kredilenir ve bonus ledger güncellenir.
Kullanıcı şartları yerine getirdiğinde bonus otomatik olarak çekilebilir bakiyeye dönüştürülür; muhasebe kayıtları oluşturulur.

Test, Hata Yönetimi ve İzleme

Sandbox ortamında uç nokta cevaplarını ve webhook tekrarlarını simüle edin.
İdempotency, concurrency ve race condition testleri planlayın.
Mutabakat sapmalarını sınıflandırın ve otomatik düzeltme / uyarı kuralları oluşturun.

Canlıya Alma Kontrol Listesi

API güvenlik ve imza doğrulama testleri tamamlandı.
KYC sağlayıcı entegre ve webhooklar doğrulandı.
Ödeme sağlayıcı ile settlement mutabakatı planlandı.
Operasyonel el kitabı ve manuel inceleme iş akışları hazır.
Monitoring ve alarm kuralları aktif.

Sınırlamalar ve Yasal Not

Bu yazı teknik ve operasyonel yaklaşımlar sunar; yasal uyumluluk, mali veya düzenleyici yorum içermez. Uygulama ve kurallar ülke ve bölgeye göre değişebilir; canlıya almadan önce yetkin hukuk ve uyumluluk danışmanlığı almanız önerilir. Ayrıca, burada yer alan örnekler uygulama-odaklıdır ve ürününüzün özel gereksinimlerine göre uyarlanmalıdır.

Sıkça Sorulan Sorular (Kısa)

Bonus KYC doğrulaması nedeniyle neden beklemeye alınır?

KYC doğrulaması, kullanıcının kimliğini ve ödeme kaynağını doğrulamak içindir; doğrulama tamamlanmadan bonus verme, ileride düzeltme gerektirebilecek durumlara yol açabileceğinden bazı operatörler bonusu beklemeye alır.

Ödeme yöntemi değişirse bonus ne olur?

Bir kullanıcının depozito yöntemi kampanya şartlarına uymuyorsa bonus reddedilebilir veya elle incelemeye düşebilir. Bu davranışı kampanya kurallarına göre sistemsel olarak kontrol etmek önemlidir.

Webhook tekrarları nasıl yönetilmeli?

Her callback için benzersiz bir provider_reference kullanın ve idempotency anahtarları ile aynı bildirimin tekrar işlenmesini engelleyin. Loglama ve retry mantığı kurun.

KYC verilerini ne kadar süre saklamalıyım?

Veri saklama süreleri yerel düzenlemelere göre değişir; veri minimizasyonu ilkesi çerçevesinde yalnızca gerekli süre boyunca tutun ve erişimi sınırlandırın. Hukuki gereklilikler için uzman görüşü alın.

Bonusların Teknik İşleyişi: Ödeme Metodları, KYC ve API Akışları