- Flowglad は、Webhookなしで動作するオープンソースの決済処理プラットフォームで、開発者が最小限のコードで 請求・決済機能を統合 できる構造
- Stateless アーキテクチャ により、
subscriptions テーブルや customer_id の管理なしで、独自のユーザー ID で決済状態を照会可能
- Full-Stack SDK を提供し、バックエンドでは
flowgladServer.getBilling()、フロントエンドでは useBilling() フックで顧客状態をリアルタイムに反映
- テストモードで価格モデルを試験 し、ワンクリックで本番環境に反映でき、アプリの再デプロイなしで料金プランを切り替え可能
- 決済統合の複雑さとコストを減らして 開発者体験（DX） を改善し、さまざまな決済プロバイダーとの接続を単一統合で拡張する基盤を提供
主な機能
- Stateless 構造 により、Webhook、サブスクリプションテーブル、顧客 ID、環境変数の管理が不要
- 価格と機能のマッピングを手動で管理する必要がなく、Flowglad が直接処理
- 単一の真実の情報源（Single Source of Truth） として、顧客の最新の請求状態、機能アクセス権、使用量クレジットを照会可能
- ユーザー定義 ID ベースのアクセス をサポートし、既存の認証システムのユーザー・組織 ID で顧客状態を照会
- Full-Stack SDK を提供
- バックエンドで
flowgladServer.getBilling() を呼び出し
- React フロントエンドで
useBilling() フックによりリアルタイムの決済状態を反映
- 柔軟な価格モデル管理
- テストモードで新しい料金プランを試し、ワンクリックで本番環境へ反映
- アプリの再デプロイなしで料金プランをローテーション可能
インストールと統合
- プロジェクトの種類に応じて
@flowglad/nextjs、@flowglad/react、@flowglad/express、@flowglad/server パッケージをインストール
- Next.js 統合例
FlowgladServer インスタンスを作成し、独自の顧客 ID を渡す- API ルートで
nextRouteHandler を使って Flowglad と安全に通信
- ルートレイアウトに
FlowgladProvider を追加し、フロントエンドで決済状態を自動読み込み
- B2C では
user.id、B2B では organization.id または team.id を顧客 ID として使用
- Flowglad は、別個の顧客 ID 管理や認証システムの変更を要求しない
フロントエンド例
useBilling() フックで機能アクセス可否（checkFeatureAccess）と使用量（checkUsageBalance）を確認- 機能アクセスが制限されている場合はアップグレード案内メッセージを表示
- 使用量が不足している場合は
createCheckoutSession で決済セッションを作成
バックエンド例
flowglad(user.id).getBilling() により、サーバー側で機能アクセスと使用量を確認
- 例:
fast_generations 機能へのアクセス可否を確認して処理を分岐
- 例:
chat_messages の使用量クレジットが不足している場合にエラーを発生
はじめに
- ダッシュボード でテンプレートを使って価格モデルを作成
- 提供されるテンプレートの種類
- 使用量制限 + サブスクリプションのハイブリッド（Cursor 類似）
- 無制限利用（ChatGPT のコンシューマー向けモデル）
- 階層型アクセス + 利用クレジット（Midjourney 類似）
- 機能ロック型サブスクリプション（Linear 類似）
- 必要に応じてテンプレートなしで直接モデルを作成することも可能
技術スタック
- Next.js、tRPC、React.js、Tailwind CSS、Drizzle ORM、Zod、Trigger.dev、Supabase、Better Auth ベース
プロジェクトの目標
- 過去 15 年で開発スタックは多様化したが、決済領域の革新はほとんどなかった
- ほとんどの決済サービスはアカウント設定ですら営業チームを経由する必要があり、セルフサービス型の決済オプションが不足
- その結果、決済関連の 開発者体験（DX） とコスト改善は停滞状態
- Flowglad は決済統合と保守の時間を最小化し、単一統合で複数の決済プロバイダーを活用することを目指す
- AI の普及により複雑化するスタートアップの請求環境の中で、開発者フレンドリーな決済レイヤーの構築 を志向
1件のコメント
Hacker Newsのコメント
私はなぜこれを A) 「payment processor」 と呼ぶのかがよくわからない
実際に決済を直接処理していないのにそう呼ぶのは違和感がある
また B) 「open source」と言っているが、すべてがSaaS経由で動いていて、データも彼らのDBに保存されるように見える
機能ゲート、利用クレジット、決済スキームのような柔軟なシステムを作ろうとしている点の問題意識には共感するが、タイトルが約束しているほど実質的な提供があるようには感じられない
オープンソースに関しては、SaaS部分は AGPLv3、残りは MITライセンス
「processor」という表現は、私たちがStripe Connectを通じて決済を処理しているとしても、単なる請求SaaSではなく決済処理まで含んでいることを明確にしたかった
たとえば、私たちは加盟店と一緒に chargeback の問題を気にしている。Stripeキーを使うだけのSaaSとは違い、私たちの構成ではchargebackがStripeと同じように私たちにとっても直接的な課題になる
この製品がいくつかのことを 簡単に してくれるのは確かだが、実際に より良いか はわからない
顧客のサブスクリプション状態のようなものを確認するたびにFlowgladのサーバーへAPIリクエストを送る構造なら、応答性が落ちる可能性がある
頻繁にアクセスするデータはキャッシュできるだろうが、そうするとこのレイヤーの意味が薄れる
Stripe統合は厄介ではあるが、ローカルに何も保存しないのであれば、Stripe APIを直接使うほうがよいと思う
私はDBにキャッシュされた状態を持つほうがずっと楽だった — 複雑なクエリもすぐ投げられるから
この構造では、Flowgladが必要なAPIを提供してくれることを期待するしかなく、そうでなければ顧客数分のAPIリクエストを投げる必要があるかもしれない
私たちは加盟店側により多くのデータを保存できるようにしつつ、私たちが整えたデータモデルと SDKの使いやすさ をそのまま活用できるようにする予定だ
Stripe APIを直接使うとしても、price id、plan、feature、customer idのマッピングを自分で管理しなければならず、そうした繰り返し作業をなくしたい
Stripeは 書き込み中心のシステム なので、リアルタイムの読み取りレイヤーとして使うことは推奨されていない (Stripe rate limitsのドキュメント)
私たちは、ShopifyがDTCブランドに提供したような、開発者向けの 統合された決済 + 価値移転体験 を目指している
最初は誤解していたが、SDKとコードだけがオープンソースで、実際の 請求データはFlowgladのサーバーへ送信 される構造なので、データを自分で所有できないようだ
ベータリリースおめでとう！
私も似た問題に直面して、Flowgladに近いDXを持つ Stripe統合ライブラリ を作った（機能はもう少し少ないが）
なぜ作ったのかについてのブログ記事もある
大きな違いは最終的な請求情報の保存場所だ — 私たちはDBスキーマとWebhookハンドラーを一緒に提供し、ローカルDBに記録する
参考になるかもしれないので、私たちが作った MITオープンソースライブラリ も勧めておく
ベータリリースおめでとう、印象的な製品なので統合を検討している
ただ、なぜ React依存 が必要なのか気になる
Reactなしでも望むUIを実装する方法はなかったのか？
私たちは Svelteベース なので、こういうライブラリのためにReactを引き込まなければならないのは不便だ
Reactで始めた理由は、私たちが最も慣れていてコミュニティもそこにあったからだ
Reactに固執しているわけではなく、SvelteとVueのサポート もまもなく追加する予定だ
データモデルとフローが安定したら、他のフレームワーク向けにSDKを移植するつもりだ
Reactのユーザー層は10〜50倍は大きいので、この種の不便を避けるのは難しい
とはいえReactはフレームワークではなく コンポーネントレンダリングレイヤー なので、うまくカプセル化された外部ライブラリならSvelteの中でも問題なく使える
ランディングページのデザインは本当に 美しく 作られている
否定的に見せたかったわけではなく、ただStripeの上に構築されているのが惜しかった
この1年は請求エンジン、データモデル、SDKの開発に注ぎ込んできたからだ
webhook が人気なのは、シンプルで信頼できて、うまく動くからだ
ただしこれを使うと、利用量、サブスクリプションティア、解約などを追跡するための別のインフラを構築しなければならない場合がある
理想的な世界では、お金が動けば、それに応じて顧客がアクセスできる機能が自動的に決まる構造であるべきだ
Shopifyのようなところがその例だ — webhookはあるが、中核となる統合ポイントではない
決済Webhookはもともと 複雑なドメインモデリングの問題を回避するためのハック的な解決策 だった
すでに GNU Taler というプロジェクトが存在し、本物の専門家たちが作ったシステムだ
https://www.taler.net/en/
プライバシー重視のオンライン決済、登録不要の支払い、不正防止を考慮した設計、自前インフラでの運用が可能、自由ソフトウェア であることが特徴だ
加盟店の銀行口座に関してはどう動くのか気になる
このリポジトリ以外に何か必要なのか？
現時点では Stripe Connect を通じて加盟店アカウントを設定する
Stripeが加盟店決済をサポートする国の法人であれば、そのまま利用できる
長期的には決済側にもっと深く統合していく予定だ
構造的には他のゲートウェイサービスと似ているが、中間マージン が追加されるため、取引ごとのコストは高くなる可能性がある
StripeのWebhookイベントが250種類以上あって複雑だと言っていたが、すべてのイベントを聞く必要はない
たとえば
charge.succeeded、payment_intent.succeeded、customer.subscription.createdをそれぞれどう処理し、重複をどう避けるかを考える必要があるStripeをきちんと統合するには、こうした細かな知識がたくさん必要になる
10年前は20分で統合できたのに、最近では丸一日かかった