Den Lieferumfang vor dem Entwurf festlegen
Dieser Ablauf richtet sich an Händler und Frontend-Entwickler, die ein selbst gehostetes Widget prüfen, nicht an Betreiber eines verwalteten Gewinndienstes. Verantwortliche, Zeitraum, Teilnahmebedingungen, Einlösung und Ergebnisquelle schriftlich festhalten. Rad, Rubbelfeld und Boxen sind Darstellungsformen; eine Animation beweist keine Zuteilung. Der lokale Modus bleibt sichtbar eine Demo. Reale Ergebnisse, Bestand, Chancen und Authentifizierung verantwortet das Händler-Backend.
Einen vollständigen Export unverändert sichern. index.html, widget.css und widget.js gemeinsam hosten oder bewusst den Ein-Datei-HTML-Export wählen. config.json ist eine bearbeitbare Quelle, kein Geheimnisspeicher. Angebote im Frontend sind für Besucher lesbar; externe Bilder werden von deren Browsern abgerufen. Hilfswerkzeuge nur mit fiktiven oder bereinigten Beispielen nutzen, niemals mit Schlüsseln, Kundendaten oder echten Einlösecodes.
Konfiguration und Antwortvertrag abstimmen
Das JSON Schema aus der aktuellen Exportdokumentation ableiten. version, campaignId, mode, endpoint und Gewinn-IDs kontrollieren. Eindeutige IDs und exakt 100 % lokale Wahrscheinlichkeit gesondert nachrechnen; eine einfache Strukturprüfung beweist nicht alle feldübergreifenden Bedingungen. Gleich große Radsegmente bedeuten keine gleichen Chancen. Änderungen an Regeln, Beschriftungen und Ergebnisquelle im JSON-Vergleich erklären. Nach genehmigten Änderungen neu exportieren, nicht neue Konfiguration und alte Skripte mischen.
Die Anfrage enthält version, campaignId und requestId. Die Antwort muss denselben requestId und einen konfigurierten prizeId liefern; optionale Felder richten sich nach dem Exportvertrag. Gewinn- und Nichtgewinnbeispiele prüfen, ungültige Beispiele für Negativtests sichern. Ein Schema führt keine API aus und prüft weder Teilnahmeberechtigung noch Bestandsbuchung. Die Editorvorschau ruft den Endpunkt niemals auf.
Alle Zustände lesbar und bedienbar machen
Echte Text-Hintergrund-Paare einschließlich Schaltflächen und Ergebnisnachrichten messen. Ein bestandenes Farbpaar ist keine vollständige Barrierefreiheitsprüfung. HTML auf häufige Probleme prüfen und Beschriftungen, Tastaturzugang, sichtbaren Fokus, wahrnehmbare Ergebnisse sowie Bedienung ohne Animation im Browser bestätigen. Statische Analyse zertifiziert weder Rubbelgesten noch eingebettete Rahmen.
Lange Übersetzungen, vergrößerte Schrift, Gewinnbilder und Einlöselinks testen. Regeln müssen als lesbarer Text verfügbar bleiben. Nicht nur den Ausgangszustand freigeben; ungelöste Bedienprobleme trotz ansprechender Vorschau dokumentieren.
Tatsächliche Hosting- und Einbettungsumgebung testen
Dateien auf dem autorisierten HTTPS-Testhost bereitstellen. Breitenvergleiche zeigen mögliche Überläufe; Screenshots dokumentieren Ansichten, keine Ziehungen. Angemeldete Zustände oder Inhalte fremder Rahmen bleiben unter Umständen unerreichbar. URL, Breite und Version notieren und im echten Shop Rahmenhöhe, Scrollen, Tastatur sowie externe Einlöselinks manuell prüfen.
Relative API-Pfade beziehen sich auf die Herkunft des Widgets, nicht auf die äußere Shopseite. Der Export verwendet Zugangsdaten derselben Herkunft. CORS für eine fremde API veranlasst keine Übertragung fremder Sitzungscookies; Drittanbieter-Cookie-Sperren können eingebettete Anmeldungen zusätzlich stören. Eine kontrollierte eigene Widget-Herkunft vorsehen und Rahmenberechtigungen prüfen. Diese ermöglichen Händleranbindung, garantieren aber keine Isolation von dessen Code.
Gewinn, konfigurierten Nichtgewinn, erfolglosen HTTP-Status, ungültiges JSON, unbekannten prizeId, falschen requestId und Antwortverzögerung über die dokumentierten 15 Sekunden testen. Fehler dürfen keinen lokalen Ersatzgewinn auslösen. Manuelle Wiederholung nutzt eine offene Anfrage nur auf dieser Seite erneut; Neuladen ist dadurch nicht geschützt. Das Backend muss Ergebnisse transaktional idempotent speichern und verlorene Antworten nach einer Zuteilung behandeln. Dafür Testgewinne verwenden.
Eine eindeutig identifizierte Version übergeben
SHA-256 erst nach der letzten Änderung berechnen. Enddateien, Konfigurationsvergleich, Herkunft, API-Vertrag, bereinigte Browsernachweise, offene Punkte und Zuständigkeiten beilegen. Ein Hash identifiziert Bytes, nicht Fairness oder Serverkorrektheit. Reale Bestände, Berechtigungen, Einlösung und Kampagnenfreigabe sind getrennte Startbedingungen.
Für Tracking und QR zur Kampagnenlink-Prüfung wechseln, für Vorher-Nachher-Nachweise zur responsiven Änderungsprüfung und für Rabattimportdateien zur Stripe-Vorprüfung. Keiner dieser Abläufe ersetzt die Integrationsabnahme des Widgets.