Die zuverlässigsten Kampagnenregeln nützen wenig, wenn Zahlungen unsicher oder doppelt verarbeitet werden. Stripe-Webhooks informieren die Suite über relevante Ereignisse, sobald sie eintreten. Dieser Eingang ist deshalb besonders schützenswert. Mitte Juni wurde die Webhook-Härtung zu einem zentralen Entwicklungsschritt: Signaturprüfung, zusätzlicher zufälliger Token im Endpunkt, erlaubte Ereignistypen und Replay-Schutz sollen gemeinsam verhindern, dass ungeprüfte Anfragen Provisionen auslösen.
Warum ein Webhook überhaupt notwendig ist
Eine Zahlung kann stattfinden, ohne dass ein Betreiber gerade im WordPress-Admin angemeldet ist. Der Webhook übermittelt das Ereignis serverseitig an die Suite. Dadurch muss die Zuordnung nicht durch ständiges manuelles Aktualisieren gesucht werden. Stripe kann ein Ereignis bei vorübergehenden Fehlern erneut zustellen.
Gerade diese Wiederholung ist fachlich wichtig. Die Verarbeitung muss fehlertolerant sein, darf denselben Vorgang aber nicht mehrfach als neue Provision speichern. Deshalb wird jedes Ereignis anhand eindeutiger Merkmale erkannt und nur einmal abrechnungswirksam verarbeitet.
Stripe-Signatur als erste Prüfung
Stripe versieht Webhook-Anfragen mit einer Signatur. Die Suite berechnet anhand des hinterlegten Webhook-Geheimnisses, ob der Inhalt tatsächlich von Stripe stammt und unverändert ist. Fehlt die Signatur oder stimmt sie nicht, wird die Anfrage abgelehnt.
Diese Prüfung muss vor der Auswertung von Zahlungsdaten erfolgen. Eine verständliche Fehlermeldung wird intern protokolliert, während die öffentliche Antwort keine sensiblen Details preisgibt. Das Webhook-Geheimnis wird geschützt gespeichert und nicht in Supportausgaben vollständig angezeigt.
Zusätzlicher zufälliger Endpunkt-Token
Neben der Stripe-Signatur wurde ein zufälliger Token als Bestandteil des Webhook-Endpunkts vorgesehen. Dadurch ist die Zieladresse nicht allein aus dem allgemeinen REST-Pfad ableitbar. Der Token ersetzt die Signatur nicht, sondern bildet eine zusätzliche Hürde.
Bei einer Neugenerierung muss der Betreiber den Endpunkt auch in Stripe aktualisieren. Die Hilfeseite zeigt deshalb die vollständige eigene URL und erklärt, welche Ereignisse abonniert werden sollen. Alte Token verlieren nach dem Wechsel ihre Gültigkeit.
Nur erlaubte Ereignisse verarbeiten
Ein Stripe-Konto kann sehr viele Ereignistypen senden. Die Suite benötigt nur eine klar definierte Auswahl. Unbekannte oder nicht freigegebene Ereignisse werden nicht als Einlösung verarbeitet. Das reduziert Angriffsfläche und verhindert, dass ein fachlich unpassendes Ereignis versehentlich in die Provisionslogik gelangt.
Auch innerhalb eines erlaubten Typs werden Pflichtdaten geprüft. Zahlung, Betrag, Währung, Promotion Code und Kampagnenbezug müssen plausibel sein. Fehlt eine entscheidende Angabe, wird der Vorgang als prüfbarer Fehler gespeichert und nicht automatisch vergütet.
Replay-Schutz und Idempotenz
Stripe kann dasselbe Ereignis erneut senden, etwa wenn die erste Antwort nicht rechtzeitig eintraf. Zusätzlich könnten Angreifer versuchen, eine gültige Anfrage zu wiederholen. Die Suite speichert daher die eindeutige Ereignis-ID und erkennt bereits verarbeitete Meldungen.
Eine Wiederholung erhält eine erfolgreiche, aber wirkungslose Antwort, sofern der ursprüngliche Vorgang abgeschlossen wurde. So beendet Stripe seine Zustellversuche, ohne dass eine zweite Provision entsteht. Bei einem zuvor abgebrochenen internen Schritt muss der Status genau genug sein, um sicher fortsetzen zu können.
Fachliche Prüfungen nach der technischen Prüfung
Eine gültige Signatur beweist nur die Herkunft der Nachricht. Sie sagt noch nicht, dass eine Provision berechtigt ist. Deshalb folgen Prüfungen auf aktiven Code, aktive Kampagne, positiven Betrag und gültige Provisionsregel. Die berechnete Provision darf den relevanten Zahlungsbetrag nicht überschreiten.
Auch Rückerstattungen und spätere Änderungen benötigen einen definierten Umgang. Sie dürfen nicht einfach als neue positive Einlösung behandelt werden. Der Entwicklungsansatz sieht vor, solche Vorgänge nachvollziehbar zu korrigieren und den ursprünglichen Bezug zu erhalten.
Protokollierung ohne Datenleck
Für Betrieb und Support werden Zeitpunkt, Ereignistyp, Ergebnis und interne Referenz protokolliert. Vollständige Geheimnisse, Zahlungsdaten oder unnötige personenbezogene Angaben gehören nicht in ein frei sichtbares Log. Administratoren erhalten ausreichend Informationen zur Fehlersuche, ohne sensible Inhalte zu vervielfachen.
Protokolle brauchen Aufbewahrungs- und Bereinigungsfunktionen. Alte, erledigte Einträge sollen archiviert oder gelöscht werden können. Offene Sicherheits- oder Synchronisationsfehler bleiben dagegen sichtbar, bis sie geprüft wurden.
Testen mit realistischen Ereignisfolgen
Ein Webhook-Test sollte mehr umfassen als eine einzelne erfolgreiche Zahlung. Sinnvoll sind wiederholte Zustellungen desselben Ereignisses, Zahlungen ohne bekannten Code, deaktivierte Kampagnen, Rückerstattungen und absichtlich ungültige Signaturen. Jede Variante muss einen nachvollziehbaren Status erzeugen.
Zusätzlich wird geprüft, wie das System nach einem internen Fehler fortsetzt. Wurde das Ereignis bereits gespeichert, aber die Provisionsberechnung unterbrochen, darf der nächste Versuch nicht bei null beginnen. Realistische Testfolgen zeigen, ob Idempotenz und Wiederaufnahme tatsächlich zusammenarbeiten.
Webhook-Zustand im Dashboard
Der Betreiber soll erkennen, wann zuletzt ein gültiges Ereignis einging und ob Signatur- oder Tokenfehler aufgetreten sind. Eine Testfunktion kann einen vorbereiteten Prüfablauf unterstützen, darf aber kein echtes Stripe-Ereignis vortäuschen. Entscheidend ist die Kombination aus Einrichtungsstatus, letzter erfolgreicher Verarbeitung und offenen Fehlern. So wird der Webhook nicht zu einem unsichtbaren Hintergrundbaustein.
Schlüsselwechsel dokumentieren
Wird ein Webhook-Geheimnis oder Endpunkt-Token erneuert, sollte der Wechsel mit Zeitpunkt dokumentiert werden. So lassen sich Zustellfehler nach einer Umstellung schneller einordnen.
Der gehärtete Webhook trennt bloße Netzwerkereignisse von abrechnungsrelevanten Einlösungen. Erst wenn Herkunft, Eindeutigkeit und fachliche Bedingungen stimmen, darf eine Provision entstehen. Diese Reihenfolge bildet das Sicherheitsfundament für alle späteren Automatisierungen.
