Flowglad, un processeur de paiement open source sans webhooks

 (github.com/flowglad)
2 points par GN⁺ 2025-11-27 | 1 commentaires | Partager sur WhatsApp
  • Flowglad est une plateforme open source de traitement des paiements qui fonctionne sans webhooks, avec une architecture permettant aux développeurs d’intégrer la facturation et les paiements avec un minimum de code
  • Grâce à une architecture stateless, il est possible de consulter l’état des paiements via ses propres identifiants utilisateur, sans table subscriptions ni gestion de customer_id
  • Un SDK full-stack est fourni : côté backend, flowgladServer.getBilling() ; côté frontend, le hook useBilling() permet de refléter en temps réel l’état du client
  • Il est possible d’expérimenter des modèles tarifaires en mode test puis de les déployer en production en un clic, avec changement de plan sans redéployer l’application
  • En réduisant la complexité et le coût de l’intégration des paiements, la plateforme améliore l’expérience développeur (DX) et pose les bases d’une extension vers différents fournisseurs de paiement via une intégration unique

Fonctionnalités principales

  • Une architecture stateless qui évite le besoin de webhooks, de table d’abonnements, d’ID client ou de gestion de variables d’environnement
    • Flowglad gère directement les tarifs et le mapping des fonctionnalités, sans gestion manuelle
  • Une source unique de vérité (Single Source of Truth) pour consulter le dernier état de facturation du client, les droits d’accès aux fonctionnalités et les crédits d’usage
  • Une approche basée sur des identifiants personnalisés, permettant d’interroger l’état du client avec les ID utilisateur ou organisation déjà présents dans le système d’authentification
  • Un SDK full-stack
    • Appel de flowgladServer.getBilling() côté backend
    • Utilisation du hook useBilling() dans un frontend React pour refléter en temps réel l’état du paiement
  • Une gestion flexible des modèles tarifaires
    • Tester de nouveaux plans en mode test et les appliquer en production en un clic
    • Faire évoluer les offres sans redéployer l’application

Installation et intégration

  • Installer les packages @flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server selon le type de projet
  • Exemple d’intégration Next.js
    • Créer une instance FlowgladServer en lui transmettant son propre ID client
    • Utiliser nextRouteHandler dans une route API pour communiquer de façon sécurisée avec Flowglad
    • Ajouter FlowgladProvider au layout racine afin de charger automatiquement l’état de facturation côté frontend
  • En B2C, utiliser user.id ; en B2B, organization.id ou team.id comme ID client
  • Flowglad n’exige ni gestion séparée des ID client ni modification du système d’authentification

Exemple frontend

  • Vérifier l’accès aux fonctionnalités (checkFeatureAccess) et l’usage (checkUsageBalance) avec le hook useBilling()
  • Afficher un message invitant à monter en gamme si l’accès à une fonctionnalité est restreint
  • Si l’usage disponible est insuffisant, créer une session de paiement avec createCheckoutSession

Exemple backend

  • Vérifier côté serveur l’accès aux fonctionnalités et l’usage avec flowglad(user.id).getBilling()
    • Exemple : bifurquer le traitement après vérification de l’accès à la fonctionnalité fast_generations
    • Exemple : générer une erreur si les crédits d’usage chat_messages sont insuffisants

Pour commencer

  • Créer un modèle tarifaire à partir d’un template dans le tableau de bord
  • Types de templates proposés
    • Limite d’usage + abonnement hybride (similaire à Cursor)
    • Usage illimité (type grand public de ChatGPT)
    • Accès par niveaux + crédits d’usage (similaire à Midjourney)
    • Abonnement avec fonctionnalités verrouillées (similaire à Linear)
  • Il est aussi possible de créer directement un modèle sans template si nécessaire

Stack technique

  • Basé sur Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase, Better Auth

Objectif du projet

  • Ces 15 dernières années, la stack de développement s’est diversifiée, mais l’innovation dans les paiements a été quasi inexistante
  • La plupart des services de paiement imposent encore de passer par une équipe commerciale, même pour configurer un compte, avec peu d’options de paiement en self-service
  • Résultat : l’amélioration de l’expérience développeur (DX) et des coûts liés aux paiements est restée au point mort
  • Flowglad vise à minimiser le temps consacré à l’intégration et à la maintenance des paiements, tout en permettant d’utiliser plusieurs prestataires via une intégration unique
  • Face à des environnements de facturation de startup de plus en plus complexes avec la généralisation de l’IA, le projet veut construire une couche de paiement pensée pour les développeurs

À lire aussi

1 commentaires

 
GN⁺ 2025-11-27
Avis Hacker News

  • Je ne comprends pas vraiment pourquoi on appelle ça A) un « payment processor »
    Ça paraît étrange de l’appeler ainsi si le produit ne traite pas directement les paiements
    Et B) on parle d’« open source », mais tout semble tourner via un SaaS et les données semblent stockées dans leur base de données
    Je comprends bien le problème qu’ils essaient de résoudre en construisant un système flexible pour les feature gates, les crédits d’usage et les schémas de paiement, mais j’ai l’impression que la réalité ne tient pas vraiment la promesse du titre

    • Merci, j’apprécie la remarque, et je serais curieux d’avoir des avis sur une meilleure façon de résoudre ça
      Concernant l’open source, la partie SaaS est sous AGPLv3 et le reste sous licence MIT
      Pour le terme « processor », on voulait préciser que, même si nous passons par Stripe Connect pour traiter les paiements, nous allons au-delà d’un simple SaaS de facturation et couvrons aussi le traitement des paiements
      Par exemple, nous nous préoccupons des chargebacks aux côtés des marchands. Contrairement à un SaaS qui se contente d’utiliser des clés Stripe, dans notre architecture les chargebacks deviennent aussi un enjeu direct pour nous, comme chez Stripe
    • Le fichier de licence mentionne bien deux licences, MIT et AGPL

  • Ce produit rend effectivement certaines choses plus simples, mais je ne sais pas si c’est vraiment meilleur
    Si l’architecture impose d’envoyer une requête API aux serveurs de Flowglad chaque fois qu’on veut vérifier, par exemple, le statut d’abonnement d’un client, la réactivité risque d’en souffrir
    On peut certes mettre en cache les données souvent consultées, mais dans ce cas l’intérêt de cette couche diminue
    L’intégration Stripe est pénible, mais si rien n’est stocké en local, je pense qu’il vaut mieux utiliser directement l’API Stripe
    J’ai trouvé bien plus pratique d’avoir un état mis en cache dans la base de données — on peut lancer immédiatement des requêtes complexes
    Avec cette architecture, il faut espérer que Flowglad fournisse l’API nécessaire, sinon on pourrait devoir envoyer une requête API par client

    • C’est juste
      Nous comptons permettre aux marchands de stocker davantage de données côté local tout en conservant notre modèle de données affiné et l’ergonomie du SDK
      Même en utilisant directement l’API Stripe, il faut gérer soi-même les mappings entre price id, plan, feature et customer id, et nous voulons éliminer ce travail répétitif
      Stripe est un système orienté écriture et ne recommande pas de l’utiliser comme couche de lecture en temps réel (documentation Stripe sur les rate limits)
      Notre objectif est d’offrir aux développeurs une expérience unifiée de paiement + transfert de valeur, comme Shopify l’a fait pour les marques DTC

  • Au début j’avais mal compris : seuls le SDK et le code sont open source, tandis que les données de facturation sont réellement envoyées aux serveurs de Flowglad, donc on n’a pas vraiment la maîtrise directe des données

    • Exact, le titre est trompeur à plusieurs égards

  • Félicitations pour la bêta !
    J’ai rencontré un problème similaire, alors j’ai créé une bibliothèque d’intégration Stripe avec une DX proche de Flowgrad (même si elle est moins riche fonctionnellement)
    J’ai aussi écrit un billet de blog expliquant pourquoi je l’ai fait
    La principale différence est l’endroit où sont stockées les informations de facturation finales — nous fournissons à la fois le schéma de base de données et les gestionnaires de webhook pour enregistrer cela dans une base locale
    Au cas où cela serait utile, je recommande aussi notre bibliothèque open source sous licence MIT

  • Félicitations pour la bêta, le produit est impressionnant et j’envisage de l’intégrer
    En revanche, je me demande pourquoi une dépendance à React est nécessaire
    N’y avait-il pas moyen de proposer l’UI souhaitée sans React ?
    Nous sommes sur une base Svelte, donc devoir faire venir React à cause de ce type de bibliothèque est gênant

    • Bonne remarque
      Nous avons commencé avec React parce que c’était ce que nous connaissions le mieux et que la communauté était surtout là
      Nous ne sommes pas attachés à React, et le support de Svelte et Vue devrait arriver bientôt
      Une fois le modèle de données et les flows stabilisés, nous prévoyons de porter le SDK vers d’autres frameworks
    • Si vous avez choisi Svelte, ce genre de situation va vous arriver souvent
      La base d’utilisateurs de React est 10 à 50 fois plus grande, donc ce type de contrainte est difficile à éviter
      Mais React n’est pas un framework, c’est une couche de rendu de composants, donc une bibliothèque externe bien encapsulée peut très bien fonctionner dans Svelte

  • Le design de la landing page est vraiment magnifique
    Je ne voulais pas paraître négatif, j’étais simplement déçu que ce soit construit au-dessus de Stripe

    • Moi aussi, j’ai aimé, ça m’a fait penser à zed.dev
    • Merci ! En réalité, nous avons volontairement gardé le site en page unique
      Parce que nous avons passé l’année écoulée à développer le moteur de facturation, le modèle de données et le SDK

  • Les webhooks sont populaires parce qu’ils sont simples, fiables et qu’ils fonctionnent bien
    Mais en les utilisant, il faut parfois construire une infrastructure séparée pour suivre l’usage, les niveaux d’abonnement, les annulations, etc.

    • Les webhooks conviennent aux tâches asynchrones ou aux domaines orientés événements, mais ils ne sont peut-être pas le meilleur modèle pour des domaines comme le paiement ou l’autorisation
      Dans un monde idéal, quand de l’argent circule, les fonctionnalités accessibles au client devraient être déterminées automatiquement en conséquence
      Shopify en est un bon exemple — il y a des webhooks, mais ce n’est pas le point d’intégration principal
      Les webhooks de paiement étaient à l’origine une solution de contournement un peu bricolée pour éviter un problème complexe de modélisation métier

  • Il existe déjà un projet appelé GNU Taler, conçu par de vrais experts
    https://www.taler.net/en/
    Ses points forts sont les paiements en ligne centrés sur la protection de la vie privée, les paiements sans inscription, une conception anti-fraude, la possibilité d’exploiter sa propre infrastructure, et le fait d’être un logiciel libre

  • Je me demande comment cela fonctionne du point de vue du compte bancaire du marchand
    Faut-il autre chose que ce dépôt ?

    • Exact, il n’existe pas encore de moyen d’auto-héberger les partenariats avec des banques acquéreuses
      Pour l’instant, les comptes marchands sont configurés via Stripe Connect
      Si votre société est enregistrée dans un pays où Stripe prend en charge les paiements marchands, cela fonctionne immédiatement
      À long terme, nous prévoyons une intégration plus profonde sur la partie paiement
    • Il faut toujours un prestataire de paiement ou un compte marchand
      Structurellement, cela ressemble aux autres services de passerelle, mais avec des frais intermédiaires supplémentaires, donc le coût par transaction peut être plus élevé

  • Il a été dit que les événements webhook de Stripe sont complexes parce qu’il y en a plus de 250, mais il n’est pas nécessaire de tous les écouter

    • Certes, mais il faut quand même déterminer soi-même quels événements comptent dans le cycle de vie métier de son application
      Par exemple, il faut réfléchir à la manière de traiter charge.succeeded, payment_intent.succeeded et customer.subscription.created, et à la façon d’éviter les doublons
      Il faut beaucoup de connaissance fine pour bien intégrer Stripe
    • Stripe est devenu excessivement étendu en fonctionnalités, de l’interface utilisateur jusqu’à l’API
      Il y a 10 ans, je l’intégrais en 20 minutes ; récemment, cela m’a pris une journée entière