Stripe + AWS EventBridge: Warum Webhooks Geschichte sind

Wenn Sie Stripe in Ihre Anwendung integrieren, stehen Sie früher oder später vor der Frage: Wie verarbeite ich Payment-Events? Die klassische Antwort lautet Webhooks. Aber seit Stripe eine native Integration mit Amazon EventBridge anbietet, gibt es eine deutlich bessere Lösung – vor allem, wenn Sie bereits auf AWS setzen.

Das Problem mit klassischen Webhooks

Webhooks klingen einfach: Stripe schickt einen HTTP-Request an Ihren Endpoint, Sie verarbeiten ihn. In der Praxis bedeutet das aber:

• Sie brauchen einen öffentlich erreichbaren Server, der 24/7 läuft
• Sie müssen Webhook-Signaturen verifizieren (Sicherheit)
• Sie müssen Retry-Logik implementieren, falls Ihr Server mal nicht erreichbar ist
• Sie müssen idempotente Verarbeitung sicherstellen (doppelte Events)
• Sie müssen den Endpoint überwachen, skalieren und absichern

Das ist eine Menge Infrastruktur-Overhead für etwas, das eigentlich eine einfache Aufgabe sein sollte: "Wenn ein Kunde bezahlt hat, tue X."

Die Lösung: Stripe Event Destinations mit EventBridge

Stripe bietet seit 2023 sogenannte Event Destinations an. Statt Events an einen Webhook-Endpoint zu schicken, können Sie Stripe anweisen, Events direkt an Amazon EventBridge zu senden. Das klingt nach einem kleinen Unterschied – ist aber ein fundamentaler Architekturwechsel.

Was ist Amazon EventBridge?

EventBridge ist ein serverloser Event-Bus von AWS. Denken Sie an eine zentrale Drehscheibe für Events: Verschiedene Quellen schicken Events rein (Stripe, Ihre eigene App, andere AWS-Services), und Sie definieren Regeln, welche Events wohin weitergeleitet werden.

Die Ziele können sein:

• AWS Lambda – Serverlose Funktionen für die Verarbeitung
• AWS Step Functions – Komplexe Workflows orchestrieren
• Amazon SQS – Events in eine Queue zur späteren Verarbeitung
• Amazon SNS – Benachrichtigungen auslösen
• Amazon CloudWatch – Logging und Monitoring

Einrichtung in 3 Schritten

Die Einrichtung ist überraschend einfach:

Schritt 1: Event Destination in Stripe anlegen

Im Stripe Dashboard unter "Entwickler → Ereignisziele" wählen Sie als Zieltyp "Amazon EventBridge" statt "Webhook-Endpoint". Stripe fragt nach Ihrer AWS Account ID und der gewünschten Region.

Schritt 2: Event Source in AWS bestätigen

In der AWS Console taucht unter EventBridge → Partner Event Sources automatisch eine neue Quelle von Stripe auf. Diese müssen Sie mit einem Klick bestätigen und einem Event Bus zuordnen.

Schritt 3: Regeln und Ziele definieren

Jetzt definieren Sie EventBridge Rules: Welche Stripe-Events sollen welche Aktion auslösen? Zum Beispiel:

• payment_intent.succeeded → Lambda-Funktion für Auftragsbestätigung
• customer.subscription.deleted → Step Function für Churn-Workflow
• invoice.payment_failed → SNS-Benachrichtigung an das Team

Warum EventBridge besser ist als Webhooks

1. Kein Server nötig

Der offensichtlichste Vorteil: Sie brauchen keinen öffentlich erreichbaren Endpoint. Kein Server, kein Container, keine Firewall-Regeln. EventBridge empfängt die Events und leitet sie an serverlose Ziele weiter. Das reduziert Ihre Angriffsfläche auf null.

2. Automatische Skalierung

Black Friday, Flash Sale, plötzlich 10x mehr Bestellungen? EventBridge skaliert automatisch. Kein Capacity Planning, kein Server-Tuning. Lambda-Funktionen starten parallel, SQS puffert bei Bedarf. Sie zahlen nur für das, was tatsächlich verarbeitet wird.

3. Eingebaute Zuverlässigkeit

Bei Webhooks müssen Sie Retries selbst implementieren und sicherstellen, dass keine Events verloren gehen. EventBridge hat eingebautes Retry-Verhalten, Dead-Letter Queues und Event Archiving. Wenn ein Ziel nicht erreichbar ist, wird das Event automatisch erneut zugestellt – bis zu 24 Stunden lang.

4. Event-Routing statt If-Else-Logik

Ein klassischer Webhook-Endpoint sieht oft so aus: Eine riesige switch-Anweisung, die je nach Event-Typ verschiedene Funktionen aufruft. Mit EventBridge definieren Sie stattdessen deklarative Regeln. Jeder Event-Typ bekommt sein eigenes Ziel. Das ist sauberer, testbarer und einfacher zu warten.

5. Fan-Out: Ein Event, viele Aktionen

Ein payment_intent.succeeded Event soll gleichzeitig eine Bestätigungsmail senden, den Lagerbestand aktualisieren und die Buchhaltung informieren? Mit Webhooks müssten Sie das alles in einem Endpoint verarbeiten oder selbst eine Event-Verteilung bauen. EventBridge kann ein Event an bis zu 5 Ziele gleichzeitig weiterleiten – out of the box.

6. Keine Signatur-Verifizierung nötig

Bei Webhooks müssen Sie jede Anfrage kryptografisch verifizieren, um sicherzustellen, dass sie wirklich von Stripe kommt. Bei EventBridge entfällt das komplett: Die Events kommen über eine vertrauenswürdige AWS-interne Verbindung. IAM-Policies regeln den Zugriff.

Praxisbeispiel: Subscription-Management

Ein typisches Szenario, das wir bei codehero für Kunden umsetzen:

Ein SaaS-Produkt mit Stripe Billing. Kunden können Abos abschließen, upgraden, kündigen. Was passiert im Hintergrund?

1. customer.subscription.created → Lambda provisioniert den Zugang (z.B. Feature Flags setzen, Datenbank aktualisieren)
2. customer.subscription.updated → Lambda passt Plan-Limits an
3. invoice.payment_failed → Step Function startet Dunning-Workflow (Erinnerungsmail → 3 Tage warten → zweite Mail → 7 Tage warten → Abo pausieren)
4. customer.subscription.deleted → Lambda entzieht Zugang + SNS benachrichtigt Customer Success Team

Alles serverlos. Keine Server zu managen, keine Skalierungsprobleme, keine Ausfälle weil ein Container abgestürzt ist. Die Kosten? Für die meisten SaaS-Anwendungen unter 5 Euro pro Monat.

Architektur im Überblick

Die Architektur ist elegant in ihrer Einfachheit:

Stripe sendet Events über die native Partnerintegration direkt an Amazon EventBridge. Von dort können die Events an verschiedene AWS-Services weitergeleitet werden: AWS Lambda für schnelle Verarbeitung, Step Functions für komplexe Workflows, SQS für asynchrone Queues, SNS für Benachrichtigungen und CloudWatch für Monitoring.

Das Besondere: Jeder dieser Pfade funktioniert unabhängig voneinander. Wenn die Lambda-Funktion für die E-Mail-Bestätigung fehlschlägt, läuft die Bestandsaktualisierung trotzdem weiter. Isolation by Design.

Vergleich: Webhook vs. EventBridge

Infrastructure as Code mit AWS CDK

Natürlich setzen wir die EventBridge-Regeln nicht manuell in der Console auf. Mit AWS CDK (Cloud Development Kit) definieren wir die gesamte Infrastruktur als TypeScript-Code:

Eine EventBridge Rule matcht auf bestimmte Stripe Event-Typen und leitet sie an eine Lambda-Funktion weiter. Die Lambda-Funktion enthält die Geschäftslogik – z.B. die Verarbeitung einer erfolgreichen Zahlung. Das Ganze wird als CDK Stack deployt und ist damit versioniert, reviewbar und reproduzierbar.

Das bedeutet: Ihre Payment-Infrastruktur ist genauso versioniert und reviewbar wie Ihr Anwendungscode. Pull Requests für Infrastruktur – genau wie es sein sollte.

Wann Webhooks trotzdem Sinn machen

Fairerweise: Es gibt Szenarien, in denen klassische Webhooks die bessere Wahl bleiben:

• Sie nutzen kein AWS (EventBridge ist AWS-exklusiv)
• Ihr Monolith verarbeitet alles in einer Anwendung (z.B. Rails, Django) und Sie wollen keine zusätzliche Infrastruktur
• Sie haben einen einfachen Use Case mit wenigen Event-Typen

Aber sobald Sie auf AWS setzen und mehr als nur "Zahlung eingegangen → Mail senden" verarbeiten, ist EventBridge der klar überlegene Ansatz.

Fazit: Die perfekte Ehe zwischen Stripe und AWS

Stripe und AWS EventBridge sind wie füreinander gemacht. Stripe liefert die Payment-Events, EventBridge verteilt sie, und serverlose AWS-Services verarbeiten sie. Kein Server, kein Overhead, keine Sorgen um Skalierung.

Bei codehero setzen wir diese Architektur für alle neuen Payment-Integrationen ein. Das Ergebnis: Weniger Code, weniger Infrastruktur, weniger Fehlerquellen – und mehr Zeit für die Geschäftslogik, die wirklich zählt.

Sie planen eine Stripe-Integration auf AWS? Wir beraten Sie gerne, welche Architektur für Ihren Use Case am besten passt.

→ Jetzt Beratungsgespräch vereinbaren