- Flowglad là một nền tảng xử lý thanh toán mã nguồn mở hoạt động không cần webhook, cho phép nhà phát triển tích hợp tính năng lập hóa đơn và thanh toán với lượng mã tối thiểu
- Thông qua kiến trúc stateless, có thể truy vấn trạng thái thanh toán bằng ID người dùng riêng mà không cần quản lý bảng
subscriptions hay customer_id
- Cung cấp Full-Stack SDK: ở backend dùng
flowgladServer.getBilling(), ở frontend dùng hook useBilling() để phản ánh trạng thái khách hàng theo thời gian thực
- Có thể thử nghiệm mô hình giá trong chế độ test và đưa lên production chỉ với một cú nhấp, đồng thời thay đổi gói giá mà không cần triển khai lại ứng dụng
- Giảm độ phức tạp và chi phí của việc tích hợp thanh toán để cải thiện trải nghiệm nhà phát triển (DX), đồng thời cung cấp nền tảng để mở rộng kết nối với nhiều nhà cung cấp thanh toán qua một lần tích hợp duy nhất
Tính năng chính
- Cấu trúc stateless giúp không cần webhook, bảng subscription, ID khách hàng hay quản lý biến môi trường
- Flowglad xử lý trực tiếp mà không cần tự quản lý thủ công việc ánh xạ giá và tính năng
- Là nguồn sự thật duy nhất (Single Source of Truth) để truy vấn trạng thái lập hóa đơn mới nhất của khách hàng, quyền truy cập tính năng và credit mức sử dụng
- Hỗ trợ truy cập dựa trên ID tùy chỉnh, cho phép truy vấn trạng thái khách hàng bằng ID người dùng hoặc tổ chức từ hệ thống xác thực hiện có
- Cung cấp Full-Stack SDK
- Gọi
flowgladServer.getBilling() ở backend
- Dùng hook
useBilling() trên frontend React để phản ánh trạng thái thanh toán theo thời gian thực
- Quản lý mô hình giá linh hoạt
- Thử nghiệm gói giá mới trong chế độ test và đưa lên production chỉ với một cú nhấp
- Có thể xoay vòng gói giá mà không cần triển khai lại ứng dụng
Cài đặt và tích hợp
- Cài các gói
@flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server tùy theo loại dự án
- Ví dụ tích hợp Next.js
- Tạo instance
FlowgladServer và truyền ID khách hàng riêng
- Dùng
nextRouteHandler trong API route để giao tiếp an toàn với Flowglad
- Thêm
FlowgladProvider vào root layout để frontend tự động tải trạng thái thanh toán
- Với B2C dùng
user.id, với B2B dùng organization.id hoặc team.id làm ID khách hàng
- Flowglad không yêu cầu quản lý ID khách hàng riêng hay thay đổi hệ thống xác thực
Ví dụ frontend
- Dùng hook
useBilling() để kiểm tra quyền truy cập tính năng (checkFeatureAccess) và mức sử dụng (checkUsageBalance)
- Nếu quyền truy cập tính năng bị giới hạn thì hiển thị thông báo nâng cấp
- Nếu mức sử dụng không đủ thì tạo phiên thanh toán bằng
createCheckoutSession
Ví dụ backend
- Dùng
flowglad(user.id).getBilling() để kiểm tra quyền truy cập tính năng và mức sử dụng ở phía server
- Ví dụ: kiểm tra quyền truy cập tính năng
fast_generations rồi phân nhánh xử lý
- Ví dụ: phát sinh lỗi khi không đủ credit sử dụng
chat_messages
Bắt đầu
- Tạo mô hình giá bằng template trên dashboard
- Các loại template được cung cấp
- Giới hạn mức sử dụng + subscription hybrid (tương tự Cursor)
- Sử dụng không giới hạn (kiểu người dùng cá nhân như ChatGPT)
- Truy cập theo tầng + credit sử dụng (tương tự Midjourney)
- Subscription khóa tính năng (tương tự Linear)
- Nếu cần, có thể tự tạo mô hình mà không dùng template
Tech stack
- Dựa trên Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase, Better Auth
Mục tiêu dự án
- Trong 15 năm qua, stack phát triển đã trở nên đa dạng hơn nhưng đổi mới trong lĩnh vực thanh toán hầu như không có
- Phần lớn dịch vụ thanh toán thậm chí phải thông qua đội sales ngay cả khi chỉ thiết lập tài khoản, và thiếu các tùy chọn thanh toán self-service
- Kết quả là trải nghiệm nhà phát triển (DX) và hiệu quả chi phí liên quan đến thanh toán bị đình trệ
- Flowglad hướng tới giảm tối đa thời gian tích hợp và bảo trì thanh toán, đồng thời tận dụng nhiều nhà cung cấp thanh toán qua một lần tích hợp duy nhất
- Trong bối cảnh môi trường billing cho startup ngày càng phức tạp do AI phổ biến, dự án hướng tới xây dựng lớp thanh toán thân thiện với nhà phát triển
1 bình luận
Ý kiến Hacker News
Tôi không hiểu vì sao lại gọi thứ này là A) "payment processor"
Cảm giác khá lạ khi gọi như vậy trong khi nó không trực tiếp xử lý thanh toán
Và B) tuy nói là "open source", nhưng có vẻ mọi thứ vẫn chạy qua SaaS và dữ liệu cũng được lưu trong DB của họ
Tôi đồng cảm với vấn đề mà họ đang cố giải quyết, vì họ đang cố xây một hệ thống linh hoạt cho feature gate, usage credits và payment scheme, nhưng tôi không thấy nó thực sự mang lại đúng những gì tiêu đề hứa hẹn
Về phần open source, phần SaaS dùng AGPLv3, còn phần còn lại là MIT license
Cách diễn đạt "processor" là để nhấn mạnh rằng dù chúng tôi xử lý thanh toán qua Stripe Connect, đây không chỉ là một SaaS lập hóa đơn mà còn bao gồm cả xử lý thanh toán
Ví dụ, chúng tôi cũng phải lo về vấn đề chargeback cùng với merchant. Không giống SaaS chỉ dùng khóa Stripe, trong cấu trúc của chúng tôi, chargeback cũng trở thành vấn đề trực tiếp với chúng tôi như với Stripe
Đúng là sản phẩm này làm cho một số thứ trở nên dễ hơn, nhưng tôi không chắc nó có thực sự tốt hơn không
Nếu mỗi lần cần kiểm tra trạng thái subscription của khách hàng hay thứ tương tự mà đều phải gửi API request đến server của Flowglad, thì độ phản hồi có thể sẽ kém
Dữ liệu truy cập thường xuyên thì có thể cache, nhưng như vậy lại làm giảm ý nghĩa của lớp này
Tích hợp Stripe đúng là phiền, nhưng nếu cuối cùng không lưu gì ở local thì tôi nghĩ dùng thẳng Stripe API còn hơn
Tôi thấy việc có trạng thái được cache trong DB tiện hơn nhiều — vì có thể chạy ngay cả những truy vấn phức tạp
Với cấu trúc này, bạn phải hy vọng Flowglad cung cấp API mình cần, nếu không có khi phải bắn API request theo số lượng khách hàng
Chúng tôi dự định cho phép phía merchant lưu nhiều dữ liệu hơn, đồng thời vẫn tận dụng được data model đã được chúng tôi tinh chỉnh và tính tiện dụng của SDK
Ngay cả khi dùng trực tiếp Stripe API, bạn vẫn phải tự quản lý mapping giữa price id, plan, feature và customer id, và chúng tôi muốn loại bỏ phần việc lặp đi lặp lại đó
Stripe là một hệ thống thiên về ghi, nên họ không khuyến nghị dùng nó như lớp đọc thời gian thực (tài liệu Stripe rate limits)
Mục tiêu của chúng tôi là mang lại cho developer một trải nghiệm thanh toán + dịch chuyển giá trị hợp nhất, giống như cách Shopify từng làm cho các thương hiệu DTC
Lúc đầu tôi hiểu nhầm, nhưng có vẻ chỉ SDK và code là open source, còn dữ liệu billing thực tế được gửi về server của Flowglad, nên có vẻ bạn không thực sự sở hữu dữ liệu của mình
Chúc mừng ra mắt beta!
Tôi cũng từng gặp vấn đề tương tự nên đã làm một thư viện tích hợp Stripe có DX giống Flowgrad (dù ít tính năng hơn)
Tôi cũng có bài blog nói về lý do tôi làm nó
Khác biệt chính là nơi lưu thông tin billing cuối cùng — chúng tôi cung cấp luôn DB schema và webhook handler để ghi vào DB local
Biết đâu hữu ích nên tôi cũng giới thiệu thư viện open source MIT mà chúng tôi đã làm
Chúc mừng ra mắt beta, đây là sản phẩm ấn tượng nên tôi đang cân nhắc tích hợp
Nhưng tôi tò mò vì sao lại cần phụ thuộc vào React
Có cách nào để xây UI mong muốn mà không cần React không?
Bên tôi dùng Svelte-based, nên việc phải kéo React vào chỉ vì thư viện kiểu này khá bất tiện
Chúng tôi bắt đầu với React vì đó là thứ chúng tôi quen nhất và cộng đồng cũng ở đó
Chúng tôi không cố chấp với React, và sẽ sớm bổ sung hỗ trợ Svelte và Vue
Khi data model và flow ổn định hơn, chúng tôi sẽ port SDK sang các framework khác
Tệp người dùng React lớn hơn 10~50 lần nên khó tránh khỏi sự bất tiện này
Nhưng React không phải framework mà là lớp render component, nên nếu là thư viện ngoài được đóng gói tốt thì vẫn có thể dùng trong Svelte mà không vấn đề gì
Thiết kế landing page thực sự rất đẹp
Tôi không muốn nghe có vẻ tiêu cực, chỉ là thấy hơi tiếc vì nó được xây trên Stripe
Vì chúng tôi đã dành cả năm qua cho billing engine, data model và phát triển SDK
webhook phổ biến vì nó đơn giản, đáng tin cậy và hoạt động tốt
Nhưng nếu dùng cách này, có thể bạn sẽ phải tự xây thêm hạ tầng để theo dõi usage, subscription tier, cancellation, v.v.
Trong một thế giới lý tưởng, khi tiền được chuyển thì các tính năng mà khách hàng có thể truy cập cũng phải tự động được xác định theo đó
Shopify là một ví dụ như vậy — họ có webhook, nhưng đó không phải điểm tích hợp cốt lõi
Webhook thanh toán vốn là một giải pháp chắp vá để né bài toán mô hình hóa domain phức tạp
Đã có dự án tên GNU Taler, và đó là một hệ thống do các chuyên gia thực thụ xây dựng
https://www.taler.net/en/
Nó nổi bật ở chỗ là thanh toán trực tuyến ưu tiên quyền riêng tư, thanh toán không cần đăng ký, được thiết kế để chống gian lận, có thể tự vận hành hạ tầng và là phần mềm tự do
Tôi tò mò nó hoạt động thế nào với tài khoản ngân hàng của merchant
Ngoài repo này ra còn cần gì khác không?
Hiện tại chúng tôi thiết lập tài khoản merchant qua Stripe Connect
Nếu bạn là pháp nhân ở quốc gia mà Stripe hỗ trợ thanh toán cho merchant thì có thể dùng ngay
Về lâu dài, chúng tôi có kế hoạch tích hợp sâu hơn vào phần thanh toán
Về mặt cấu trúc thì nó giống các dịch vụ gateway khác, nhưng vì có thêm phí trung gian nên chi phí mỗi giao dịch có thể cao hơn
Họ nói webhook event của Stripe có hơn 250 loại nên phức tạp, nhưng thực ra bạn đâu cần lắng nghe tất cả
Ví dụ, bạn phải nghĩ xem
charge.succeeded,payment_intent.succeeded,customer.subscription.creatednên được xử lý ra sao và làm thế nào để tránh trùng lặpMuốn tích hợp Stripe cho đúng thì phải có rất nhiều kiến thức chi tiết như vậy
10 năm trước tôi tích hợp trong 20 phút, còn gần đây thì mất cả ngày