Jak działa integracja API między studiami a platformami

Integracja studia (dostawcy gier) z platformą/agregatorem to łańcuch synchronicznych i asynchronicznych połączeń wokół sesji, portfela, wyniku spinu i telemetrii zdarzeń. Poniżej znajduje się krótka, ale praktyczna mapa, jak wszystko łączy się bez bólu dla deweloperów i zgodności.

1) Architektura w dłoni

Aktorzy:

Studio RGS (Remote Game Server) - logika gry, RNG, bonusy, jackpoty.
Platforma/Agregator - routing, rozliczenie, promocja, zgodność.
Operator - portfel gracza, KYC/RG, prezentacja.
Klient - web/mobile game container (iframe/webview/native).

Główne autobusy:

Synchronizacja API: sesje, portfel, wynik.
Async/Event Bus: spin events, bonusy, jackpoty, RG, błędy techniczne.
Metadane/katalog: gry, buduje rynek, profile RTP, lokalizacje.

2) Protokoły i podstawowe rozwiązania

Transport: HTTPS/JSON (czasami gRPC dla Event Bus/Wallet).

Wersioning: 'Accept: application/vnd. rgs. v1 + json 'lub '/v1/...'; degradacja kompatybilności - tylko poprzez nowe wersje.

Identyfikacja: 'game _ id',' build _ hash ',' operator _ id', 'session _ id',' round _ id', 'spin _ id'.

Czas: ściśle UTC, ISO-8601 milisekundami.

Waluty: ISO-4217 + dokładność (jednostki niewielkie). FX - strona operatora/agregatora.

3) Uwierzytelnianie i autoryzacja

Server-to-server: OAuth2 Client Credentials ила HMAC-бодкиса („X-Signature: HMAC_SHA256 (payload, shared_key)”).

Sesja gracza: krótkotrwała JWT (platforma znaków) c 'sub', 'geo', 'rg _ flags',' exp ',' aud = studio '.

Listy dostępu: IP umożliwiają + mTLS dla pętli produkcyjnych.

4) Modele portfela: przelew debetowy/kredytowy vs

A) Debet/kredyt (w locie):

1. Platforma wywołuje RGS: 'SpinRequest (stake)' → RGS oblicza wynik → zwraca 'win'.

2. Równolegle platforma dokonuje „debetu (stawki)” i „kredytu (wygranej)” w miejscu operatora.

Plusy: Prosta księgowość. Minusy: więcej połączeń sieciowych, ścisłe wymagania dotyczące idempotencji.

B) Przeniesienie (saldo sesji):

1. Na początku sesji platforma wykonuje „Transfer In (kwota)” w systemie RGS.

2. Podczas spinów RGS sam równoważy sesję; po zakończeniu - „Przeniesienie (pozostałe)”.

Plusy: Mniej czatów portfelowych. Minusy: rozliczanie „pieniędzy po stronie RGS”, dodatkowe ryzyko i pojednanie.

Zalecenia:

W przypadku automatów częściej stosuje się klucze debetowe/kredytowe z idempotentem.

Na darmowych spinach i turniejach wygodnie jest mieć oddzielne typy zakładu 'spin _ type = free	promo '.

5) Idempotencja i spójność

Każdy krok pieniężny musi mieć unikalny 'idempotence _ key' (na przykład 'round _ id' lub' spin _ id').

Duplikaty ('HTTP 409/425') zwracają ten sam wynik, a nie „błąd już wykonany”.

Dokładnie raz jest trudne do osiągnięcia, więc budujemy przynajmniej raz + idempotencję.

Idempotencję rozszerza się na: 'debit', 'credit', 'jackpot _ contribution', 'bonus _ award'.

6) Kluczowe programy zapytań (skrócone)

6. 1. Początek sesji

json
POST/rgs/v1/sesje
{
„session_id":” s- „...,” operator_id": „op-”..., „player_id":” p- „...,” game_id": „g-BookOf”..., „build_hash":” sha256: „...,” jwt': „eyJhbGci”..., „geo”: „DE”, „waluta”: „EUR”, „rg_flags": {” self _ excluded „: false”, time_limit_min": 60}
}

6. 2. Spin (debet/kredyt)

json
POST/rgs/v1/spins
{
"spin_id": "spin-"..., "round_id": "rnd-"..., "session_id": "s-"..., "stake": {"amount": 1. 00, „waluta”: „EUR”} „, spin_type": „gotówka”, „idempotency_key": „spin-”...
}

Odpowiedź:

json
{
"spin_id": "spin-"..., "wynik": {
"wygraj': {" kwota ": 3. 40, „waluta”: „EUR”}, „funkcje”: [{„typ „: „bonus _ trigger „, „nazwa”:” BlackSpins”,” count”: 10}], „symbole”: „nieprzezroczysty lub pominięty”
} ", rgs_txns": [
{„typ „: „jackpot _ contribution”,” kwota”: 0. 01}
], "telemetry_ref": "evt-"..
}

6. 3. Autobus imprezowy

json
POST/rgs/v1/events/batch
{
„wydarzenia”: [
{
„typ”: „spin _ finished”, „ts':” 2025-10-20T11: 22:33. 123Z," "spin_id":"spin-...," "round_id":"rnd-...," "kołek": 1. 00, "wygraj': 3. 40, „waluta”:” EUR”, „game_id":"g-...,""build_hash":"sha256:...,” „player_id":"p-...,""operator_id":"op-...,” „spin_type":"cash”
}
]
}

7) Wersioning buduje i buduje rynek

„build _ hash” (SHA-256) - wymagane w każdym zdarzeniu.

Global vs Market build: język, ostrzeżenia, limity stawki, profil RTP.

Platforma potwierdza: „jest obecnie odtwarzana budowa, która odpowiada certyfikatowi danego kraju”.

Macierz: 'gra _ id × kraj × rtp_profile × build_hash'.

8) RNG, matematyka i powtórka

RNG żyje na RGS; Logika biznesu nie zmienia szans na muchę.

W przypadku medycyny sądowej: „nasiona/nonce” na rundę/spin + wersję mechaniczną.

Powtórka: poprzez 'spin _ id'/' seed', RGS odtwarza wynik i daje ścieżkę audytu.

9) Odpowiedzialne gry (RG) i haki zgodności

Haki czasu/limitów: 'session _ time _ ms', 'reminders', timeouts; 'rg _ event' w Event Bus.

Samodzielne wyłączenie/blok: z flagą - natychmiastowe '403 RG_BLOCKED'.

UI niezmienne: platforma sprawdza, czy klient pokazuje ostrzeżenia/tagi wiekowe z budowy rynku.

10) Błędy, przekaźniki i SLA

Kody: „400” (walidacja), „401/403” (uwierzytelnianie/RG), „409” (konflikt idempotencji), „422” (błąd biznesowy), „429” (limit stawki), „5xx” (tymczasowy).

Polityka retray: wykładnicza, z kluczem idempotentnym i deduplikacją w odbiorniku.

Dostępność SLA ≥ 99 API. 9%, p95 opóźnienie dla „spin” ≤ 200 -300 ms (regionalny), Event Bus - near-real-time <60 s.

11) Obserwowalność i audyt

Dzienniki: nieokreślone dzienniki serwera z korelacją 'trace _ id'.

Metryki: opóźnienie p95/p99, szybkość błędów metodami, odchylenia częstotliwości RTP/bonusowych, odsetek „spinów elastycznych”.

Alerty: przez SLA, przez anomalie matematyczne, przez wzrost awarii portfela.

Audyt: magazyn WORM do zakładów/zdarzeń wyników; eksport na żądanie.

12) Bezpieczeństwo

mTLS + TLS 1. 2 +, HSTS, ścisły CORS na ładowarce klienta.

Obrót klucza, krótkie żetony TTL, sprawdzanie JTI/nonce.

Anty-manipulator dla klienta: podpisy aktywów, kontrola integralności, ochrona debuggera.

Sekrety - tylko w tajnym menedżerze; Nie ma klucza w konfiguracji gry.

13) Środowiska badawcze i certyfikacja

Piaskownica: fikcyjne portfele, deterministyczny RNG (stałe nasiona), automatyczna awaria scenariuszy RG.

Posting: kopia prod-infra bez prawdziwych pieniędzy.

Pakiet dla laboratoriów: GDD/matematyka, dokumentacja RNG, schematy dzienników, powtarzalna budowa i hashes.

14) Promocje i jackpoty w API

Free Spins: transfer pakietów: 'grant _ free _ spins (count, bet_size, rtp_profile?)'; wydarzenia są spędzane w systemie RGS i rejestrowane.

Turnieje: atrybut 'spin _ type = turniej' + poszczególne agregaty w Event Bus.

Jackpoty: „jackpot _ contribution” i „jackpot _ win” jako odrębne transakcje; spójność poprzez idempotencję i „podpisane” wydarzenia.

15) Sprawozdawczość i rozliczenia

Блока ва рукой: 'spins _ total', 'eligible _ spins', 'turnover', 'ggr', 'netwin', 'jackpot _,' bonus _ cost ',' royalty _ due '.

Opłata za obrót/spin: rachunek według 'kwalifikujących się _ spinów' lub 'stawki stake ×'.

Rev-share: z „NetWin” po posiadaniu „wodospadu”; kwartalna prawda dla FX/wyjątków.

16) Typowe sekwencje (wykresy słów)

Spin (debet/kredyt):

Klient → Platforma: StartRound → Platforma → RGS: Spin → RGS → Platforma: Wynik → Platforma → Portfel: Debet → Platforma → Portfel: Kredyt → Platforma → Klient: Wynik → Platforma → spin_finished.

Darmowe spiny:

Platforma → RGS: Na RGS → Klient: Start → RGS: Zużyj/Zaloguj każdy → Na autobusie: spin_finished (spin_type=free).

17) Zarządzanie zmianami i interoperacyjność

Kontrakt pierwszy: OpenAPI/Protobuf jest jednym źródłem schematów.

SemVer: dodać tylko pola; delete/modify - in/v2.

Flagi funkcji - Włącz opcje (Bonus Buy/Ante) tylko za pomocą certyfikowanych profili.

Odrzucenie: ogłosić → okres karencji → zamknięcie w nieaktywnych regionach.

18) Listy kontrolne

Studio → Platforma

Specyfikacje OpenAPI/gRPC i ładunki próbkowe.
IDempotency „spin/debit/credit/jackpot”.
„build _ hash” i rejestr buduje rynek.
Repliki RNG i dziennik audytu.
Haczyki i błędy RG '403 RG_BLOCKED'.
Piaskownica z mocowaniem nasion, portfel testowy i auto skrypty.

Platforma → Studio

Podpis JWT z krótkim TTL, permlist IP, mTLS.
Podmiot zatwierdzający buduje rynkowe i certyfikaty.
Event Bus and dashboards (latency/error/RTP drift).
Kwoty i limity stawek z uczciwymi informacjami zwrotnymi „429-Retry-After”.
SLA/Incydenty/Linki 24 × 7.

19) Plan uruchomienia 30-60-90

0-30 dni

Uzgodnić umowy API i programy imprez, wybrać model portfela.

Podnieść piaskownicę: stałe nasiona RNG, portfel testowy, autotest idempotencji.

Rejestr 'build _ hash' i rynek macierzy pierwotnej buduje.

31-60 dni

Integracja portfela i spinu; enable Event Bus i deski rozdzielcze.

Testy obciążenia (p95/p99), retrai/idempotencja, scenariusze chaosu sieciowego.

Zgodność: haki RG, lokalizacje, etykiety wiekowe; Pakiet do laboratorium.

61-90 dni

Pilot dla 1-2 operatorów, A/B dla promocji (darmowe spiny/turnieje).

Wprowadzanie prawdziwego/raportowania, alerty dryfujące RTP/bonus-freq.

Przygotowanie ulepszeń v2: imprezy wsadowe, gRPC dla portfela, geo-routing.

20) Krótkie najczęściej zadawane pytania

Gdzie jest sprawdzony RTP/wersja? Na platformie: 'build _ hash'

Czy RTP można zmienić dynamicznie? Nie, nie jest. Tylko wstępnie certyfikowane profile i tylko przełączanie rynku budować.

Jak rozwiązać „podwójny debet”? Idempotent key + przechowywanie statusu transakcji; redo-Zwraca wynik.

Czy potrzebuję gRPC? Przydatne do portfela/imprez w dużych ilościach; Pozostały resztki dla metadanych/panelu administracyjnego.

Stabilna integracja to kontrakty + idempotencja + obserwowalność. Przejrzyste programy imprez, budowa/kontrola rynku, haki RG i dyscyplina wersji usunąć 90% ryzyka na początku. Dalej - automatyzacja promo i raportowania, twardy SLA i staranny rozwój API bez „łamania” zmian.