Ein doppelter Zahlungswebhook soll für dieselbe verifizierte Transaktion nur eine beabsichtigte Auslieferung auslösen. Bei PayRequest payment.succeeded prüfen Sie zuerst die Signatur des unveränderten Bodys und verwenden anschließend data.id in einem dauerhaften Verarbeitungsschlüssel. Eine wiederholte Nachricht darf keine zusätzliche Lieferung oder Leistungsgutschrift erzeugen.
Dies ist eine Entwurfs- und Abnahmecheckliste für Entwickler eigener Auslieferungssysteme. Ein Datenbankeintrag garantiert allein keine genau einmalige externe Aktion.
Den tatsächlichen Vertrag prüfen
Die PayRequest-Webhookdokumentation beschreibt HTTPS POST, X-PayRequest-Signature und HMAC-SHA256 über den unveränderten Requestbody. Prüfen Sie mit serverseitigem Secret und zeitkonstantem Vergleich. Validieren Sie Format und Länge des Headers; manche Vergleichsfunktionen akzeptieren keine ungleichen Längen. Bewahren Sie die Bytes vor der JSON-Verarbeitung auf.
Für payment.succeeded ist data.id die Transaktions-ID. Ein separates Event-ID-Feld auf oberster Ebene ist in der veröffentlichten Zahlungspayload nicht dokumentiert. Kopieren Sie keine event.id-Lösung anderer Anbieter ungeprüft. Secrets gehören nicht in Browsercode; vollständige Kundendaten müssen nicht unnötig protokolliert werden.
Zahlung statt gemeinsamem Link identifizieren
Ein beispielhafter Schlüssel lautet integration-account / payment.succeeded / data.id. Bei mehreren Händlerkonten braucht er einen Kontobezug. Das ist Ihr Entwurf, kein PayRequest-Feld.
Ein payment_link_id kann zu mehreren gültigen Zahlungen gehören. E-Mail, Betrag und Beschreibung reichen ebenfalls nicht als eindeutiger Schlüssel: Ein Kunde kann zweimal kaufen. Dieselbe data.id ist eine Wiederholung, eine neue data.id am selben Link eine neue Zahlung.
Ordnen Sie die Transaktion über eine kontrollierte Integrationsreferenz einer echten Bestellung oder Berechtigung zu. Erfolg legt Paket, Zeitraum oder Menge nicht automatisch fest. Unbekannte Referenzen zunächst zur Prüfung zurückhalten.
Vergleichen Sie Betrag und Währung vor der Auslieferung mit der vorgesehenen Bestellung. Unerwartete Werte müssen geprüft werden.
Dauerhaft speichern, dann bestätigen
Nutzen Sie eine Unique-Constraint und eine atomare Transaktion für akzeptierte Zahlung und einen ausstehenden Auslieferungsauftrag. Eine dauerhafte Outbox trennt Empfang und langsame Arbeit. Bestätigen Sie nach dauerhafter Annahme; bekannte Wiederholungen erzeugen keinen zweiten Auftrag.
PayRequest akzeptiert 2xx. Die Dokumentation nennt fünf Versuche für Kautionswebhooks, für Zahlungen aber nur die bestehende Queue-Regel ohne Anzahl. Übertragen Sie diese Wiederholungsfristen nicht auf Zahlungen oder Ihre Deduplizierung.
Nach externer Auslieferung kann ein Worker vor Speicherung des Ergebnisses abstürzen. Nutzen Sie unterstützte Idempotenz des Zielsystems oder gleichen Sie das externe Ergebnis vor einer Wiederholung ab. Das lokale Register garantiert keine Genau-einmal-Wirkung über Systemgrenzen.
Die eigene Replay-Matrix ausführen
Testen Sie einen isolierten Empfänger mit fiktiven signierten Daten ohne echte Auslieferung. Test-Bodys mit Testsecret signieren; Änderungen erfordern eine neue Signatur. Das sind vorgeschlagene Tests, keine Produktionskontotests.
| Test | Eingabe | Erwartetes Ergebnis |
|---|---|---|
| Replay | Gleiche Transaktion zweimal | Eine Zahlung und ein Auftrag |
| Parallelzustellung | Zwei gültige Kopien gleichzeitig | Unique-Constraint verhindert zwei Aufträge |
| Zweiter Kauf | Gleicher Link, neue Transaktions-ID | Zwei Zahlungen und Aufträge |
| Manipulation | Neuer Body, alte Signatur | Ablehnung vor Auslieferung |
| Workerabbruch | Absturz nach Auftragsspeicherung | Ausstehende Arbeit wiederherstellbar |
Prüfen Sie auch unbekannte Referenzen und fehlerhafte Signaturlängen. Zählen Sie gespeicherte Datensätze und externe Aktionen separat. HTTP 200 bestätigt den Empfang, nicht die Auslieferung.
Zahlung und Wirkung abgleichen
Speichern Sie Transaktions-ID, Kontobezug, Verarbeitungsstatus, Auftrag und externe Ergebnisreferenz. Untersuchen Sie bezahlte Transaktionen mit ausstehender Lieferung über denselben kontrollierten Weg statt durch eine zweite manuelle Lieferung außerhalb des Registers.
Beginnen Sie mit der PayRequest API-Dokumentation. Zahlungsabgleich liefert den finanziellen Kontext; Zahlung und Auslieferung bleiben separate Datensätze.
Redaktioneller Hinweis: KI unterstützte Artikel und Grafik. Vertrag am 4. Oktober 2026 geprüft. Schlüssel, Matrix und Architektur sind eigene Empfehlungen, kein Integrationstest und keine Liefergarantie.
