Jak działa interfejs API do łączenia gier na żywo z platformą

1) Wspólna architektura i role komponentów

Operator Platform (Casino Platform): konta, portfel, silnik bonusowy, limity, KYC/AML, dziennik transakcji.

Dostawca gier na żywo (Studio/Dostawca): studia, dealerzy, strumienie wideo (WebRTC/Low-Latency HLS), rundy serwerów gier.

Agregator (czasami): pojedynczy interfejs API dla kilkudziesięciu dostawców, ujednolicenie walut/limitów/zdarzeń.

Frontend klienta: klient internetowy/mobilny z interfejsem użytkownika zakładów, odtwarzacz wideo, czat, lokalne prompty.

Usługi pomocnicze: Ryzyko/Przeciwdziałanie oszustwom, logowanie, analityka, kolejki wiadomości (Kafka/RabbitMQ), monitorowanie.

Typowa topologia: → klient (JWT) → → platforma (serwer-serwer) → dostawca, równolegle, klient otrzymuje strumień wideo z puli serwerów CDN/media.

2) Cykl życia gracza i sesje

2. 1. Login i „token gry”

1. Gracz loguje się na platformę.

2. Platforma dzwoni od dostawcy (S2S), przesyła 'player _ id',' currency ',' country ',' bet _ limits ', flagi odpowiedzialnej gry.

3. Dostawca zwraca jednorazowy game_token i launch_url.

4. Klient otwiera 'start _ url' w iframe/nowej karcie, dodając' game _ token '(lub dostaje 302 do ostatecznego adresu URL gry).

Przykład żądania S2S:

http
Sesje POST/api/v1/
Typ treści: aplikacja/json
Autoryzacja: Nosiciel <platform_api_key>

{
"player_id": "u-918273", "session_id": "sess-5f3b2", "waluta": "EUR", "kraj": "DE", "lang": "de", "bet_limits": {"min": 0. 5, "max": 2000}, "responsible_gaming": {"self _ excluded": false, "deposit_limit_left": 150} ", callback_urls": {
"balance": "https ://platform. przykład. com/wallet/balance”, „debit”: „https ://platform. przykład. com/wallet/debit”, „credit”: „https ://platform. przykład. com/wallet/credit”, „rollback „: „https ://platform. przykład. com/portfel/rollback”, „wydarzenia”: „https ://platform. przykład. com/gra/wydarzenia"
}
}

Odpowiedź dostawcy:

json
{
"game_token": "gtkn_7f0...e2a," "launch_url": "https ://live. dostawca. com/launch/ruletka”, „expires_in": 900
}

2. 2. Uwierzytelnianie z przodu

Gra ładuje, zatwierdza 'game _ token' przez jego backend.

WebSocket jest instalowany na serwerze gier dla zakładów/zdarzeń.

Strumień wideo działa przez WebRTC (niskie opóźnienie 0. 5-2 s) lub LL-HLS (2-5 s).

3) Pieniądze i zakłady: API portfel i idempotencja

3. 1. Saldo i obciążenie/kredyt

Dostawca nie przechowuje „pieniądze” gracza - nazywa API platformy portfela:

'GET/portfel/balance? player_id' → prąd dostępny.
'POST/portfel/debit' → odpisać zakład.
„POST/portfel/kredyt” → wygrane/zwroty kredytu.
'POST/portfel/rollback' → cofnięcie transakcji po anulowaniu rundy.

Ważne: wszystkie transakcje pieniężne to 'transaction _ id'/' round _ id'. Powtarzanie tego samego zapytania nie zmienia wyniku.

Przykład obciążenia (stopa):

http
POST/portfel/debet
Idempotencja-Key: trx-7a2df-001
Typ treści: aplikacja/json

{
"player_id": "u-918273", "round_id": "r-2025-10-18-12:30:15Z-001," "transaction_id": "trx-7a2df-001", "kwota": 25. 00, "waluta": "EUR", "bet_type" ":" roulette_straight, "" meta ": {" table _ id':" ru-11", "selection":" 17", "kursy": 35}
}

3. 2. Terminy i statusy zakładów

WINDOW_OPEN → WINDOW_CLOSING → WINDOW_CLOSED. Po 'WINDOW _ CLOSED' dostawca zabrania nowych debetów.

Późne oferty są odrzucane z kodem 'LATE _ BET'.

Jeśli połączenie jest zerwane, klient może ponownie zakład - serwer musi być w stanie odróżnić duplikat przez Idempotency-Key.

Statusy transakcji: „OCZEKUJĄCE”, „SETTLED”, „ROLLED _ BACK”, „ODRZUCONE”.

4) Okrągłe wydarzenia: Model i zamówienie

4. 1. Schemat zdarzeń WebSocket

"teren. started '→ comes' round _ id', bet timer.

'bet. zaakceptowane/odrzucone "→ potwierdzenie dla każdej oferty.

"teren. zamknięte "→ zakłady nie są już akceptowane.

"teren. wynik "→ wynik (ruletka/karta/sektor kości).

„wypłata”. created '→ kwota wygrana przez gracza.

"teren. settled '→ status końcowy, checksum.

Przykład zdarzenia wynikowego:

json
{
"typ": "okrągły. wynik", "round_id": "r-2025-10-18-12:30:15Z-001," "table_id": "ru-11", "ładunek użytkowy": {
"ruletka": {"liczba": 17, "kolor": "czarny"}, "hash": "sha256: 8a7b... d1c'," video_ts": "2025-10-18T12:30:23. 450Z"
}
}

4. 2. Spójność i kontrolki

Każde wydarzenie jest zaopatrzone w „następne” i „podpis” (mTLS + podpis organu wnioskującego).

Dla uzgadniania podano 'payout _ checksum' - suma wszystkich 'round _ id' kredytów musi się zbiegać.

5) Strumień wideo i opóźnienia

WebRTC na zakłady ręczne na żywo (blackjack/baccarat/ruletka) - ścisły budżet opóźnienia <2 s do klienta.

LL-HLS/DASH dla widzów/skali, umożliwia 2-5 c.

Synchronizacja czasu: NTP/chrony, w ładunku - 'video _ ts' dla powtórzeń i sporów.

Folback: gdy WebRTC degraduje, automatyczne przełączanie na LL-HLS → z blokowaniem późnych zakładów.

6) Błędy, Retras, Timeouts

Zasady ogólne:

Wszystkie połączenia S2S z czasem 800-1500 ms, przekłada się z wykładniczą przerwą i Jitter, ale bez ponownego obciążania pieniędzy (idempotencja).

Kody błędów portfela:

„NIEWYSTARCZAJĄCE _ FUNDUSZE”, „LIMIT _ EXCEEDED”, „ACCOUNT _ LOCKED”, „DUPLIKAT _ TRANSACTION”, „LATE _ BET”, „CURRENCY _ MISMATCH”.

Format błędu:

json
{
"błąd": "INSUFFICIENT_FUNDS," "komunikat": "Równowaga 18. 00 <wymagane 25. 00”, „transaction_id": „trx-7a2df-001”
}

7) Bonusy, freespins, ubezpieczenia

Równolegle z portfelem „money” może istnieć saldo bonusowe: ładunek wskazuje źródło odpisu: CASH	BONUS ".
W przypadku gier na żywo ubezpieczenie/zakład boczny nie jest rzadkością (na przykład w blackjacku) - są to osobne transakcje z własnymi limitami i współczynnikami.
Zasady zaokrąglania: bankowość (w połowie do parzystego) lub na korzyść gracza/operatora - muszą być ustalone w konfiguracji integracji.

8) Odpowiedzialna zabawa i ograniczenia

Flagi sesji: 'self _ excluded', 'cooldown _ until', 'loss _ limit _ left', 'time _ limit _ left'.

Dostawca może zażądać 'validate _ limits' przed każdym debetem.

Platforma może zainicjować force_close_session: gracz jest wykluczony/przekroczony limit → dostawca zamyka okno zakładów i zwraca w zakładach nieplanowanych.

9) Bezpieczeństwo i zgodność

mTLS dla S2S, HSTS, ścisła lista IP.

JWT/JWS z krótkim TTL dla żetonów przednich, weryfikacja publiczności/emitenta.

Podpis haków internetowych dostawcy (HMAC-SHA256 nad ciałem).

Dzienniki aktywności dealera, powtórki okrągłe, audyt niezmienny (magazynowanie WORM).

Przechowywanie danych osobowych - minimalizacja PII, tokenizacja 'player _ id', okresy retencji jurysdykcji (RODO i analogi).

Blokowanie geograficzne i zakazy przez jurysdykcję na poziomie, na którym odbywa się sesja.

10) Pojednanie i finanse

10. 1. Raporty godzinowe/dzienne

Dostawca podaje raport na temat 'round _ id → total_bets, total_wins, opłaty'. Platforma łączy w sobie:

Debety = Zakłady, Kredyty = • Wygrywa + zwraca, Delta = GGR (w tym bonusy/jackpoty/prowizje).

Format raportu:

json
{
„data”: „2025-10-18”, „waluta”: „EUR”, „tabele”: [{
"table_id": "ru-11", "rundy": 1260 ", total_bets": "45230. 00", "total_payouts": "43012. 50", "jackpot_contrib": "302. 00", "provider_fee": "2. 5%"
}]
}

10. 2. Scenariusze rollback

Video/Storyboard → runda nie powiodła się. anulowane: dostawca wysyła 'rollback' do wszystkich zakładów w rundzie.

Podwójne przetwarzanie debetowe złapane na platformie → „DUPLIKAT _ TRANSACTION” i 200 OK z tym samym wynikiem.

11) Czat, moderowanie i imprezy UI

Wydarzenia czatu przechodzą przez oddzielny kanał (WebSocket # 2) z filtrami stopu.

Ogłoszenia systemowe (zakłady zamknięte, lista zwycięzców) - tylko z zaufanego źródła dostawcy, podpisane/oznaczone terminem.

12) Testowanie i certyfikacja

Dostawca piaskownicy: stałe wyniki, zdolność do wymuszania 'ground. wynik ".

Kontur QA: tabela testowa z okrojonymi oknami bukmacherskimi (5-8 c) i przyspieszonym przepływem.

Obciążenie: symulacja 5-10 tysięcy graczy jednocześnie, szczytowe debety na sekundę (TPS) ≥ zaplanowane × 1. 5.

Certyfikacja integracji: listy kontrolne dotyczące idempotencji, walut, zaokrąglania, przerw w przetwarzaniu, zgodności z limitami i samodzielnego wykluczenia.

13) Metryka i SLO

Te: mediana/95p opóźnienia dla 'debit/credit', WebSocket round-trip, błąd synchronizacji czasu, drop-rate WebRTC.

Бробка: stawka akceptacji, stawka late-bet, stawka sporna, stawka obciążenia zwrotnego, czas trwania sesji, retencja, ARPU/LTV.

Przykłady SLO:

99. 5% 'debit' ≤ 1. 2 s, 99. 9% dostawa 'teren. wynik '≤ 300 ms po utrwaleniu, opóźnienie wideo ≤ 2. 5 s dla 95p WebRTC.

14) Wielokrotność, podatki, lokalizacja

Konwersja - poza dostawcą: gra działa ściśle w walucie sesji.

Podatki/odliczenia - po stronie platformy z „kredytem” (pole „u źródła”).

Lokalizacja: 'lang', format numeru/waluty, strefa czasowa dla timerów i raportów.

15) Warianty integracji

1. Bezpośredni dostawca: maksymalna kontrola i funkcja, ale odrębne umowy/certyfikaty.

2. Poprzez agregator: szybki zasięg przez dostawców, ujednolicone systemy, czasami mniej elastyczności.

3. Hybryda: górne stoły bezpośrednio, reszta przez agregator.

16) Mini-specyfikacja (razem)

16. 1. WebSocket przychodzący (klient do dostawcy)

json
{"typ ":" zakład. miejsce", "zakład": {
„kwota”: 25, „wybór”:” 17”, „table_id":"ru-11”
}, „idempotency_key":"c3a2-...-001”}

16. 2. WebSocket wyjście (dostawca do klienta)

json
{"typ ":" zakład. przyjęte", "bet_id":"b-8821," "seq ": 12031}
{"typ ":" okrągły. zamknięte", "round_id":"r-...001," "seq ": 12050}
{"typ ":" okrągły. wynik", "wynik ": {"liczba ": 17," kolor":" czarny"}, "seq ": 12070}
{"typ ":" wypłata. utworzony", "kwota": 875, "waluta":" EUR", "seq ": 12075}

16. 3. S2S portfela (dostawca platformy)

„POST/portfel/debet” (idempotent)

„POST/portfel/kredyt” (idempotent)
„POST/portfel/rollback” (idempotent)

Podpis HMAC, „Timestamp”, „Nonce”, ochrona powtórna (TTL ≤ 60 c).

17) Przypadki krawędzi i jak je zamknąć

Odłączenie gracza: zakład wysłany, brak potwierdzenia → powtórzyć z tym samym 'Idempotence-Key'; serwer zareaguje tym samym statusem.

Zmiana dealera/pokładu w rundzie: automatyczne anulowanie i pełny 'rollback'.

Niedopasowanie waluty: 'CURRENCY _ MISMATCH' + dziennik zdarzeń; gra jest zablokowana do czasu ponownego wydania sesji.

Samodzielne wyłączenie w czasie gry: natychmiastowe 'force _ close _ session', powrót nieplanowany.

Zmiana jakości wideo: tylko klient, bez wpływu na zegary/zakłady.

WebSocket re-handshake: bez utraty zamówienia - kolejka wydarzeń z 'seq', „nadrabianie zaległości” przegapił.

18) Lista kontrolna produkcji

Bezpieczeństwo

Certyfikat mTLS + pinning, lista IP.
Podpisz wszystkie haki i sprawdź 'Timestamp '/' Nonce'.
Mini-PII: tylko 'player _ id' (tokenizowany).

Niezawodność

Tożsamość wszystkich transakcji pieniężnych.
Powtórki okrągłe i niezmienne audyty.
WebRTC → LL-HLS auto-folback.

Produkt

Limity/odpowiedzialne zagranie stosowane w czasie rzeczywistym.
Native prompts w czasie zakładu.
Deski rozdzielcze SLO + wpisy 24/7.

Integracja gry na żywo API to pakiet nisko opóźnionych strumieni, autobusu imprezowego i idempotentnego portfela z surowymi wymaganiami dotyczącymi kolejności wiadomości, harmonogramów i bezpieczeństwa. Udana realizacja opiera się na: ścisłym cyklu życia zakładów i rund, możliwej do zweryfikowania spójności (pojednanie), ochronie danych i limitach odpowiedzialnej zabawy - i zamienia „piękną transmisję” w wiarygodny, certyfikowany produkt finansowy.