Ödeme sistemlerinin entegrasyonu nasıl çalışır

Ödemeler, bir online kumarhanenin "aorta'sıdır. İlk para yatırma, para çekme oranı, ters ibrazların payı, destek yükü ve hatta düzenleyicinin itibarı, ödeme sağlayıcılarıyla (PSP) entegrasyonun nasıl çalıştığına bağlıdır. Aşağıda pratik bir harita bulunmaktadır: hangi bileşenlere ihtiyaç duyulduğu, isteğin nasıl aktığı, korumanın nereye yerleştirileceği ve neyin sayılacağı.

1) Ödeme döngüsünün mimarisi

Ana birimler:

Ödeme UI'si-Yöntemi/para birimini/miktarını, 3DS/SCA, durumları, hataları seçin.
Ağ Geçidi: Kurallara göre PSP'ye yönlendirme (ülke, para birimi, risk, maliyet).
Cüzdan (PAM/Cüzdan): bilanço muhasebesi, RG limitleri, 'banka/kredi' işlemleri.
Antifraud/AML: yetkilendirme öncesi ve sonrası puanlama işlemi.
Webhooks (Callbacks): Son durumları onaylayın.
Faturalandırma/Uzlaşma: PSP'de ve cüzdanda günlük para tesadüfü.
Token depolama: PSP tokenization yoluyla kartlar/cüzdanlar, "ham" PAN'lar yok.

Birden çok PSP'ye yönlendirme:

Ülke/Banka/Para Birimi/Limit Kuralları, A/B Hatları, Bozulmada Otomatik Yük Aktarımı.

2) "Mevduat've" para çekme "akışları (şemalar)

Depozito (kart/cüzdan/bankacılık):

1. 'POST/payments/init' - bir niyet oluşturun (miktar, para birimi, yöntem).

2. Yönlendirme/SDK - 3DS/SCA/biometrics.

3. PSP bir ön durum döndürür (yetkilendirilmiş/beklemede/başarısız).

4. Webhook PSP - son durum (yakalandı/başarısız oldu).

5. Final + record RG/history limitlerine göre 'wallet/credit'.

Sonuç:

1. 'POST/payouts/init' - vager/limits/risk kontrolü.

2. PSP'de ödemeyi başlatmak (ideal olarak depozito ile aynı rota).

3. Webhook PSP - başarı/başarısız.

4. 'wallet/debit' başarı, başarısızlık nedeni günlüğü, oyuncu bildirimi.

3) İdempotans ve para bağlılığı

Her çağrı 'Idempotency-Key've benzersiz bir' txn _ id'ile yapılır.

Depozitolar/sonuçlar dengeyi sadece bir kez değiştirir - son webhook'a göre.

Herhangi bir tekrarlama sorgusu aynı 'txn _ id've durumunu döndürür.

Oyunlarla birlikte: 'round _ id' ↔ 'debit _ txn _ id'/' credit _ txn _ id'.

4) Güvenlik ve uyumluluk

TLS 1. 2+/1. 3, HSTS; HMAC imzası ve anti-replay ('timestamp', nonce) içeren webhooks.

PSP'de kartların tokenizasyonu; PCI DSS kapsam azaltma (barındırılan alanlar/sayfalar).

Kart SCA/3DS2, Banka Tarafından Ödeme için PSD2/Open Bankacılık.

GDPR: PII minimizasyonu, tutma, DSR süreçleri; Profil erişim günlüğü.

PSP ile bağlantılar için mTLS/IP allow-list, ödeme döngüsünün ayrılması.

5) Antifraud ve AML (ödeme öncesi ve sonrası)

Ön-auth kuralları: geo/ASN, cihaz, hız, davranış, geçiş.

ML puanlama/grafik: genel kartlar/cüzdanlar/cihazlar, tekrarlanan ters ibraz.

Auth sonrası izleme: iptaller, geri dönüşler, hızlı çıkış.

AML senaryoları: eşikler, yapılanma, olağandışı rotalar, STR/SAR raporları.

Step-up KYC: Çıkıştan önce orta/yüksek risk altında.

6) Webhooks: güvenilir teslimat

HMAC imzası, 'zaman damgası' doğrulaması ve 'event _ id' veri tekilleştirme.

PSP tarafındaki geri çekilmeler idempotenttir.

Teslimat günlükleri (başarı/başarısızlık), ölü harf kuyruğu ve manuel "yeniden oynatma".

Webhook, miktar/tanımlayıcılar eşleşmediği sürece dengeyi değiştirmez.

7) Hatalar ve zaman aşımları: yanıt tasarımı

Kodlar: '402' (ödeme gerekli), '409' (idempotent çakışma), '422' (doğrulama), '429' (oran-limit), '5xx' (olay).

Hata organları: 'error', 'message', 'trace _ id', 'details {...}' - yardım desteği ve uyarıları.

İstemcide zarif yeniden deneme (üstel geri alma), UI'de açık ipuçları.

8) Çoklu PSP yönlendirme ve yük devretme

Kalite kuralları: p95 yetkilendirmeleri, dönüştürme, 3DS dosyalarının paylaşımı, maliyet.

Akıllı yönlendirici: metrikler bozulursa, trafiği bir alternatife geçirin.

3DS istikrarı için oturum/bankaya yapışkan rota.

Bozunma planı:'ağır "yöntemleri kapatma, hızlı bırakma (P2P/Pay-by-Bank), çıktı kuyruğu.

9) Uzlaşma

Günlük PSP yükleme ve cüzdan ile otomatik doğrulama: eşleşen miktarlar, komisyonlar, iadeler.

Uyumsuzluklar - soruşturma için davalar.

Ters ibraz/iade/ücretlerle ilgili ayrı raporlar, gerçek marjın yöntemlerle hesaplanması.

10) Odakta kalmak için metrikler

Yöntem/banka/ülke/cihaz ile mevduat dönüşümü.

Depozito/çıkış süresi (p50/p95).

3DS-files paylaşımı, iptaller, iadeler, geri ödeme oranı.

Manuel incelemelerin ve TTV KYC'nin paylaşımı.

Çalışma süresi PSP ve rotaya göre yerel hata oranı.

Başarı başına maliyet ve yöntemle ROI.

11) Minimum API örneği (kısaltılmış)

Para yatırma niyeti oluşturma

'POST/v1/payments/init'

Json
{
"Miktar":" 50. 00", "para birimi":" EUR", "yöntem ":" kart", "return_url":"https://app. örnek. com/checkout/return", "idempotency_key":"b6a1-...," "meta ": {"ülke ": "FI"," cihaz":" ios"}
}

Cevap ver

Json
{"payment _ id ": "pay _ 123 ", "status ": "pending"," redirect _ url":" https ://psp. Örnek/3ds/"..}

Webhook durumu

'POST/v1/payments/webhook' + 'X-Signature: sha256 =..'

Json
{
"event_id":"evt_789," payment_id":"pay_123, "durum": "yakalanan", "miktar": "50. 00", "para birimi":" EUR", "zaman damgası":" 2025-10-17T09: 41: 00Z"
}

Kayıt (platform içinde)

'POST/v1/cüzdan/kredi'

Json
{"payment _ id ": "pay _ 123 ", "txn _ id":" txn _ 555"," amount":" 50. 00 ", "idempotency _ key":" b6a1- "..}

12) Kullanılabilirlik ve UX ödeme

Minimum adımlar: Ülkeleri/para birimlerini otomatik olarak algılar, saklanan yöntem belirteçleri.

Yerel yöntemler: banka düğmeleri, e-cüzdanlar, Apple/Google Pay.

Şeffaflık: komisyonlar/ETA sonuçları, operasyon durumu, anlaşılabilir hatalar.

Erişilebilirlik: büyük öğeler, kontrast, ekran okuyucular, çok dillilik.

13) DR/BCP ve Operasyon Güvenliği

Ödeme günlüklerinin çoğaltılması, şifreli yedeklemeler, üç aylık DR alıştırmaları.

RPO'lar/RTO'lar, PSP arızası durumunda "ertelenmiş" ödemelerin akışlarını belgelemektedir.

Kasada WAF/bot yönetimi, ancak PSP yönlendirmeleri/SDK'lar için istisnalar.

14) Sık yapılan hatalar

Son webhook'a kadar denge değişir - çiftler/senkronizasyon dışı.

No 'Idempotency-Key' - Bir ağ hatası yeniden denemesi ikinci bir işlem oluşturur.

Webhook imzasının zayıf doğrulanması - durum değişikliği.

PSP ile otomatik doğrulama eksikliği - "sessiz tutarsızlıklar".

"Her şey için'bir PSP - bozulma sırasında kesinti ve dönüşüm kaybı.

3DS/address alanların "gösteri için" doğrulanması - ters ibrazların büyümesi.

15) Uygulama kontrol listesi (kaydet)

Çoklu PSP yönlendirici, kalite kuralları, yük devretme
Her katmanda idempotency ('txn _ id', 'Idempotency-Key')
Webhooks: HMAC, anti-replay, teslimat günlükleri, veri tekilleştirme
Tokenization/hosted fields, PCI DSS kapsam azaltma
3DS2/SCA, PSD2/Open Bankacılık mevcut olduğunda
Ödeme öncesi ve sonrası antifraud/AML, adım KYC
PSP raporları otomatik mutabakat, uyumsuzluk analizi
Gözlemlenebilirlik: depozito/çıkış p95, 3DS arıza oranı, çalışma süresi PSP
DR planı, ertelenmiş ödemeler, günlük yedeklemeleri
UX döşemeleri: yerel yöntemler, şeffaf ETA/komisyonlar, kullanılabilirlik

İyi bir ödeme entegrasyonu "SDK'yı bağlamak'değil, istikrarlı bir kontur oluşturmaktır: çoklu PSP yönlendirmesi, sıkı idempotency, imzalı webhook'lar, sahtekarlık önleme/AML, otomatik doğrulama ve gözlemlenebilirlik. Bu yığın dönüşümü artırır, geri çekilmeyi hızlandırır, ters ibraz risklerini azaltır ve platformu oyuncular, ortaklar ve düzenleyiciler için öngörülebilir hale getirir.