Wie macht man eine Zahlungs- oder WhatsApp-Webhook idempotent?

Vergeben Sie für jeden Webhook eine eindeutige ID vom Absender, wie z. B. eine Bestell-ID oder Nachrichten-ID, und führen Sie die Nebenwirkungen nur einmal aus. Eine wiederholte Zustellung erkennt die bereits verarbeitete ID und tut nichts. Veröffentlichen Sie die eigentliche Arbeit in einer Warteschlange, anstatt sie inline auszuführen, damit der Absender nicht warten muss.

Warum kommen Webhooks mehr als einmal an?

Absender versuchen es bei Zeitüberschreitungen, Netzwerkproblemen und Nicht-2xx-Antworten erneut und bevorzugen eine doppelte Zustellung gegenüber keiner Zustellung. Sowohl Zahlungs-Gateways als auch WhatsApp verfahren so. Ein Handler, der bei jeder Zustellung reagiert, erzeugt doppelte Tickets, sendet Buchungsbestätigungen doppelt oder belastet zweimal.

Was sollte der Idempotenzschlüssel sein?

Verwenden Sie den Bezeichner, den der Absender über Wiederholungen hinweg garantiert stabil hält: die Bestell-ID für Zahlungs-Webhooks, die Nachrichten-ID für WhatsApp. Speichern Sie verarbeitete Schlüssel und prüfen Sie vor der Ausführung. Ein von Ihnen selbst pro Zustellung generierter Schlüssel funktioniert nicht, da jede Wiederholung wie ein neues Ereignis aussieht.

Warum in eine Warteschlange veröffentlichen, statt die Arbeit im Handler zu erledigen?

Ein Ticket zu erstellen und eine E-Mail inline zu senden, lässt das Gateway auf Arbeit warten, die ihm egal ist, was Zeitüberschreitungen und weitere Wiederholungen provoziert. Bestätigen Sie schnell, veröffentlichen Sie ein Zahlungsbestätigungs-Ereignis in RabbitMQ und lassen Sie einen Consumer die Arbeit erledigen. Eine wiederholte Zustellung veröffentlicht nur einmal; die zweite ist eine No-Op.

Wo wird das in der Praxis eingesetzt?

Bei FindYourVibe ist der Zahlungs-Webhook idempotent anhand der Bestell-ID und veröffentlicht vor der Ticketausgabe in RabbitMQ. Bei Trexind ist jeder WhatsApp-Webhook-Handler idempotent anhand der Nachrichten-ID, sodass eine wiederholte Zustellung den Status einmal aktualisiert, anstatt Buchungs- oder Abrechnungseffekte erneut auszulösen.

Wie testet man, ob ein Webhook idempotent ist?

Senden Sie dieselbe Nutzlast idealerweise gleichzeitig zweimal und prüfen Sie, dass die Nebenwirkung nur einmal auftrat: ein Ticket, eine Buchung, eine Belastung. Spielen Sie dann eine alte Nutzlast erneut ab, nachdem die erste vollständig verarbeitet wurde. Wenn eine Anzahl über eins liegt, gibt es einen Rennzustand beim Schlüssel-Check oder es fehlt eine eindeutige Einschränkung.

Ursprünglich veröffentlicht auf sakshamjain.codes/blog/idempotent-payment-and-whatsapp-webhooks. Brauchen Sie das umgesetzt? Sehen Sie meine Services auf NexoRush oder schreiben Sie mir.