Alle Projekte
Automation

Stripe-Zahlungen zu Rechnungen

Sieben n8n-Workflows machen aus Stripe-Zahlungen deutsche Rechnungen (E-Mail mit PDF) und eine Telegram-Nachricht. Keine doppelte Rechnung, kein verlorenes Ereignis.

Live-Demo folgtGitHubDokumentation

Problem

Stripe sendet Zahlungsereignisse per Webhook, auch doppelt, und erwartet eine schnelle Antwort. Bestätigt ein Webhook ein Ereignis, bevor es gespeichert ist, geht es bei einem Datenbankausfall verloren. Verarbeitet er dasselbe Ereignis zweimal, entstehen doppelte Rechnungen und Nachrichten. Und Fehler bleiben unbemerkt, wenn niemand alarmiert wird.

Lösung

Der Intake prüft die Stripe-Signatur (HMAC-SHA256) und lehnt Zeitstempel ab, die älter als 5 Minuten sind. Er antwortet erst, nachdem das Ereignis gespeichert ist; schlägt das Speichern fehl, antwortet er mit 500, sodass Stripe es erneut zustellt.

Ein Processor holt jede Minute bis zu 10 Ereignisse atomar ab (FOR UPDATE SKIP LOCKED). Pro bezahltem Ereignis entsteht genau eine Rechnung, abgesichert durch UNIQUE-Constraints in PostgreSQL. E-Mail, PDF und Telegram-Nachricht werden nur aus der gespeicherten Rechnungszeile erzeugt, sodass jeder Wiederholungsversuch dasselbe Dokument liefert.

Ein Monitor-Workflow meldet tote oder hängende Ereignisse per Telegram und E-Mail; ein fehlgeschlagenes Ereignis lässt sich mit Begründung und Protokolleintrag erneut verarbeiten. Ein externer Heartbeat meldet, wenn das System etwa 15 Minuten lang schweigt.

Architektur

Ablaufdiagramm: Stripe sendet an den Intake, der signiert prüft und in stripe_events speichert (400 bei falscher Signatur, 200 bei Erfolg oder Duplikat, 500 wenn das Speichern fehlschlägt). Der Processor erstellt jede Minute die Rechnung, daraus entstehen E-Mail mit PDF und Telegram-Nachricht.

Ergebnisse

54

End-to-End-Prüfungen in einem Skript, nach jeder Änderung ausgeführt

Beleg
384

Fälle am echten Processor-Graphen geprüft

Beleg
1

Rechnung, E-Mail und Telegram-Nachricht pro Zahlung, auch wenn Stripe das Ereignis erneut sendet

Beleg
7

n8n-Workflows, als TypeScript-Quelldateien versioniert

Beleg

Tech-Stack

  • n8n
  • PostgreSQL
  • TypeScript (n8n Workflow SDK)
  • Docker Compose (WSL)
  • Gotenberg
  • Mailpit
  • Telegram Bot API
  • Healthchecks.io
  • Stripe
  • PowerShell

Screenshots

Die Rechnungs-E-Mail einer Demo-Zahlung mit PDF-Anhang (Mailpit, das lokale Postfach).
Die Rechnungs-E-Mail einer Demo-Zahlung mit PDF-Anhang (Mailpit, das lokale Postfach).
Das angehängte PDF: ein fiktiver Shop, 30,00 EUR aufgeteilt in Netto und 19 % USt., als bezahlt markiert, mit Demo-Hinweis in der Fußzeile.
Das angehängte PDF: ein fiktiver Shop, 30,00 EUR aufgeteilt in Netto und 19 % USt., als bezahlt markiert, mit Demo-Hinweis in der Fußzeile.
Der Telegram-Chat des Betreibers nach einer Demo-Zahlung: die Nachricht mit Kunde, Zahlungsart und Rechnungsnummer, danach das PDF als Dokument.
Der Telegram-Chat des Betreibers nach einer Demo-Zahlung: die Nachricht mit Kunde, Zahlungsart und Rechnungsnummer, danach das PDF als Dokument.

Läuft nur in der Stripe-Sandbox auf meinem eigenen Rechner. Die Rechnungen sind eine technische Demo und beanspruchen keine Konformität mit § 14 UStG oder GoBD. Das Repository lässt sich noch nicht frisch klonen und starten; das ist der nächste Schritt.