Pytanie o to, jakie API zintegrować, pada zwykle za późno i zwykle jest złym pytaniem. Właściwe brzmi inaczej: gdzie przebiega granica między warstwą treści a platformą gamingową i który system czego jest właścicielem.
Jeśli ta odpowiedź jest błędna, lista integracji nie ma znaczenia. Podłączycie właściwe usługi do niewłaściwej architektury.
Krótka odpowiedź. WordPress odpowiada za prezentację, treść i akwizycję. Certyfikowana platforma odpowiada za konto gracza, portfel, sesję gry i rozliczenie zakładu. Liczą się te nieliczne integracje, które leżą na granicy między nimi, i jest ich mniej, niż sugerują listy dostawców.
Gdzie przebiega granica
Trzy warstwy. Praca jest w środkowej.
| Warstwa | Właściciel | Co tam leży |
|---|---|---|
| Prezentacja i treść | WordPress | Landing page’e, SEO, regulaminy promocji, help center, warianty rynkowe, strony afiliacyjne |
| Integracja | Kod dedykowany | Przekazanie sesji, katalog gier, gating jurysdykcyjny, fragmenty spersonalizowane |
| Rdzeń transakcyjny | Platforma (PAM) | Konto gracza, portfel, sesja gry, rozliczenie zakładu, KYC, płatności, ślad audytowy |
Całą architekturę porządkuje jedna zasada. WordPress nigdy nie jest źródłem prawdy dla pieniędzy ani tożsamości. Może wyświetlić saldo. Nie może go przechowywać.
To nie jest ograniczenie platformy. To wynika z tego, czego regulator wymaga od warstwy transakcyjnej: certyfikacji, integralności transakcji i śladu audytowego, który przetrwa kontrolę. Wymogi opisujemy dokładniej w tekście o licencjonowaniu w iGamingu.
Co faktycznie leży w WordPressie
Cztery integracje. Reszta to albo treść, albo cudzy system.
Przekazanie sesji
Najważniejsza i najczęściej problematyczna. Gracz zalogowany na platformie musi zostać rozpoznany na stronie treściowej, a oba systemy muszą uzgodnić, kim jest, bez przechowywania jakichkolwiek danych uwierzytelniających po stronie WordPressa.
Dojrzałe platformy wystawiają endpoint OpenID Connect i wtedy jest to zadanie konfiguracyjne. Mniej dojrzałe wystawiają endpoint z podpisanym tokenem i wtedy jest to zadanie programistyczne. Część nie wystawia niczego, a odpowiedzią na to jest ustalenie sprawy na etapie wyboru dostawcy, nie po wdrożeniu.
WordPress trzyma referencję sesji i zestaw atrybutów do wyświetlenia: segment, rynek, status weryfikacji, informację o samowykluczeniu. Nie trzyma hasła, salda ani niczego, co regulator chciałby zaudytować.
Katalog gier jako metadane
Katalog dzieli się czysto i traktowanie go jako jednej całości to częsty błąd.
Metadane gry to treść. Nazwa, dostawca, miniatura, RTP, zmienność, kategorie, obsługiwane urządzenia, dostępność w danym rynku. To należy do WordPressa, bo to czytają wyszukiwarki, to kuratoruje redakcja i z tego budowane są landing page’e.
Uruchomienie gry to nie treść. Token startowy, sesja i wywołania portfela należą do platformy. WordPress renderuje link. Nie otwiera sesji.
Katalog powinien synchronizować się z API agregatora lub platformy według harmonogramu, a nie być utrzymywany ręcznie. Katalogi prowadzone ręcznie się rozjeżdżają, a rozjazd objawia się graczem klikającym w grę niedostępną na jego rynku.
Gating jurysdykcyjny
Geolokalizacja rozstrzyga, co wolno pokazać odwiedzającemu, i to jest realnie zadanie warstwy prezentacji. Które strony, który regulamin, jakie dane licencji w stopce, jakie logotypy metod płatności, jaki komunikat o odpowiedzialnej grze, które gry w ogóle pojawią się w katalogu.
Samo sprawdzenie lokalizacji może pochodzić od wyspecjalizowanego dostawcy albo z platformy. Niezależnie od tego decyzja o tym, co wyrenderować, należy do warstwy treści i musi być pełnoprawnym elementem logiki szablonów, a nie wtyczką doklejoną na końcu wdrożenia.
Operacje na treści i personalizacja
Regulaminy promocji, zasady bonusów jako publikowany tekst, artykuły help center, strony compliance per rynek. Wszystko to treść, wszystko to WordPress.
Jeden szczegół wart zaprojektowania z góry. Regulator może zapytać, która wersja regulaminu promocji obowiązywała w danym dniu. WordPress może trzymać historię wersji publikowanych. Platforma zapisuje, którą wersję zaakceptował konkretny gracz. Łączy je identyfikator wersji, który trzeba zaprojektować od początku, bo nikt nie dokłada go później bez migracji.
Czego w WordPressie nie ma
Płatności. Portfele graczy. Weryfikacja KYC i AML. Stan sesji gry. Przyjmowanie i rozliczanie zakładów. Sprawdzenia w krajowych rejestrach samowykluczeń, takich jak GAMSTOP, Spelpaus, OASIS czy CRUKS. Ślad audytowy transakcji.
Powodem nie jest to, że WordPressa nie dałoby się technicznie do tego zmusić. Powodem jest to, że powstały w ten sposób system musiałby zostać certyfikowany, zaudytowany i utrzymywany na poziomie, pod który system zarządzania treścią nie jest projektowany. I że certyfikację trzeba by powtarzać dla każdego nowego rynku.
Tam, gdzie widzimy ten błąd, rzadko jest on świadomą decyzją. Zaczyna się od jednego wygodnego skrótu, zwykle od zapisania atrybutu gracza w WordPressie, bo akurat w tym tygodniu API platformy działało wolno.
Pięć sposobów, w jakie te integracje się psują
Z projektów, nie z teorii.
Dane gracza w wp_usermeta. W chwili, w której atrybut gracza zostaje zapisany w WordPressie i jednocześnie istnieje na platformie, macie dwa źródła prawdy. Zgadzają się do momentu, w którym przestają, a rozbieżność wypływa w zgłoszeniu o bonusie, który zniknął.
Cache na stronie pokazującej saldo. Pełne cache’owanie strony i kontekst gracza wykluczają się, dopóki granica nie jest jawna. Fragmenty spersonalizowane muszą ładować się poza cache, po stronie klienta albo przez edge-side includes. To błąd o najgorszych konsekwencjach, bo prowadzi do sytuacji, w której jeden gracz przez moment widzi stan konta innego.
Logika bonusowa zduplikowana w warstwie treści. Reguła promocji zaimplementowana w WordPressie, żeby nie czekać na wydanie platformy, rozjedzie się z regułą platformy w ciągu tygodni. Gracz widzi wtedy jedno, a rozliczany jest według drugiego.
Brak zdefiniowanego zachowania przy niedostępnym API platformy. Każda platforma ma przestoje. Pytanie brzmi, czy strona degraduje się do trybu treściowego z katalogiem z cache i ukrytymi blokami spersonalizowanymi, czy zwraca błąd serwera każdemu odwiedzającemu, łącznie z tymi, którzy chcieli tylko przeczytać recenzję.
Odpytywanie kontekstu gracza przy każdym renderowaniu strony. Endpointy graczy mają limity zapytań, a ruch kampanijny przychodzi skokowo. Szablon odpytujący platformę przy każdym żądaniu wyczerpie limit dokładnie wtedy, gdy to najbardziej kosztuje.
O co zapytać dostawcę platformy
Te pytania decydują o tym, ile pracy integracyjnej kupujecie. Warto je zadać przed podpisaniem umowy, nie po.
Czy platforma wystawia endpoint OpenID Connect do przekazania sesji, czy budujemy wymianę tokenów?
Czy katalog gier jest dostępny przez API i czy niesie informację o dostępności per rynek i per urządzenie?
Jakie są limity zapytań i oczekiwane opóźnienia na endpointach kontekstu gracza?
Kto jest właścicielem silnika reguł bonusowych i czy warstwa treści może odczytać stan bonusu bez powielania logiki?
Czy istnieje sandbox z reprezentatywnym katalogiem i graczami testowymi, czy tylko produkcja?
Czy jest udokumentowany endpoint statusu, na podstawie którego możemy uruchomić kontrolowaną degradację?
Jakie certyfikacje platforma posiada dla każdego z rynków docelowych i czy ograniczają one to, co wolno nam renderować na własnych stronach?
Dostawca, który odpowiada na to jasno, jest dostawcą, pod którego da się zaplanować harmonogram. Dostawca, który nie potrafi, jest ryzykiem, którego jeszcze nie wyceniliście.
FAQ: AI w iGamingu
Czy WordPress może obsługiwać konta graczy?
Nie powinien. Konta graczy, portfele i rozliczanie zakładów leżą w certyfikowanej platformie, bo to jest warstwa, którą audytuje regulator. WordPress trzyma referencję sesji i atrybuty do wyświetlenia.
Czy potrzebujemy do tego architektury headless?
Niekoniecznie. Klasyczna instalacja WordPressa konsumuje API platformy bez problemu. Headless ma sens przy stałych zasobach front-endowych i realnej potrzebie wielokanałowej, a nie jako sposób na rozwiązanie problemu integracyjnego.
Czy możemy pokazywać saldo na stronie treściowej?
Tak, pod warunkiem jawnej granicy cache. Fragment z saldem ładuje się poza pełnym cache strony i czyta z platformy. Nigdy nie jest zapisywany w WordPressie.
Single wallet czy transfer wallet?
To decyzja na poziomie platformy, nie WordPressa. Większość obecnych integracji korzysta z modelu jednego portfela, w branży nazywanego seamless wallet, w którym dostawca gry odpytuje portfel operatora w czasie rzeczywistym. Dla warstwy treści nie ma to znaczenia.
Kto odpowiada za obowiązek transparentności z AI Act w przypadku naszego chatbota?
To zależy od tego, kto jest dostawcą systemu. Jeśli chatbota licencjonujecie, obowiązek leży po stronie dostawcy. Jeśli działa pod Waszą marką, prawdopodobnie po Waszej. Artykuł 50 obowiązuje od 2 sierpnia 2026.
Ile zwykle trwa taka integracja?
Zmienną jest platforma, nie WordPress. Tam, gdzie istnieje endpoint OpenID Connect i udokumentowane API katalogu, praca liczy się w tygodniach. Tam, gdzie ich nie ma, większość wysiłku idzie na zbudowanie tego, co platforma powinna była wystawić.
Podsumowanie
Lista API znaczy mniej niż granica, na której te API leżą. Treść, metadane katalogu, logika jurysdykcyjna i przekazanie sesji należą do WordPressa. Pieniądze, tożsamość i stan gry należą do platformy. Projekty, które trzymają tę granicę, integrują się szybko i przechodzą audyty. Projekty, które ją zacierają, spędzają drugi rok na uzgadnianiu dwóch źródeł prawdy.
Planujesz warstwę contentową lub afiliacyjną dla platformy iGaming? Zaczniemy od przeglądu architektury integracji i podziału odpowiedzialności między systemami. → Porozmawiajmy
