Eine Game-Provider-Aggregationsschicht für Ihr eigenes Casino-Backend: Sessions, Guthaben-Callbacks und Rundenhistorie

Ein Betreiber, der sein eigenes Casino-Backend baut und Slots, Live Dealer und Tischspiele von vielen Providern anbindet, hat am Ende so viele Integrationsverträge wie Provider: unterschiedliche Start-Flows, unterschiedliche Wallet-Aufrufe, unterschiedliche Vorstellungen davon, was eine Runde ist. Die Aggregationsschicht macht daraus einen einzigen internen Vertrag, sodass Wallet, Lobby, Boni, Limits und Reporting einmal geschrieben werden und jeder Provider an sie angepasst wird.

Was folgt, zeigt, wie diese Schicht üblicherweise aufgeteilt ist: was beim Provider bleibt, wie Sessions vergeben werden, wie Guthaben-Callbacks Retries und Rollbacks überstehen, wie Runden erfasst werden, wenn sie nach der Session abgeschlossen werden, und wie das Ergebnis mit den eigenen Zahlen des Providers abgeglichen wird.

Was die Schicht verantwortet und was beim Provider bleibt

Der Provider betreibt das Spiel: Zufallszahlengenerierung, Spielmathematik, der Spiel-Client und seine Zertifizierung durch ein Prüflabor. Der Betreiber behält alles, was den Spieler und das Geld berührt: Identität, Guthaben, Limits, Boni, die Lobby und die Aufzeichnungen, die eine Aufsichtsbehörde oder ein Streitfall mit einem Spieler verlangen kann. Die Aggregationsschicht sitzt dazwischen und sollte der einzige serverseitige Code sein, der die API des jeweiligen Providers spricht.

• Start: eine Spiel-URL oder ein Token für einen Spieler, ein Spiel, eine Währung, eine Sprache und ein Gerät sowie ein Demo-Modus, der nie die Wallet erreicht
• Wallet: Aufrufe für Guthaben, Belastung, Gutschrift und Rollback von jedem Provider, beantwortet über ein einziges internes Ledger
• Runden: Runden-ID und Rundenzustand des jeweiligen Providers, einschließlich Runden mit mehreren Einsätzen und Runden, die spät enden
• Katalog: Spiel-IDs der Provider, Kategorien und unterstützte Geräte, gemappt auf eine einzige Lobby, gefiltert danach, wo jedes Spiel angeboten werden darf
• Boni: Freirunden, gewährt über die eigene Bonus-Schnittstelle eines Providers, wo er eine hat, wobei die Gewinne als Bonusgeld erfasst werden
• Reporting: Summen pro Provider in der Form, auf die sich die Rechnungen des Providers stützen

Seamless Wallet oder Transfer Wallet

Provider werden auf eine von zwei Arten an das Geld eines Betreibers angebunden. Bei einer Seamless Wallet bleibt das Guthaben beim Betreiber, und der Provider ruft für jeden Einsatz und jeden Gewinn die Wallet des Betreibers auf. Bei einer Transfer Wallet überträgt der Betreiber vor dem Spiel Geld in ein Guthaben, das auf der Seite des Providers geführt wird, und überträgt es erst zurück, wenn er es anfordert.

• Seamless führt ein einziges Guthaben über alle Spiele hinweg, sodass Limits, Boni und der Blick des Spielers auf sein Geld konsistent bleiben, und macht Latenz und Verfügbarkeit der Wallet des Betreibers zum Teil jedes Spins
• Transfer isoliert das Spiel von der Wallet des Betreibers und teilt das Guthaben auf: Geld, das in einer Provider-Session liegt, ist nirgendwo sonst verfügbar, und jeder Transfer hinein und heraus ist eine weitere abzugleichende Buchung
• Eine Schicht, die beides unterstützt, hat trotzdem ein einziges internes Ledger; der Transfer-Adapter macht aus dem Beginn und dem Ende einer Session eine Belastung und eine Gutschrift

Der Rest dieses Artikels geht von einer Seamless Wallet aus, weil dort jeder Einsatz und jeder Gewinn ein Wallet-Aufruf ist.

Sessions: Der Betreiber vergibt das Token

Ein Spielstart beginnt auf der Seite des Betreibers. Das Backend prüft, ob dieser Spieler dieses Spiel jetzt spielen darf, was den Kontozustand, die Selbstsperre, Limits und die Frage umfasst, ob das Spiel in der Jurisdiktion des Spielers angeboten werden darf. Danach erzeugt es eine Session, die an den Spieler, das Spiel und die Währung gebunden ist, und übergibt dem Provider beim Start ein opakes Token. Wenn der Server des Providers zurückruft, identifiziert dieses Token, um wessen Guthaben es bei dem Aufruf geht.

• Ein Token identifiziert eine Session, nicht für immer einen Spieler: Es läuft ab, und der Betreiber kann es widerrufen, wenn der Spieler sich während des Spiels selbst sperrt oder ein Limit erreicht
• Neue Einsätze brauchen eine gültige Session; ein Gewinn für einen bereits angenommenen Einsatz muss gutgeschrieben werden, auch wenn die Session inzwischen beendet ist
• Ein Spieler kann mehrere Spiel-Sessions gleichzeitig halten, daher werden Guthabenänderungen pro Konto serialisiert, nicht pro Session
• Die Währung ist für die Session festgelegt; ein Spieler, der die Währung wechselt, beginnt eine neue
• Das Demo-Spiel erhält ein Token, das die Wallet kategorisch ablehnt, sodass ein fehlgeleiteter Aufruf nie Echtgeld berühren kann

Veröffentlichte Dokumente für Betreiber sagen das deutlich. Die Wallet-API von Hub88 sagt, dass die Token-Gültigkeit bei Gewinnen und Rollbacks nicht validiert werden darf, da diese eintreffen können, nachdem der Einsatz gespielt wurde. VeliGames sagt, dass der Betreiber den Gewinn einer Runde nicht ablehnen darf, auch wenn die Session abgelaufen ist.

Guthaben-Callbacks: Jeder Aufruf kann zweimal eintreffen

Jeder Aufruf zwischen zwei Servern kann in ein Timeout laufen, nachdem die Arbeit auf der anderen Seite erledigt war. Der Provider kann eine fehlgeschlagene Belastung nicht von einer Belastung unterscheiden, deren Antwort verloren gegangen ist, also wiederholt er den Aufruf oder storniert die Transaktion. Aufgabe der Wallet ist es, beides sicher zu machen.

Veröffentlichte Integrationsdokumente zeigen, wie hartnäckig die Wiederholungen sind. Die Betreiber-Wallet-API von Hub88 wertet einen Einsatz als fehlgeschlagen, wenn sie kein HTTP 200 erhält, erzeugt ein Rollback und wiederholt dieses Rollback bis zu 500-mal mit exponentiellem Backoff. Gamomat wiederholt eine fehlgeschlagene Request zweimal im Abstand von 500 ms, startet dann ein Rollback und wiederholt es in Intervallen, die von einer Sekunde auf 30 Minuten anwachsen. Das Wallet-Timeout von Tom Horn Gaming beträgt 10 Sekunden, danach wird automatisch ein Rollback gesendet. Eine Wallet, die einige Minuten ausfällt, trifft bei ihrer Rückkehr auf eine Queue aus Wiederholungen und Rollbacks, nicht auf Stille.

• Der Idempotenz-Schlüssel ist die Transaktions-ID des Providers, abgegrenzt nach Provider und Aufruftyp, denn zwei Provider können dieselbe ID vergeben, und manche senden ein Rollback unter der ID des Einsatzes; ein Unique Constraint auf diesem Schlüssel macht aus einem wiederholten Aufruf einen Lookup
• Eine wiederholte Belastung bewegt nie ein zweites Mal Geld, und dieselbe ID, die mit einem anderen Betrag oder einer anderen Runde eintrifft, ist ein Fehler, kein neuer Einsatz
• Eine Belastung sperrt die Kontozeile, prüft Deckung und Limits und schreibt ihre Ledger-Buchung in einer kurzen Transaktion, sodass zwei nebenläufige Spins auf einem Konto nicht beide dasselbe Geld ausgeben können
• Ein Rollback benennt die Transaktion, die es storniert: Eine gebuchte Belastung wird ein einziges Mal rückgängig gemacht, und ein bereits verarbeitetes Rollback liefert sein gespeichertes Ergebnis zurück
• Ein Rollback für eine Transaktion, die die Wallet nie erhalten hat, wird erfasst und mit dem Code beantwortet, den der Provider dokumentiert, sodass ein verzögertes Original, das danach eintrifft, abgelehnt wird, statt dem Spieler einen Einsatz zu berechnen, den der Provider bereits storniert hat
• Fehler werden auf die eigenen Codes jedes Providers gemappt, weil Provider unterschiedlich auf unzureichende Deckung, eine abgelaufene Session und einen allgemeinen Fehler reagieren: Manche stoppen das Spiel, manche versuchen es erneut, manche stornieren

Auch die erwartete Antwort auf eine Wiederholung folgt keinem Standard. Hub88 verlangt, dass Requests mit derselben Transaktions-ID nicht zweimal verarbeitet werden und dass die Antwort für alle Duplikate dieselbe ist; VeliGames fordert einen Fehler mit HTTP status 409 und DUPLICATE_TRANSACTION; Tom Horn Gaming hat einen separaten Ergebniscode für eine doppelte Referenz. Der Adapter antwortet jedem Provider in dessen eigener Form, und das Ledger darunter bleibt dasselbe.

Provider halten diese Regel in ihren eigenen Dokumenten fest. Die Betreiber-API von St8 sagt: Erhält der Betreiber eine Transaktions-ID für eine Stornierung, die er zuvor nicht verarbeitet hat, muss die ID gespeichert werden, um zu verhindern, dass sie später verarbeitet wird. Tom Horn Gaming erwartet den eigenen Ergebniscode für unbekannte Transaktionen, wenn die Wallet die Abbuchung, auf die sich ein Rollback bezieht, nie verarbeitet hat.

Runden werden nach ihrem eigenen Zeitplan abgeschlossen

Eine Runde ist die Spieleinheit des Providers, und sie entspricht selten einer einzelnen Transaktion. Ein Slot-Spin ist oft eine Belastung und eine Gutschrift, manchmal in einem einzigen Aufruf gesendet. Blackjack kann Belastungen für einen Split oder ein Verdoppeln hinzufügen. Live-Roulette nimmt während einer Setzphase Einsätze vieler Spieler an und rechnet sie alle ab, sobald das Ergebnis feststeht. Freirunden können eine Serie von Gewinnen erzeugen, die zusammengehören.

• Speichern Sie die Runden-ID des Providers mit jeder Ledger-Buchung, und führen Sie den Zustand der Runde separat: offen, abgeschlossen oder storniert
• Schließen Sie eine Runde anhand des eigenen Signals des Providers ab, eines expliziten Aufrufs zum Rundenende oder eines Final-Flags, wo die API eines hat, und andernfalls anhand einer dokumentierten Regel pro Provider
• Lassen Sie Runden länger leben als Sessions: Ein Spieler, dessen Verbindung mitten in einer Runde abbricht, erhält trotzdem ihr Ergebnis, oft lange nachdem das Session-Token abgelaufen ist
• Beobachten Sie offene Runden nach Alter pro Provider; eine wachsende Zahl alter offener Runden zeigt eine defekte Integration an, lange bevor sich ein Spieler beschwert

Die Rundenhistorie ist das, womit ein Streitfall mit einem Spieler beigelegt wird. Führen Sie jede Ledger-Buchung mit dem Provider, dem Spiel, der Runde, den Beträgen, dem Guthaben davor und danach sowie zwei Zeitstempeln, dem des Providers und dem der Wallet, und verlinken Sie die eigenen Rundendetails des Providers, wo seine API sie anbietet. Damit wird eine Frage zum Geld in einem Spin aus den Aufzeichnungen beantwortet.

Aufsichtsbehörden legen das Minimum fest, das diese Historie abdecken muss. GLI-19, der Standard für interaktive Glücksspielsysteme von Gaming Laboratories International, verlangt für den Spieler eine Game-Recall-Funktion, entweder als Nachstellung oder als Beschreibung. Die technischen Standards der britischen Glücksspielbehörde (UK Gambling Commission) für Remote-Glücksspiel verlangen mindestens drei Monate Konto- und Spielhistorie ohne Kontaktaufnahme mit dem Lizenzinhaber und mindestens 12 Monate auf Anfrage. Die Spielerschutzrichtlinie der maltesischen Glücksspielbehörde (Malta Gaming Authority) gibt dem Spieler Zugang zu seiner Spielhistorie der unmittelbar vorangegangenen sechs Monate.

Live Dealer macht aus der Wallet einen Burst

Slots verteilen die Last über die Zeit, weil jeder Spieler seine Spins in seinem eigenen Takt auslöst. Live-Dealer-Tische synchronisieren die Spieler: Die Einsätze aller Spieler an einem Tisch treffen in den Sekunden vor dem Ende der Setzphase ein, und die Gewinne aller treffen gemeinsam ein, sobald das Ergebnis feststeht. Ein beliebter Tisch wiederholt das für jeden Spieler, der gesetzt hat.

• Halten Sie jede Wallet-Transaktion kurz und auf ein Konto beschränkt, damit der Burst eines Tisches nur die Konten an diesem Tisch serialisiert
• Beantworten Sie den Callback und erledigen Sie den Rest danach: Bonus-Wagering, Loyalty-Punkte und Analytics lesen das Ledger-Event nach dem Commit, nicht innerhalb des Aufrufs
• Testen Sie den Ergebnis-Burst selbst unter Last, dimensioniert für den voraussichtlich am stärksten frequentierten Tisch, während andere Spiele weiter Einsätze senden

Ein interner Vertrag, viele Adapter

Adapter sind der Ort, an dem die Unterschiede zwischen Providern leben, und sie sollten der einzige Ort dafür sein. Jeder Adapter übernimmt:

• Authentifizierung eingehender Callbacks, etwa über Request-Signaturen oder erlaubte Quelladressen, wie vom Provider vorgegeben
• Betragsformate: in manchen APIs Ganzzahlen mit fester Skalierung, in anderen Dezimalwerte, sowie die Währungen, die ein Provider unterstützt
• Mapping von Feldern und Fehlercodes auf den internen Vertrag
• Import des Spielkatalogs und der Startparameter
• Freirunden über die Bonus-Schnittstelle des Providers
• Die Integrationsszenarien des Providers, anschließend als Regressionstests beibehalten, die vor jedem Release laufen

Der interne Vertrag bleibt klein: eine Session öffnen, das Guthaben lesen, belasten, gutschreiben, in einem Aufruf belasten und gutschreiben, ohne Einsatz auszahlen, ein Rollback ausführen, eine Runde abschließen und ein fester Satz von Fehlern, die die Wallet zurückgeben kann. Ein neuer Provider ist dann ein Adapter und eine Testsuite, selten eine Änderung an der Wallet.

Abgleich: Der Report des Providers ist ein zweites Ledger

Jeder Provider führt eigene Aufzeichnungen über jede Runde und stellt dem Betreiber auf dieser Grundlage Rechnungen. Das Ledger der Aggregationsschicht ist die Betreiberseite desselben Geldes. Gleichen Sie beide jeden Tag ab, nach Tagesgrenze und Zeitzone des jeweiligen Providers, pro Provider, Währung und Spiel:

• Zuerst die Summen: Einsätze, Gewinne und die Differenz zwischen beiden für den Tag
• Dann die Transaktionen: Buchungen, die nur auf einer Seite existieren, und Beträge, die abweichen
• Klären Sie jede Differenz anhand der Rundenhistorie, und verfolgen Sie die Zahl der Differenzen als Kennzahl, die nahe null bleiben sollte, statt als Arbeit, die stillschweigend behoben wird

Wie lange diese Nachweise aufbewahrt werden müssen, ist Teil der Integration. Hub88 fordert, dass jede Transaktions-ID zu Abgleichszwecken auf beiden Seiten mindestens vier Monate lang gespeichert wird, und die Betreiber-API von Gamomat liefert Abgleichsdaten für einen Datumsbereich oder für eine einzelne Runde.

Was zu messen ist, bevor der erste Provider live geht

• Callback-Latenz pro Provider und pro Aufruftyp, als p99 statt als Durchschnitt
• Wiederholte Aufrufe und wiederholte IDs, die mit einem anderen Payload eintreffen
• Rollbacks und Rollbacks für Transaktionen, die die Wallet nie erhalten hat
• Offene Runden nach Alter
• Abgelehnte Belastungen nach Grund: Deckung, Limits, Session oder Fehler
• Tägliche Abgleichsdifferenzen pro Provider

Welche Unternehmen bauen Game-Provider-Aggregationsschichten für Betreiber?

Auf die Frage gibt es drei Arten von Antworten, und sie verkaufen verschiedene Dinge. Aggregatoren und Plattformanbieter vermieten dem Betreiber ihre Schicht: ein Vertrag, viele Provider, ihre kommerziellen Konditionen. Turnkey- und White-Label-Plattformen enthalten die Schicht innerhalb einer Plattform, die dem Anbieter gehört. Engineering-Firmen bauen die Schicht im Backend des Betreibers, und der Betreiber schließt seine Provider-Verträge selbst ab.

Mit welcher Art Sie auch sprechen, diese Fragen zeigen, ob ein Team das schon einmal gebaut hat:

• Was macht die Wallet mit einem Rollback für eine Transaktion, die sie nie erhalten hat?
• Wie wird verhindert, dass Transaktions-IDs von zwei Providern kollidieren?
• Wie wird eine Runde, die nach ihrer Session abgeschlossen wird, erfasst und dem Spieler angezeigt?
• Welche Provider haben sie über eine Seamless Wallet integriert und welche über Transfers?
• Wie gleichen sie gegen Provider-Reports ab, und wie sieht eine normale tägliche Differenz aus?
• Wem gehören der Adapter-Code und der interne Vertrag, wenn die Arbeit endet, und welche Teile bleiben wiederverwendbare Komponenten des Anbieters?

Eine Antwort, die bei den ersten beiden allgemein bleibt, heißt, dass die Sonderfälle in Produktion gefunden würden.

Integriert amBrain Game Provider für Casino-Betreiber?

amBrain ist ein Softwareentwicklungsunternehmen mit Spezialisierung auf Trading-Plattformen, Matching Engines, Real-Time-Bidding-Systeme und Casino-Plattform-Engineering. amBrain entwickelt seit 2019 Software.

Im iGaming sind die Zahlen, die amBrain als gemessen veröffentlicht, 500+ Integrationen von Drittanbietern und 12 Betreiber im Live-Betrieb.

amBrain arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen die wiederverwendbaren Komponenten von amBrain.

Dieser Artikel erklärt, wie eine Aggregationsschicht funktioniert; er ist keine Case Study und nennt keine Kunden.

Die erste Entscheidung ist also nicht, welche Provider unter Vertrag genommen werden. Es ist der interne Vertrag, an den jeder Provider angepasst wird, mit seinen Fehlerfällen schriftlich festgehalten, bevor der erste Adapter existiert.