{"id":4546,"date":"2026-10-06T11:31:50","date_gmt":"2026-10-06T11:31:50","guid":{"rendered":"https:\/\/whitelotto.com\/?p=4546"},"modified":"2026-10-07T05:26:59","modified_gmt":"2026-10-07T05:26:59","slug":"lottery-draw-results-api-integration","status":"publish","type":"post","link":"https:\/\/whitelotto.com\/de\/lottery-draw-results-api-integration\/","title":{"rendered":"Lotterie-API f\u00fcr Ziehungen und Ergebnisse: Annahmeschluss und Abrechnung"},"content":{"rendered":"\n

Eine Integration f\u00fcr Lotterieziehungen und Ergebnis-APIs muss die Verbindung zwischen der richtigen Ziehung, dem akzeptierten Spielschein, dem autorisierten Ergebnis und der anschlie\u00dfenden Abrechnung erhalten. Die anspruchsvolle Arbeit liegt in Annahmeschl\u00fcssen, Zeitzonen, Ergebnisrevisionen und der Wiederherstellung bei fehlenden oder wiederholten Nachrichten, nicht in der blo\u00dfen Anzeige von Gewinnzahlen.<\/p>\n

Dies ist ein anbieterneutraler Anforderungsleitfaden, keine Spezifikation tats\u00e4chlicher WhiteLotto-Endpunkte und keine Zusage, dass jede beschriebene Schnittstelle enthalten ist. Beginnen Sie mit dem Leitfaden zur Lotterie-API-Architektur<\/a> und vereinbaren Sie den tats\u00e4chlichen Vertrag mit dem Umsetzungsteam.<\/p>\n

Stabile Ziehungskennungen statt ausschlie\u00dflich Datumsangaben verwenden<\/h2>\n

Ein Ziehungsdatum identifiziert eine Ziehung nicht zuverl\u00e4ssig, wenn ein Produkt mehrere t\u00e4gliche Ziehungen, Termin\u00e4nderungen oder mehrere Zeitzonen hat. Ordnen Sie Produktkennung, Ziehungskennung des Anbieters und Plattformkennung einander zu. Bewahren Sie diese Referenzen auf Spielscheinen und in Berichten auf. Entscheiden Sie, ob eine verschobene Ziehung ihre Identit\u00e4t beh\u00e4lt und wie eine abgesagte Ziehung akzeptierte Spielscheine betrifft.<\/p>\n

\n
Schnittstellenvertrag f\u00fcr Ziehungen und Ergebnisse<\/caption>
Datensatz<\/th>Vor der Implementierung definieren<\/th>Abnahmenachweis<\/th><\/tr><\/thead>
Ziehungsplan<\/th>Stabile Kennung, Produkt, geplanter Zeitpunkt, Annahmeschluss und geltende Zeitzone.<\/td>Eine durchgehende Spur zwischen Katalog, Kauf und Reporting.<\/td><\/tr>\n
Spielscheinannahme<\/th>Ma\u00dfgeblicher Annahmezeitpunkt, Stichtagsregel und Behandlung unklarer Antworten.<\/td>F\u00e4lle unmittelbar vor, genau an und nach der Grenze.<\/td><\/tr>\n
Ergebnis<\/th>Ma\u00dfgebliche Quelle, Status, Ver\u00f6ffentlichungszeit, Version und Vollst\u00e4ndigkeit.<\/td>Unver\u00f6ffentlichte, vorl\u00e4ufige und endg\u00fcltige Ergebnisszenarien.<\/td><\/tr>\n
Korrektur<\/th>Revisionsreferenz, Grund, Freigabe und Behandlung betroffener Spielscheine.<\/td>Auditspur zwischen bisherigem und korrigiertem Ergebnis.<\/td><\/tr>\n
Abrechnung<\/th>Ausl\u00f6ser, Berechnungsverantwortung, Buchungsreferenzen und Abgleich.<\/td>Ein finanzieller Effekt je vorgesehener Abrechnung.<\/td><\/tr>\n<\/tbody><\/table><\/div>\n

Zeitsemantik und Annahmeschluss vereinbaren<\/h2>\n

Speichern Sie einen eindeutigen Zeitpunkt zusammen mit der benannten lokalen Zeitzone f\u00fcr Kundenanzeige und Gesch\u00e4ftsregeln. Das Zeitstempelformat RFC 3339<\/a> ist eine hilfreiche Referenz f\u00fcr einen Zeitpunkt mit UTC-Versatz. Der Versatz allein beschreibt nicht die zuk\u00fcnftigen Sommerzeitregeln einer Region.<\/p>\n

Legen Sie fest, ob die Annahme vom Eingang auf der Plattform, der Annahme beim Lieferanten oder einem anderen vertraglichen Ereignis abh\u00e4ngt. Ein Countdown im Frontend informiert; er sollte nicht entscheiden, ob ein Spielschein existiert. Testen Sie Zeitsynchronisierung, Uhrabweichungen, versp\u00e4tete Anfragen und Sommerzeitwechsel. Zeigen Sie einen klaren Ausgang an, wenn der Verkauf geschlossen ist.<\/p>\n

Ein Timeout kurz vor Annahmeschluss ben\u00f6tigt eine Ergebnisabfrage oder einen zugeordneten Ausnahmeprozess. Blindes Wiederholen kann ein Duplikat oder einen Spielschein f\u00fcr eine andere Ziehung erzeugen. Bewahren Sie die urspr\u00fcngliche Vorgangsreferenz und die Referenz der angeforderten Ziehung auf.<\/p>\n

Ergebniskorrekturen als kontrollierte \u00c4nderungen behandeln<\/h2>\n

Unterscheiden Sie empfangene, validierte, endg\u00fcltige und korrigierte Ergebnisse im vereinbarten Zustandsmodell. Ein fehlendes Feld bedeutet keinen verlorenen Spielschein. Legen Sie fest, wer die Abrechnung freigeben darf und wie die Quelle authentifiziert wird. Bewahren Sie bei einer Korrektur die fr\u00fchere Version auf und verkn\u00fcpfen Sie die Anpassung mit Grund und Freigebendem.<\/p>\n

Eine wiederholte Benachrichtigung darf denselben Spielschein nicht zweimal abrechnen. Ein versp\u00e4tetes \u00e4lteres Ergebnis darf keine neuere autorisierte Revision \u00fcberschreiben. Finanzielle Korrekturen m\u00fcssen nachvollziehbar bleiben, statt den urspr\u00fcnglichen Buchungsverlauf still umzuschreiben. Der Leitfaden zur Zahlungsintegration<\/a> behandelt die entsprechende Disziplin f\u00fcr asynchrone finanzielle Ereignisse.<\/p>\n

Fehlende Ereignisse sichtbar machen<\/h2>\n