- Flowglad es una plataforma open source de procesamiento de pagos que funciona sin webhooks, con una estructura que permite a los desarrolladores integrar funciones de facturación y pagos con un mínimo de código
- Mediante una arquitectura stateless, es posible consultar el estado de pago con el propio ID de usuario, sin una tabla de
subscriptions ni gestión de customer_id
- Ofrece un SDK full-stack: en el backend,
flowgladServer.getBilling(), y en el frontend, el hook useBilling() para reflejar el estado del cliente en tiempo real
- Permite probar modelos de precios en modo de prueba y aplicarlos a producción con un clic, además de cambiar planes sin volver a desplegar la app
- Reduce la complejidad y el costo de integrar pagos, mejora la experiencia de desarrollador (DX) y sienta las bases para ampliar la conexión con distintos proveedores de pago mediante una sola integración
Funciones principales
- Estructura stateless que elimina la necesidad de webhooks, tablas de suscripción, IDs de cliente y gestión de variables de entorno
- Flowglad lo maneja directamente, sin tener que administrar manualmente el mapeo entre precios y funciones
- Como fuente única de verdad (Single Source of Truth), permite consultar el estado de facturación más reciente del cliente, los permisos de acceso a funciones y los créditos de uso
- Soporta acceso basado en IDs personalizados, para consultar el estado del cliente usando los IDs de usuario u organización del sistema de autenticación existente
- Incluye un SDK full-stack
- Llamada a
flowgladServer.getBilling() en el backend
- Reflejo del estado de pago en tiempo real con el hook
useBilling() en el frontend de React
- Gestión flexible de modelos de precios
- Se pueden probar nuevos planes en modo de prueba y llevarlos a producción con un clic
- Es posible rotar planes sin volver a desplegar la app
Instalación e integración
- Instala los paquetes
@flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server según el tipo de proyecto
- Ejemplo de integración con Next.js
- Crea una instancia de
FlowgladServer y pasa tu propio ID de cliente
- Usa
nextRouteHandler en la ruta API para comunicarte de forma segura con Flowglad
- Agrega
FlowgladProvider al layout raíz para cargar automáticamente el estado de pago en el frontend
- En B2C se usa
user.id; en B2B, organization.id o team.id como ID de cliente
- Flowglad no exige gestionar un ID de cliente por separado ni modificar el sistema de autenticación
Ejemplo en frontend
- Con el hook
useBilling() se verifica el acceso a funciones (checkFeatureAccess) y el uso disponible (checkUsageBalance)
- Si el acceso a una función está restringido, se muestra un mensaje para invitar al usuario a mejorar su plan
- Si no hay suficiente uso disponible, se crea una sesión de pago con
createCheckoutSession
Ejemplo en backend
- Con
flowglad(user.id).getBilling() se validan en el servidor el acceso a funciones y el uso disponible
- Ejemplo: ramificar el procesamiento tras verificar el acceso a la función
fast_generations
- Ejemplo: generar un error si faltan créditos de uso para
chat_messages
Primeros pasos
- Crea un modelo de precios con plantillas desde el dashboard
- Tipos de plantilla disponibles
- Híbrido de límite de uso + suscripción (similar a Cursor)
- Uso ilimitado (tipo consumidor de ChatGPT)
- Acceso por niveles + créditos de uso (similar a Midjourney)
- Suscripción con funciones bloqueadas (similar a Linear)
- Si hace falta, también puedes crear un modelo directamente sin usar plantillas
Stack técnico
- Basado en Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase, Better Auth
Objetivo del proyecto
- Aunque el stack de desarrollo se ha diversificado en los últimos 15 años, casi no ha habido innovación en el área de pagos
- La mayoría de los servicios de pago requieren incluso pasar por el equipo comercial para configurar una cuenta, y faltan opciones de pago self-service
- Como resultado, la experiencia de desarrollador (DX) y la reducción de costos en pagos se han estancado
- Flowglad busca minimizar el tiempo de integración y mantenimiento de pagos, y permitir usar varios proveedores de pago con una sola integración
- En un entorno de facturación para startups cada vez más complejo por la expansión de la IA, apunta a construir una capa de pagos amigable para desarrolladores
1 comentarios
Comentarios en Hacker News
No entiendo muy bien por qué llaman a esto A) un “payment processor”
se siente raro llamarlo así si en realidad no procesa pagos directamente
y además B) dicen que es “open source”, pero parece que todo corre a través de su SaaS y los datos también se guardan en su BD
Entiendo la intención de resolver el problema, porque están intentando construir un sistema flexible para feature gates, créditos de uso y esquemas de pago, pero no siento que entregue en la práctica tanto como promete el título
En cuanto a open source, la parte SaaS es AGPLv3 y el resto es licencia MIT
Con la palabra “processor” queríamos dejar claro que, aunque procesamos pagos vía Stripe Connect, esto incluye procesamiento de pagos y no es solo un SaaS de facturación
Por ejemplo, junto con los comercios nos preocupamos por el tema de los chargebacks. A diferencia de un SaaS que solo usa claves de Stripe, en nuestra estructura los chargebacks también se vuelven un problema directo para nosotros, igual que para Stripe
Sí hace que algunas cosas sean fáciles, pero no sé si realmente sean mejores
Si la estructura implica enviar una solicitud API al servidor de Flowglad cada vez que quieras revisar algo como el estado de suscripción de un cliente, la capacidad de respuesta puede verse afectada
Podrías cachear los datos a los que accedes con frecuencia, pero entonces esta capa pierde parte de su sentido
Integrar Stripe es complicado, pero si no vas a guardar nada localmente, me parece mejor usar directamente la API de Stripe
A mí me resultó mucho más cómodo tener el estado cacheado en una BD: así puedes lanzar consultas complejas de inmediato
En esta estructura dependes de que Flowglad exponga la API que necesitas, y si no, quizá termines haciendo solicitudes API por cada cliente
Planeamos permitir que el comercio almacene más datos de su lado, sin perder el modelo de datos refinado y la usabilidad del SDK que construimos
Incluso si usas la API de Stripe directamente, igual tienes que manejar por tu cuenta los mapeos de price id, plan, feature y customer id, y queremos eliminar ese trabajo repetitivo
Stripe es un sistema orientado a escritura, así que no recomienda usarlo como capa de lectura en tiempo real (documentación de Stripe rate limits)
Nuestro objetivo es dar a los desarrolladores una experiencia unificada de pagos + movimiento de valor, como la que Shopify ofreció a las marcas DTC
Al principio lo entendí mal, pero parece que solo el SDK y el código son open source, y los datos reales de facturación se envían a los servidores de Flowglad, así que en realidad no puedes ser dueño directo de tus datos
¡Felicidades por la beta!
Yo pasé por un problema parecido, así que construí una librería de integración con Stripe con una DX similar a la de Flowgrad (aunque con menos funciones)
También tengo una entrada de blog sobre por qué la hice
La diferencia principal es dónde se guarda la información final de facturación: nosotros incluimos el esquema de BD y los handlers de webhooks para registrarla en la BD local
Por si sirve, también recomiendo nuestra librería open source con licencia MIT
Felicidades por la beta, se ve como un producto impresionante y estoy considerando integrarlo
Pero me da curiosidad por qué requiere una dependencia de React
¿No había forma de implementar la UI deseada sin React?
Nosotros usamos Svelte, así que es incómodo tener que traer React por una librería así
Empezamos con React porque era con lo que más cómodos estábamos y donde estaba nuestra comunidad
No estamos aferrados a React, y pronto agregaremos soporte para Svelte y Vue
Cuando el modelo de datos y los flujos estén estables, planeamos portar el SDK a otros frameworks
La base de usuarios de React es entre 10 y 50 veces mayor, así que es difícil evitar estas incomodidades
Pero React no es un framework sino una capa de renderizado de componentes, así que una librería externa bien encapsulada puede usarse dentro de Svelte sin problema
El diseño de la landing page está realmente hermoso
No quería sonar negativo, solo me decepcionó que estuviera construido sobre Stripe
porque el último año lo dedicamos a desarrollar el motor de facturación, el modelo de datos y el SDK
Los webhooks son populares porque son simples, confiables y funcionan bien
Pero si usas esto, quizá igual tengas que construir infraestructura aparte para rastrear uso, niveles de suscripción, cancelaciones, etc.
En un mundo ideal, si el dinero se mueve, eso debería determinar automáticamente a qué funciones puede acceder el cliente
Shopify es un buen ejemplo de eso: tiene webhooks, pero no son el punto central de integración
Los webhooks de pagos originalmente fueron una solución medio hacky para esquivar un problema complejo de modelado de dominios
Ya existe un proyecto llamado GNU Taler, y es un sistema hecho por verdaderos expertos
https://www.taler.net/en/
Se caracteriza por pagos en línea centrados en la privacidad, pagos sin registro, diseño antifraude, posibilidad de operar tu propia infraestructura y ser software libre
Me da curiosidad cómo funciona esto en relación con la cuenta bancaria del comercio
¿Hace falta algo más además de este repositorio?
Por ahora configuramos las cuentas de comercio a través de Stripe Connect
Si eres una entidad legal en un país donde Stripe admite pagos para comercios, puedes usarlo de inmediato
A largo plazo planeamos integrarnos más a fondo en el lado de pagos
Estructuralmente es parecido a otros servicios gateway, pero agrega una comisión intermedia, así que el costo por transacción puede ser más alto
Dijeron que los eventos webhook de Stripe son más de 250 y por eso es complejo, pero no necesitas escuchar todos los eventos
Por ejemplo, tienes que pensar cómo procesar
charge.succeeded,payment_intent.succeededycustomer.subscription.created, y cómo evitar duplicadosHace falta bastante conocimiento detallado para integrar Stripe correctamente
Hace 10 años lo integré en 20 minutos; hace poco me tomó todo un día