Jak działa integracja systemów płatniczych

Płatności są „aortą” kasyna online. Konwersja na pierwszy depozyt, stopa wypłaty, udział obciążeń zwrotnych, obciążenie pomocnicze, a nawet reputacja regulatora zależy od tego, jak działa integracja z dostawcami płatności (PSP). Poniżej znajduje się praktyczna mapa: jakie elementy są potrzebne, jak płynie żądanie, gdzie umieścić ochronę i co liczyć.

1) Architektura pętli płatniczej

Główne jednostki:

Realizacja transakcji UI-Select method/currency/amount, 3DS/SCA, statusy, błędy.
Brama: trasa do PSP zgodnie z zasadami (kraj, waluta, ryzyko, koszt).
Portfel (PAM/Wallet): rachunkowość bilansowa, limity RG, transakcje „debetowe/kredytowe”.
Antifraud/AML: operacja punktacji przed i po autoryzacji.
Webhooks (Callbacks): potwierdzenie ostatecznych statusów.
Rozliczenie/pojednanie: codzienny zbieg pieniędzy w PSP i w portfelu.
Przechowywanie tokenów: karty/portfele za pomocą tokenizacji PSP, brak „surowych” PANÓW.

Routing do wielu dostawców usług płatniczych:

Kraj/Bank/Waluta/Reguły limitu, Linie A/B, Automatyczna awaria przy degradacji.

2) Przepływy „depozytu” i „wycofania” (programy)

Depozyt (karta/portfel/bankowość):

1. "POST/payments/init' → stworzyć zamiar (kwota, waluta, metoda).

2. Przekierowanie/SDK → 3DS/SCA/biometrics.

3. PSP zwraca status wstępny (autoryzowany/oczekujący/nieudany).

4. Webhook PSP → stan końcowy (przechwycony/nieudany).

5. „portfel/kredyt” według ostatecznych + rekordowych limitów RG/historii.

Wniosek:

1. "POST/payouts/init' → sprawdzenie wagi/limitów/ryzyka.

2. Inicjowanie wypłaty w PSP (najlepiej na tej samej trasie co depozyt).

3. Webhook PSP → sukces/nieudany.

4. 'portfel/debet' na sukces, niepowodzenie spowodować dziennik, powiadomienie gracza.

3) Idempotencja i łączność pieniędzy

Każde połączenie jest z 'Idempotence-Key' i unikalnym 'txn _ id'.

Wpłaty/wnioski zmieniają saldo tylko raz - zgodnie z końcowym hakiem.

Każde zapytanie wielokrotne zwraca ten sam 'txn _ id' i status.

W połączeniu z grami: 'round _ id', 'debit _ txn _ id'/' credit _ txn _ id'.

4) Bezpieczeństwo i zgodność

TLS 1. 2+/1. 3, HSTS; haki internetowe z podpisem HMAC i anty-replay („timestamp”, nonce).

Tokenizacja kart w PSP; Zmniejszenie zakresu PCI DSS (pola/strony hostowane).

Karta SCA/3DS2, PSD2/Open Bankowość płatna po banku.

RODO: minimalizacja PII, zatrzymywanie, procesy DSR; dziennik dostępu do profilu.

mTLS/IP allow-list dla połączeń z PSP, segregacja pętli płatniczej.

5) Antifraud i AML (przed i po płatności)

Zasady pre-auth: geo/ASN, urządzenie, prędkość, zachowanie, przejście.

Wynik ML/wykres: karty ogólne/portfele/urządzenia, wielokrotne obciążenie zwrotne.

Monitorowanie po auth: anulowanie, zwroty, szybkie wyjście.

Scenariusze AML: progi, strukturyzacja, nietypowe trasy, sprawozdania STR/SAR.

Krok-up KYC: przy średnim/wysokim ryzyku przed wyjściem.

6) Haki internetowe: niezawodna dostawa

Podpis HMAC, walidacja "timestamp" i deduplikacja "event _ id'.

Odwrót po stronie PSP jest idempotentny.

Dzienniki dostawy (sukces/niepowodzenie), kolejka martwej litery i ręczne „powtórzenie”.

Hak nie zmienia salda, chyba że kwota/identyfikatory pasują.

7) Błędy i terminy: projekt odpowiedzi

Kody: „402” (wymagana płatność), „409” (konflikt idempotentny), „422” (walidacja), „429” (ograniczenie stawki), „5xx” (incydent).

Organy błędów: 'error', 'message', 'trace _ id',' details {...} '- help support i alerts.

Graceful retry na kliencie (wykładnicze backoff), wyraźne wskazówki w interfejsie użytkownika.

8) Wiele routingu PSP i awarii

Zasady jakości: autoryzacje p95, konwersja, udział plików 3DS, koszt.

Inteligentny router: jeśli metryka ulegnie pogorszeniu, przełączyć ruch na alternatywę.

Lepka droga do sesji/banku dla stabilności 3DS.

Plan degradacji: wyłączenie „ciężkich” metod, pozostawienie szybko (P2P/Pay-by-Bank), kolejka wyjściowa.

9) Pojednanie

Codzienne przesyłanie PSP i automatycznej weryfikacji z portfelem: dopasowywanie kwot, prowizje, zwroty.

Niedopasowanie → sprawy do dochodzenia.

Oddzielne raporty dotyczące obciążenia zwrotnego/zwrotu/opłat, obliczanie prawdziwego marginesu według metod.

10) Metryki do zachowania ostrości

Konwersja depozytów metodą/bank/kraj/urządzenie.

Czas złożenia/wyjścia (p50/p95).

Udział 3DS-files, anulowania, zwroty, stawka obciążenia zwrotnego.

Udział recenzji ręcznych i TTV KYC.

Uptime PSP i natywny poziom błędu na trasie.

Koszt na sukces i ROI metodą.

11) Przykład minimalnego API (skróconego)

Utwórz zamiar wpłaty

„POST/v1/płatności/”

json
{
"kwota":" 50. 00”, „waluta”:” EUR”, „metoda „:” karta”, „return_url":"https://app. przykład. com/checkout/return", "idempotency_key":"b6a1-...," "meta ": {"kraj ": "FI"," urządzenie":" ios"}
}

Odpowiedź

json
{"payment _ id':" pay _ 123 "," status ":" oczekujący "," redirect _ url': "https ://psp. przykład/3ds/"..}

Status haka internetowego

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

json
{
"event_id":"evt_789," "payment_id":"pay_123," "status ": "schwytany", "kwota":" 50. 00", "waluta":" EUR", "znacznik czasu":" 2025-10-17T09: 41: 00Z"
}

Zapisz (w ramach platformy)

„POST/v1/portfel/kredyt”

json
{"payment _ id':" pay _ 123 "," txn _ id': "txn _ 555", "kwota": "50. 00 ", "idempotency _ key":" b6a1- "..}

12) Dostępność i realizacja transakcji UX

Minimalne kroki: automatyczne wykrywanie krajów/walut, przechowywane żetony metody.

Metody lokalne: przyciski bankowe, e-portfele, Apple/Google Pay.

Przejrzystość: wnioski komisji/ETA, status operacji, zrozumiałe błędy.

Dostępność: duże elementy, kontrast, czytniki ekranu, wielojęzyczność.

13) DR/BCP i bezpieczeństwo operacji

Replikacja dzienników płatności, zaszyfrowane kopie zapasowe, ćwiczenia kwartalne DR.

RPO/RTO są dokumentowane, przepływy płatności „odroczonych” w przypadku awarii PSP.

Zarządzanie WAF/bot przy realizacji transakcji, ale wyjątki dla przekierowań PSP/SDK.

14) Częste błędy

Równowaga zmienia się aż do końca webhook → podwaja/wychodzi z synchronizacji.

Brak 'Idempotence-Key' → Ponowne próbowanie awarii sieci tworzy drugą operację.

Słaba weryfikacja podpisu webhooka → substytucja statusu.

Brak automatycznej weryfikacji z PSP → „ciche rozbieżności”.

Jeden PSP „za wszystko” → przestoje i utrata konwersji podczas degradacji.

Walidacja pól 3DS/address „na pokaz” → wzrost obciążeń zwrotnych.

15) Lista kontrolna wdrażania (zapisz)

Multi-PSP router, zasady jakości, awaria
Idempotencja na każdej warstwie ('txn _ id',' Idempotency-Key ')
Haki internetowe: HMAC, anty-replay, logi dostawy, deduplication
Pola tokenizacji/hostingu, zmniejszenie zakresu PCI DSS
3DS2/SCA, PSD2/Open Bankowość, jeśli jest dostępna
Antifraud/AML przed i po dokonaniu płatności, step-up KYC
PSP raporty auto-pojednanie, analiza niezgodności
Obserwability: deposit/output p95, 3DS failure-rate, uptime PSP
Plan DR, odroczone płatności, kopie zapasowe dziennika
Rachunki UX: metody lokalne, przejrzyste ETA/prowizje, dostępność

Dobra integracja płatności nie polega na „podłączeniu SDK”, ale na budowaniu stabilnego konturu: multi-PSP routing, ścisła idempotencja, podpisane haki internetowe, przeciwdziałanie oszustwom/AML, automatyczna weryfikacja i obserwowalność. Ten stos zwiększa konwersję, przyspiesza wycofywanie, zmniejsza ryzyko obciążenia zwrotnego i sprawia, że platforma jest przewidywalna dla graczy, partnerów i regulatorów.