Lotterie-Wallet und Abstimmungsarchitektur: Checkliste für Betreiber
Eine Lotterie-Wallet ist mehr als der angezeigte Spielersaldo. Bei der Plattformwahl zählen die Transaktionsaufzeichnungen hinter diesem Saldo, die Abwicklung von Käufen und Gewinnen sowie die Erkennung von Systemdifferenzen durch die Finanzabteilung. Diese Checkliste behandelt diese Betriebsgrenzen. Die Auswahl eines Zahlungsanbieters ist eine eigene Entscheidung: Der Leitfaden zum Zahlungsaufbau einer Lotterie behandelt Zahlungsarten, Abwickler und Vertragsmodelle. […]
Eine Lotterie-Wallet ist mehr als der angezeigte Spielersaldo. Bei der Plattformwahl zählen die Transaktionsaufzeichnungen hinter diesem Saldo, die Abwicklung von Käufen und Gewinnen sowie die Erkennung von Systemdifferenzen durch die Finanzabteilung.
Diese Checkliste behandelt diese Betriebsgrenzen. Die Auswahl eines Zahlungsanbieters ist eine eigene Entscheidung: Der Leitfaden zum Zahlungsaufbau einer Lotterie behandelt Zahlungsarten, Abwickler und Vertragsmodelle. Hier geht es darum, jede Bewegung erklären und abstimmen zu können.
Die Bedeutung jedes Saldos definieren
Fordern Sie vor der Bildschirmprüfung ein Saldenverzeichnis an. Unterscheiden Sie verfügbares Geld, reservierte Beträge, Bonusguthaben und offene Auszahlungen. Legen Sie die Währung jedes Betrags, gegebenenfalls Umrechnungsregeln und das führende System für jeden Zustand fest.
- Kann der Support erklären, warum verfügbarer Saldo und Buchungssaldo voneinander abweichen?
- Welche Aktionen reservieren, geben frei, belasten oder schreiben gut, und wer darf sie auslösen?
- Enthält ein Export Anfangssaldo, Bewegungen und Endsaldo mit stabilen Referenzen?
Den Lebenszyklus von Spielschein und Abwicklung abbilden
Definieren Sie das erwartete Verhalten vor der Integrationsfreigabe. Zahlungsbenachrichtigung, angenommener Spielschein und endgültiges Ziehungsergebnis sind unterschiedliche Ereignisse: Legen Sie ihre Beziehungen fest.
| Ereignis | Abnahmefrage |
|---|---|
| Kauf angenommen | Sind Spielschein, Belastung und Endstatus nachvollziehbar verknüpft? |
| Kauf abgelehnt | Werden reservierte Beträge freigegeben, ohne einen gültigen Spielschein auszustellen? |
| Stornierung oder Erstattung | Verweist die Gegenbuchung auf den ursprünglichen Eintrag und einen genehmigten Grund? |
| Gewinnabwicklung | Ist jede Gutschrift auf Ziehung, Spielschein und Abwicklungsversion zurückführbar? |
Wiederholungen und Ausnahmen vereinbaren
HTTP macht nicht jede Wiederholung sicher: RFC 9110 unterscheidet idempotente Methoden. Vereinbaren Sie die anwendungsseitige Duplikatbehandlung für Käufe, Auszahlungen und Rückmeldungen; eine erfolgreiche API-Antwort beweist sie nicht.
- Wiederholen Sie dieselbe Kaufreferenz und prüfen Sie, dass keine zweite unbeabsichtigte Belastung oder Spielscheinausstellung entsteht.
- Unterbrechen Sie die Antwort nach dem Absenden und zeigen Sie, wie der Endstatus wiederhergestellt wird.
- Definieren Sie verspätete, doppelte und ungeordnet eintreffende Rückmeldungen sowie Eskalation bei gescheiterter automatischer Wiederherstellung.
Abstimmung für die Finanzabteilung planen
Stimmen Sie für ein Geldbuch und eine Währung Anfangssaldo plus gebuchte Gutschriften minus gebuchte Belastungen mit dem Endsaldo ab. Definieren Sie Buchungsarten und Berichtsstichtag; diese Prüfung allein stimmt weder Zahlungsanbieter noch Bank ab.
Vergleichen Sie Plattformbuchungen getrennt mit Abrechnungen des Zahlungsabwicklers und relevanten Bankaufzeichnungen. Dokumentieren Sie Gebühren, Erstattungen, Rückbelastungen, Währungs- und Zeitdifferenzen. Jede Ausnahme braucht Zuständigkeit, Nachweis, Status und Lösungshistorie. Der Leitfaden zur Lotterie-API-Integration unterstützt die Definition der ausgetauschten Daten.
Korrekturen kontrollieren und Prüfspuren schützen
Legen Sie Freigaben für manuelle Korrekturen, Erstattungen und Exportzugriff fest. Verlangen Sie handelnde Person, Zeitpunkt, Grund und verknüpfte Transaktionskennungen je Änderung. OWASP empfiehlt, Zugangsdaten und sensible Zahlungsdaten aus Protokollen auszuschließen oder zu schützen.
Beziehen Sie Exportzugriff und Vorfallreaktion in die Sicherheits- und SLA-Prüfung ein. Vereinbaren Sie beim Plattformwechsel, wie Anfangssalden und offene Spielscheine während der Plattformmigration nachgewiesen werden, statt sie nach dem Start zu rekonstruieren.
Vier Abnahmefälle in der Demo verwenden
Fordern Sie Ereignishistorie, Buchungen und Finanzexport für jeden Fall. Bewerten Sie den vollständigen Ablauf, nicht ein Bild des Endsaldo. Dokumentieren Sie nicht unterstützte Fälle und notwendige Arbeiten vor Vertragsabschluss.
- Ein normaler Kauf mit anschließendem Ziehungsergebnis und nachvollziehbarer Gewinn- oder Verlustabwicklung.
- Ein abgelehnter Kauf mit Freigabe der Reservierung und ohne doppelte Belastung nach Wiederholung.
- Eine Stornierung oder Erstattung mit Originalreferenz, berechtigter Person und konsistentem Export.
- Eine absichtliche Abstimmungsdifferenz in einer Testumgebung, mit Zuständigkeit und belegter Lösung.
Die Betriebsgrenzen im Leistungsumfang festhalten
Vergleichen Sie Plattformmodule und Lieferumfang mit den benötigten Zuständigkeiten für Buchungen, Zahlungsabwickler und Finanzen. Legen Sie fest, wer Regeln konfiguriert, Ausnahmen überwacht, Änderungen genehmigt und Exporte liefert. Nehmen Sie diese Leistungen in den Umsetzungsplan auf, statt Abstimmung auf die Zeit nach dem Start zu verschieben.
Technische Quellen
- RFC 9110: HTTP-Semantik und idempotente Methoden (auf Englisch)
- OWASP: Leitfaden zur Protokollierung (auf Englisch)
Wallet- und Abstimmungsanforderungen besprechen
Bringen Sie Zahlungsfluss, Währungen, Buchungszuständigkeit und vorhandene Berichtsanforderungen mit. WhiteLotto kann den Plattformumfang und Integrationsfragen Ihres Projekts besprechen.