Flowglad, o processador de pagamentos open source sem webhooks

 (github.com/flowglad)
2 pontos por GN⁺ 2025-11-27 | 1 comentários | Compartilhar no WhatsApp
  • Flowglad é uma plataforma open source de processamento de pagamentos que funciona sem webhooks, com uma estrutura que permite aos desenvolvedores integrar cobrança e pagamentos com o mínimo de código
  • Por meio de uma arquitetura stateless, é possível consultar o status de pagamento usando os próprios IDs de usuário, sem gerenciar uma tabela subscriptions ou customer_id
  • Oferece um SDK full-stack: no backend, flowgladServer.getBilling(); no frontend, o hook useBilling() reflete o status do cliente em tempo real
  • É possível testar modelos de preço no modo de teste e aplicá-los em produção com um clique, além de mudar planos sem redeploy do app
  • Reduz a complexidade e o custo da integração de pagamentos, melhorando a experiência do desenvolvedor (DX) e oferecendo uma base para expandir conexões com vários provedores de pagamento por meio de uma única integração

Principais recursos

  • Estrutura stateless, que elimina a necessidade de webhooks, tabela de assinaturas, ID de cliente e gerenciamento de variáveis de ambiente
    • O próprio Flowglad lida diretamente com preços e mapeamento de funcionalidades, sem necessidade de manutenção manual
  • Como fonte única da verdade (Single Source of Truth), permite consultar o estado mais recente de cobrança do cliente, permissões de acesso a funcionalidades e créditos de uso
  • Suporta acesso baseado em IDs personalizados, permitindo consultar o status do cliente com IDs de usuário ou organização do sistema de autenticação já existente
  • Fornece um SDK full-stack
    • No backend, chamada de flowgladServer.getBilling()
    • No frontend em React, o hook useBilling() reflete o status de pagamento em tempo real
  • Gerenciamento flexível de modelos de preço
    • Teste novos planos no modo de teste e aplique em produção com um clique
    • Altere planos sem redeploy do app

Instalação e integração

  • Instale os pacotes @flowglad/nextjs, @flowglad/react, @flowglad/express e @flowglad/server de acordo com o tipo de projeto
  • Exemplo de integração com Next.js
    • Crie uma instância de FlowgladServer e passe seu próprio ID de cliente
    • Use nextRouteHandler em rotas de API para se comunicar com o Flowglad com segurança
    • Adicione FlowgladProvider ao layout raiz para carregar automaticamente o status de pagamento no frontend
  • Em B2C, use user.id; em B2B, use organization.id ou team.id como ID do cliente
  • O Flowglad não exige gerenciamento separado de IDs de cliente nem mudanças no sistema de autenticação

Exemplo de frontend

  • Use o hook useBilling() para verificar acesso a funcionalidades (checkFeatureAccess) e uso (checkUsageBalance)
  • Exiba uma mensagem sugerindo upgrade quando o acesso a uma funcionalidade estiver restrito
  • Quando o uso disponível for insuficiente, crie uma sessão de pagamento com createCheckoutSession

Exemplo de backend

  • Use flowglad(user.id).getBilling() para verificar no servidor o acesso a funcionalidades e o uso
    • Ex.: verificar se há acesso à funcionalidade fast_generations antes de seguir com o processamento
    • Ex.: gerar erro quando faltarem créditos de uso para chat_messages

Como começar

  • Crie um modelo de preço usando um template no dashboard
  • Tipos de template disponíveis
    • Híbrido de limite de uso + assinatura (semelhante ao Cursor)
    • Uso ilimitado (modelo consumidor estilo ChatGPT)
    • Acesso em camadas + créditos de uso (semelhante ao Midjourney)
    • Assinatura com bloqueio de funcionalidades (semelhante ao Linear)
  • Se necessário, também é possível criar um modelo manualmente sem template

Stack técnica

  • Baseado em Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase e Better Auth

Objetivo do projeto

  • Nos últimos 15 anos, a stack de desenvolvimento se diversificou, mas quase não houve inovação na área de pagamentos
  • A maioria dos serviços de pagamento exige até mesmo passar pela equipe comercial para configurar uma conta, e há poucas opções de pagamento self-service
  • Como resultado, a melhoria da experiência do desenvolvedor (DX) e dos custos relacionados a pagamentos ficou estagnada
  • O Flowglad busca minimizar o tempo de integração e manutenção de pagamentos, além de permitir o uso de vários provedores por meio de uma única integração
  • Em um ambiente de cobrança para startups cada vez mais complexo com a expansão da IA, o objetivo é construir uma camada de pagamentos amigável para desenvolvedores

Leituras relacionadas

1 comentários

 
GN⁺ 2025-11-27
Comentários do Hacker News

  • Não entendo muito bem por que isso é chamado de A) "payment processor"
    Parece estranho chamar assim algo que não processa pagamentos diretamente
    E também B) dizem que é "open source", mas parece que tudo roda via SaaS e os dados ficam armazenados no banco de dados deles
    Entendo a preocupação e a tentativa de criar um sistema flexível com feature gates, créditos de uso e esquemas de cobrança, mas não sinto que entregue na prática tudo o que o título promete

    • Obrigado pela empatia, e adoraria ouvir opiniões sobre como poderíamos resolver isso melhor
      Sobre open source, a parte de SaaS está em AGPLv3 e o restante em licença MIT
      Quanto ao termo "processor", queríamos deixar claro que isso inclui o processamento de pagamentos, e não é apenas um SaaS de cobrança, mesmo que processemos pagamentos via Stripe Connect
      Por exemplo, nós nos preocupamos com problemas de chargeback junto com a loja. Diferentemente de um SaaS que só usa uma chave da Stripe, na nossa estrutura chargeback também vira um problema direto para nós, como acontece com a Stripe
    • O arquivo de licença menciona tanto MIT quanto AGPL

  • É verdade que esse produto deixa algumas coisas fáceis, mas não sei se ele é de fato melhor
    Se a estrutura exige enviar uma requisição de API para os servidores do Flowglad sempre que eu quiser verificar algo como o status de assinatura de um cliente, isso pode prejudicar a responsividade
    Dá para fazer cache dos dados acessados com frequência, mas aí essa camada perde parte do sentido
    Integrar com a Stripe é chato, mas se você não vai armazenar nada localmente, acho melhor usar a API da Stripe direto
    Para mim foi muito mais confortável manter o estado em cache no banco de dados — até porque dá para fazer consultas complexas na hora
    Nessa estrutura, você precisa torcer para que o Flowglad forneça a API necessária; caso contrário, pode acabar tendo que fazer uma chamada de API por cliente

    • Faz sentido
      Planejamos permitir que a loja armazene mais dados do seu lado, enquanto ainda aproveita nosso modelo de dados refinado e a usabilidade do SDK
      Mesmo usando a API da Stripe diretamente, você ainda precisa gerenciar por conta própria os mapeamentos de price id, plan, feature e customer id, e queremos eliminar esse trabalho repetitivo
      A Stripe é um sistema orientado à escrita, então eles não recomendam usá-la como camada de leitura em tempo real (documentação de rate limits da Stripe)
      Nosso objetivo é dar aos desenvolvedores uma experiência unificada de pagamentos + movimentação de valor, como o Shopify fez para marcas DTC

  • No começo eu tinha entendido errado, mas parece que só o SDK e o código são open source, e os dados reais de cobrança são enviados para os servidores do Flowglad, então você não é realmente dono dos seus dados

    • Exato, o título é enganoso em vários sentidos

  • Parabéns pelo lançamento da beta!
    Eu também passei por um problema parecido, então criei uma biblioteca de integração com Stripe com uma DX semelhante à do Flowgrad (embora com menos recursos)
    Também tenho um post no blog sobre por que a construí
    A principal diferença é onde as informações finais de cobrança são armazenadas — nós fornecemos juntos o esquema do banco de dados e os handlers de webhook para registrar tudo no banco local
    Caso ajude, também recomendo a biblioteca open source MIT que criamos

  • Parabéns pelo lançamento da beta, parece um produto impressionante e estou considerando integrar
    Mas fiquei curioso: por que exigir uma dependência de React?
    Não havia um jeito de implementar a UI desejada sem React?
    Somos baseados em Svelte, então é inconveniente ter que puxar React por causa desse tipo de biblioteca

    • Boa observação
      Começamos com React porque era o que conhecíamos melhor e onde estava a nossa comunidade
      Não temos apego a React, e o suporte a Svelte e Vue deve chegar em breve
      Quando o modelo de dados e os fluxos estiverem estáveis, pretendemos portar o SDK para outros frameworks
    • Se você escolheu Svelte, vai acabar encontrando esse tipo de situação com frequência
      A base de usuários de React é de 10 a 50 vezes maior, então é difícil evitar esse incômodo
      Mas React não é um framework, e sim uma camada de renderização de componentes, então se for uma biblioteca externa bem encapsulada, ela pode ser usada dentro de Svelte sem problemas

  • O design da landing page ficou realmente lindo
    Não queria soar negativo, só fiquei decepcionado por ter sido construído em cima da Stripe

    • Eu também gostei, me lembrou o zed.dev
    • Obrigado! Na verdade mantivemos o site intencionalmente como uma single page
      Isso porque passamos o último ano desenvolvendo o motor de cobrança, o modelo de dados e o SDK

  • O motivo de webhook ser popular é que ele é simples, confiável e funciona bem
    Mas, ao usar isso, talvez você precise montar uma infraestrutura separada para acompanhar uso, nível de assinatura, cancelamentos etc.

    • Webhook funciona bem para tarefas assíncronas ou domínios orientados a eventos, mas talvez não seja o melhor modelo para áreas como pagamento ou autorização
      Em um mundo ideal, quando o dinheiro se move, os recursos aos quais o cliente pode acessar deveriam ser definidos automaticamente com base nisso
      Shopify é um exemplo assim — há webhooks, mas eles não são o principal ponto de integração
      O webhook de pagamento foi originalmente uma solução improvisada para contornar um problema complexo de modelagem de domínio

  • Já existe um projeto chamado GNU Taler, e é um sistema feito por especialistas de verdade
    https://www.taler.net/en/
    Ele se destaca por ser um pagamento online focado em privacidade, sem necessidade de cadastro, com prevenção a fraude, possibilidade de operar sua própria infraestrutura e por ser software livre

  • Fiquei curioso sobre como isso funciona em relação à conta bancária da loja
    É preciso algo além deste repositório?

    • Sim, ainda não há uma forma de self-host das parcerias com acquiring banks
      No momento, configuramos as contas das lojas via Stripe Connect
      Se a empresa estiver em um país onde a Stripe dá suporte a pagamentos para lojistas, ela pode usar imediatamente
      No longo prazo, planejamos nos integrar mais profundamente à parte de pagamentos
    • Você ainda precisa de um provedor de pagamento ou de uma conta de lojista
      Estruturalmente, é parecido com outros serviços de gateway, mas como há uma taxa intermediária extra, o custo por transação pode ficar mais alto

  • Disseram que os eventos de webhook da Stripe são mais de 250 e por isso complexos, mas não é preciso ouvir todos eles

    • Ainda assim, você precisa decidir por conta própria quais eventos são importantes para o ciclo de vida de negócio do seu app
      Por exemplo, é preciso pensar em como tratar charge.succeeded, payment_intent.succeeded e customer.subscription.created, e como evitar duplicações entre eles
      É preciso muito conhecimento detalhado para integrar a Stripe corretamente
    • A Stripe expandiu demais as funcionalidades, da UI até a API
      Há 10 anos eu integrava em 20 minutos, mas recentemente levei um dia inteiro