Flowglad, ein Open-Source-Zahlungsprozessor ohne Webhooks

 (github.com/flowglad)
2 Punkte von GN⁺ 2025-11-27 | 1 Kommentare | Auf WhatsApp teilen
  • Flowglad ist eine Open-Source-Plattform zur Zahlungsabwicklung, die ohne Webhooks arbeitet und es Entwicklern ermöglicht, Abrechnungs- und Zahlungsfunktionen mit minimalem Code zu integrieren
  • Durch eine stateless Architektur kann der Zahlungsstatus über die eigene Benutzer-ID abgefragt werden, ohne eine subscriptions-Tabelle oder die Verwaltung einer customer_id
  • Es wird ein Full-Stack-SDK bereitgestellt: im Backend mit flowgladServer.getBilling(), im Frontend mit dem Hook useBilling(), um den Kundenstatus in Echtzeit widerzuspiegeln
  • Preis-Modelle im Testmodus ausprobieren und mit einem Klick in die Produktion übernehmen; Tarifwechsel sind ohne erneutes Deployment der App möglich
  • Verringert die Komplexität und die Kosten der Zahlungsintegration, verbessert die Developer Experience (DX) und schafft die Grundlage dafür, Verbindungen zu verschiedenen Zahlungsanbietern über eine einzige Integration zu erweitern

Zentrale Funktionen

  • Stateless Aufbau, sodass Webhooks, Subscription-Tabellen, Kunden-IDs und die Verwaltung von Umgebungsvariablen nicht erforderlich sind
    • Flowglad verarbeitet Preise und Feature-Zuordnungen direkt, ohne dass diese manuell gepflegt werden müssen
  • Als Single Source of Truth lassen sich der aktuelle Abrechnungsstatus, Feature-Zugriffsrechte und Nutzungsguthaben eines Kunden abfragen
  • Unterstützt zugriffe auf Basis benutzerdefinierter IDs, sodass der Kundenstatus mit Benutzer- oder Organisations-IDs aus dem bestehenden Authentifizierungssystem abgefragt werden kann
  • Bietet ein Full-Stack-SDK
    • Aufruf von flowgladServer.getBilling() im Backend
    • Abbildung des Zahlungsstatus in Echtzeit im React-Frontend mit dem Hook useBilling()
  • Flexible Verwaltung von Preis-Modellen
    • Neue Tarife im Testmodus ausprobieren und mit einem Klick in die Produktion übernehmen
    • Tarife können ohne erneutes Deployment der App rotiert werden

Installation und Integration

  • Je nach Projekttyp die Pakete @flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server installieren
  • Beispiel für die Next.js-Integration
    • Eine FlowgladServer-Instanz erstellen und die eigene Kunden-ID übergeben
    • In API-Routen nextRouteHandler verwenden, um sicher mit Flowglad zu kommunizieren
    • FlowgladProvider zum Root-Layout hinzufügen, damit der Zahlungsstatus im Frontend automatisch geladen wird
  • Für B2C user.id, für B2B organization.id oder team.id als Kunden-ID verwenden
  • Flowglad erfordert weder eine separate Verwaltung von Kunden-IDs noch Änderungen am Authentifizierungssystem

Frontend-Beispiele

  • Mit dem Hook useBilling() den Feature-Zugriff (checkFeatureAccess) und die Nutzung (checkUsageBalance) prüfen
  • Bei eingeschränktem Feature-Zugriff eine Upgrade-Mitteilung anzeigen
  • Bei unzureichendem Nutzungsguthaben mit createCheckoutSession eine Zahlungssitzung erstellen

Backend-Beispiele

  • Mit flowglad(user.id).getBilling() serverseitig Feature-Zugriff und Nutzung prüfen
    • Beispiel: Verarbeitung verzweigen, nachdem der Zugriff auf das Feature fast_generations geprüft wurde
    • Beispiel: Fehler auslösen, wenn das Nutzungsguthaben für chat_messages nicht ausreicht

Erste Schritte

  • Im Dashboard mit einer Vorlage ein Preis-Modell erstellen
  • Verfügbare Vorlagentypen
    • Nutzungslimit + Subscription-Hybrid (ähnlich wie Cursor)
    • Unbegrenzte Nutzung (verbraucherorientiert wie ChatGPT)
    • Gestaffelter Zugriff + Nutzungsguthaben (ähnlich wie Midjourney)
    • Feature-Lock-Subscription (ähnlich wie Linear)
  • Bei Bedarf kann auch ohne Vorlage direkt ein Modell erstellt werden

Tech-Stack

  • Basierend auf Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase, Better Auth

Projektziel

  • Obwohl sich der Entwickler-Stack in den vergangenen 15 Jahren stark diversifiziert hat, gab es im Zahlungsbereich kaum Innovation
  • Bei den meisten Zahlungsdiensten muss selbst die Kontoeinrichtung über ein Vertriebsteam laufen, und Self-Service-Zahlungsoptionen sind rar
  • Dadurch stagniert die Verbesserung von Developer Experience (DX) und Kosten bei Zahlungslösungen
  • Flowglad will Zeit für Zahlungsintegration und Wartung minimieren und die Nutzung mehrerer Zahlungsanbieter über eine einzige Integration ermöglichen
  • Angesichts immer komplexerer Startup-Abrechnungsumgebungen durch die Verbreitung von KI will das Projekt eine entwicklerfreundliche Payment-Layer aufbauen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-27
Hacker-News-Kommentare

  • Ich verstehe nicht ganz, warum man das A) einen „payment processor“ nennt
    Es fühlt sich seltsam an, das so zu bezeichnen, wenn Zahlungen nicht direkt selbst verarbeitet werden
    Und B) heißt es zwar „open source“, aber offenbar läuft alles über SaaS und die Daten werden in ihrer DB gespeichert
    Ich verstehe das Problembewusstsein, weil ihr versucht, ein flexibles System für Feature-Gating, Nutzungsguthaben und Zahlungsschemata zu bauen, aber ich habe nicht das Gefühl, dass substanziell so viel geliefert wird, wie der Titel verspricht

    • Danke für das Verständnis, und ich würde gern hören, wie man das besser lösen könnte
      Beim Open-Source-Teil ist der SaaS-Bereich AGPLv3, der Rest steht unter der MIT-Lizenz
      Mit dem Ausdruck „processor“ wollten wir klar machen, dass wir nicht nur ein einfaches Billing-SaaS sind, sondern auch die Zahlungsabwicklung einschließen, selbst wenn wir Zahlungen über Stripe Connect verarbeiten
      Zum Beispiel kümmern wir uns zusammen mit dem Merchant um Chargeback-Probleme. Anders als bei einem SaaS, das nur Stripe-Keys verwendet, ist in unserer Struktur ein Chargeback für uns genauso direkt ein Thema wie für Stripe
    • In der Lizenzdatei sind zwei Lizenzen angegeben: MIT und AGPL

  • Das Produkt macht einige Dinge tatsächlich einfacher, aber ich bin nicht sicher, ob es wirklich besser ist
    Wenn man jedes Mal eine API-Anfrage an die Flowglad-Server schicken muss, um so etwas wie den Abo-Status eines Kunden zu prüfen, kann das die Reaktionsfähigkeit verschlechtern
    Häufig abgefragte Daten könnte man cachen, aber dann verliert diese Schicht an Bedeutung
    Die Stripe-Integration ist zwar mühsam, aber wenn lokal ohnehin nichts gespeichert wird, ist es meiner Meinung nach besser, einfach direkt die Stripe-API zu verwenden
    Ich fand einen in der DB gecachten Status viel praktischer — man kann komplexe Queries sofort absetzen
    In dieser Struktur muss man hoffen, dass Flowglad die benötigte API anbietet, und wenn nicht, muss man womöglich pro Kunde API-Anfragen schicken

    • Das stimmt
      Wir planen, Merchants zu ermöglichen, mehr Daten auf ihrer Seite zu speichern und trotzdem unser aufbereitetes Datenmodell und die Nutzbarkeit des SDKs weiter zu verwenden
      Selbst wenn man die Stripe-API direkt verwendet, muss man Price IDs, Pläne, Features und Customer-ID-Mappings selbst verwalten, und wir möchten genau diese Wiederholungsarbeit beseitigen
      Stripe ist ein write-zentriertes System und empfiehlt sich nicht als Echtzeit-Read-Layer (Dokumentation zu Stripe Rate Limits)
      Unser Ziel ist es, Entwicklern eine integrierte Payment- und Value-Movement-Erfahrung zu geben, ähnlich wie Shopify sie DTC-Marken geboten hat

  • Ich hatte es anfangs missverstanden, aber offenbar sind nur SDK und Code Open Source, während die eigentlichen Abrechnungsdaten an die Flowglad-Server gesendet werden, sodass man die Daten nicht direkt besitzt

    • Genau, der Titel ist in mehrfacher Hinsicht irreführend formuliert

  • Glückwunsch zum Beta-Launch!
    Ich hatte ein ähnliches Problem und habe deshalb eine Stripe-Integrationsbibliothek mit einer ähnlichen DX wie Flowgrad gebaut (wenn auch mit weniger Funktionen)
    Dazu, warum ich sie gebaut habe, gibt es auch einen Blogpost
    Der Hauptunterschied ist, wo die endgültigen Abrechnungsinformationen gespeichert werden — wir liefern ein DB-Schema und Webhook-Handler gleich mit, sodass alles in der lokalen DB landet
    Falls es hilfreich ist, kann ich auch unsere MIT-Open-Source-Bibliothek empfehlen

  • Glückwunsch zum Beta-Launch, ein beeindruckendes Produkt, daher erwäge ich eine Integration
    Ich frage mich aber, warum eine React-Abhängigkeit nötig ist
    Gab es keine Möglichkeit, die gewünschte UI auch ohne React umzusetzen?
    Wir setzen auf Svelte, deshalb ist es unpraktisch, wegen einer solchen Bibliothek React mit hereinzuziehen

    • Guter Punkt
      Wir haben mit React begonnen, weil wir uns damit am besten auskennen und die Community ebenfalls dort war
      Wir hängen nicht an React, und Support für Svelte und Vue soll bald folgen
      Sobald das Datenmodell und die Flows stabil sind, wollen wir das SDK auf andere Frameworks portieren
    • Wenn ihr euch für Svelte entschieden habt, werdet ihr solche Situationen häufig erleben
      Die React-Nutzerschaft ist 10- bis 50-mal größer, daher lässt sich diese Unbequemlichkeit kaum vermeiden
      React ist aber kein Framework, sondern eine Component-Rendering-Layer, daher kann man eine gut gekapselte externe Bibliothek auch innerhalb von Svelte problemlos verwenden

  • Das Design der Landingpage ist wirklich wunderschön gemacht
    Ich wollte nicht negativ wirken, ich fand es nur schade, dass es auf Stripe aufbaut

    • Mir hat es auch gefallen, es erinnert an zed.dev
    • Danke! Tatsächlich haben wir die Website bewusst als Single-Page gehalten
      Denn das vergangene Jahr haben wir in die Entwicklung der Billing-Engine, des Datenmodells und des SDK gesteckt

  • Webhooks sind beliebt, weil sie einfach, zuverlässig und praxiserprobt sind
    Wenn man sie verwendet, muss man aber möglicherweise separate Infrastruktur aufbauen, um Nutzung, Subscription-Tiers, Kündigungen usw. nachzuverfolgen

    • Webhooks sind gut für asynchrone Aufgaben oder Event-getriebene Domains, aber für Bereiche wie Zahlungen oder Autorisierung sind sie vielleicht nicht das beste Modell
      In einer idealen Welt sollte die Struktur so sein, dass sich aus Geldbewegungen automatisch ergibt, auf welche Funktionen ein Kunde Zugriff hat
      Shopify ist ein gutes Beispiel dafür — dort gibt es zwar Webhooks, aber sie sind nicht der zentrale Integrationspunkt
      Zahlungs-Webhooks waren ursprünglich eine hackige Notlösung, um komplexe Domain-Modellierungsprobleme zu umgehen

  • Es gibt bereits ein Projekt namens GNU Taler, ein System von echten Experten
    https://www.taler.net/en/
    Es zeichnet sich durch datenschutzorientierte Online-Zahlungen, Zahlungen ohne Registrierung, ein betrugssicheres Design, den Betrieb auf eigener Infrastruktur und freie Software aus

  • Ich frage mich, wie das in Bezug auf das Bankkonto des Merchants funktioniert
    Braucht man außer diesem Repository noch etwas anderes?

    • Genau, derzeit gibt es noch keine Möglichkeit, Acquiring-Bank-Partnerschaften selbst zu hosten
      Aktuell richten wir Merchant-Konten über Stripe Connect ein
      Wenn es sich um ein Unternehmen in einem Land handelt, in dem Stripe Merchant-Zahlungen unterstützt, kann man es sofort verwenden
      Langfristig planen wir eine tiefere Integration in den Zahlungsbereich
    • Man braucht weiterhin einen Zahlungsanbieter oder ein Merchant-Konto
      Strukturell ähnelt es anderen Gateway-Services, aber durch die zusätzliche Zwischengebühr könnten die Kosten pro Transaktion höher ausfallen

  • Es hieß, die Webhook-Events von Stripe seien mit über 250 Stück zu komplex, aber man muss nicht auf alle Events hören

    • Man muss aber selbst beurteilen, welche Events für den Business-Lifecycle der eigenen App wichtig sind
      Man muss sich zum Beispiel überlegen, wie charge.succeeded, payment_intent.succeeded und customer.subscription.created jeweils verarbeitet und Duplikate vermieden werden sollen
      Für eine saubere Stripe-Integration braucht man viel Detailwissen
    • Stripe ist von der UI bis zur API funktional übermäßig gewachsen
      Vor 10 Jahren habe ich es in 20 Minuten integriert, in letzter Zeit hat es einen ganzen Tag gedauert