Stripe

Kurz: Ein Zahlungsdienstleister für Online-Bezahlungen (Checkout, Abos, Webhooks) — bekannt für eine klare Trennung zwischen Test- und Live-Modus.

Genauer: Im Test-Modus lässt sich der komplette Checkout-Flow technisch identisch zum Live-Betrieb durchspielen (mit Test-Kreditkartennummern), ganz ohne vollständige Geschäftsverifizierung. Erst der Wechsel in den Live-Modus (echtes Geld) verlangt Nachweise wie Gewerbeanmeldung/Handelsregister.

Kontext bei uns: Läuft bei Emzett vorerst im Test-Modus weiter, weil noch kein Gewerbe angemeldet ist — die Checkout-Logik bleibt im Code bestehen, damit später nur die Keys getauscht werden müssen.

Im Detail

Stripe entstand 2010 aus der Beobachtung der Collison-Brüder, dass Online-Zahlungen für Entwickler unverhältnismäßig kompliziert waren — PCI-Compliance, Bankanbindungen und Betrugsprüfung mussten praktisch jedes Unternehmen einzeln neu lösen. Der Kerngedanke war eine Zahlungsintegration, die sich mit wenigen Zeilen Code einbinden lässt, während Stripe die gesamte regulatorische und sicherheitstechnische Komplexität darunter versteckt. Das hat sich zum Industriestandard entwickelt: viele SaaS-Produkte, Marktplätze und Abo-Dienste bauen heute direkt auf Stripe auf, statt eigene Zahlungsabwicklung zu entwickeln.

Stripe bildet den gesamten Zahlungsfluss über zwei Bausteine ab: den Checkout (eine von Stripe gehostete, PCI-konforme Zahlungsseite, auf die man den Kunden weiterleitet, statt selbst Kartendaten entgegenzunehmen) und Webhooks (asynchrone Benachrichtigungen, mit denen Stripe dem eigenen Server mitteilt, dass eine Zahlung wirklich abgeschlossen wurde). Das ist ein bewusstes Sicherheits- und Zuverlässigkeitsmuster: Der Redirect zurück auf die eigene Erfolgsseite nach der Zahlung ist NICHT der verlässliche Punkt, an dem man z. B. eine Bestellung als bezahlt markieren sollte — ein Kunde kann den Tab schließen, bevor der Redirect passiert, die Erfolgsseite manuell erneut aufrufen, oder ein Browser-Crash verhindert den Redirect komplett. Erst der signierte Webhook-Event (checkout.session.completed) ist die Quelle der Wahrheit, weil er direkt von Stripes Servern kommt und unabhängig vom Kundenbrowser zugestellt wird.

Webhook-Sicherheit

Ein häufiger Anfängerfehler: Webhook-Endpunkte ungeprüft zu vertrauen. Da die Webhook-URL öffentlich erreichbar sein muss (Stripe muss sie ja von außen aufrufen können), könnte theoretisch jeder eine gefälschte checkout.session.completed-Nachricht senden und sich damit eine „bezahlte“ Bestellung erschleichen. Stripe signiert deshalb jeden Webhook-Request mit einem HMAC-Signatur-Header (Stripe-Signature), den man serverseitig mit dem eigenen Webhook-Secret verifizieren muss, bevor man dem Inhalt überhaupt vertraut:

const sig = request.headers.get("stripe-signature")!
const event = stripe.webhooks.constructEvent(
  rawBody, // WICHTIG: der unveränderte Request-Body, nicht das geparste JSON
  sig,
  process.env.STRIPE_WEBHOOK_SECRET!,
)

Die Betonung auf „unveränderter Body“ ist kein Detail: Viele Frameworks parsen den Request-Body standardmäßig automatisch zu JSON, bevor eigener Code ihn sieht — die Signaturprüfung braucht aber exakt die Rohbytes, wie Stripe sie signiert hat, sonst schlägt die Verifikation fehl (ein klassischer Stolperstein bei der Stripe-Integration).

Idempotency Keys und Subscriptions

Ein weiterer wichtiger Baustein sind Idempotency Keys: Da Netzwerkfehler dazu führen können, dass ein Request doppelt ankommt (Client sendet erneut, weil die Antwort nicht ankam), lässt sich jedem kritischen Request wie „Zahlung abbuchen“ ein eindeutiger Schlüssel mitgeben — Stripe erkennt Duplikate daran und führt die Aktion garantiert nur einmal aus, egal wie oft derselbe Request ankommt.

const session = await stripe.checkout.sessions.create(
  { line_items, mode: "payment", success_url, cancel_url },
  { idempotencyKey: orderId },
)

Für wiederkehrende Zahlungen bietet Stripe einen eigenen mode: "subscription", der automatisch Abrechnungszyklen, anteilige Umstellungen (Proration bei Plan-Wechsel mitten im Zyklus) und fehlgeschlagene Zahlungsversuche (Dunning — automatische Wiederholungsversuche bei abgelaufener Karte) verwaltet, statt dass man diese Logik selbst nachbauen müsste.

Abgrenzung zu Alternativen

Im Vergleich zu PayPal bietet Stripe deutlich granularere APIs und bessere Entwicklerdokumentation, verzichtet aber auf PayPals riesige installierte Nutzerbasis (viele Kunden vertrauen eher einem bekannten PayPal-Button als einer unbekannten Kreditkarteneingabe). Adyen richtet sich eher an Großkunden mit sehr individuellen Anforderungen und komplexerer Vertragsgestaltung, während Stripe bewusst auf Self-Service ohne Vertragsverhandlung setzt. Mollie und Klarna sind im europäischen Raum stark bei lokalen Zahlungsmethoden (SEPA-Lastschrift, Sofortüberweisung, Rechnungskauf) — Stripe unterstützt zwar viele dieser Methoden mittlerweile auch, war aber ursprünglich stärker auf Kreditkarten fokussiert.

Für den Übergang von Test- zu Live-Modus gilt: beide Modi haben komplett getrennte API-Keys, Kunden, Produkte und Webhook-Endpunkte — es gibt keine Möglichkeit, Testdaten „hochzustufen“, ein Wechsel bedeutet praktisch einen sauberen Neustart mit den Live-Keys.

Siehe auch: Environment Variables, JSON