Flowglad, pemroses pembayaran open-source tanpa webhook

 (github.com/flowglad)
2 poin oleh GN⁺ 2025-11-27 | 1 komentar | Bagikan ke WhatsApp
  • Flowglad adalah platform pemrosesan pembayaran open-source yang bekerja tanpa webhook, dengan struktur yang memungkinkan pengembang mengintegrasikan fitur penagihan dan pembayaran hanya dengan sedikit kode
  • Melalui arsitektur stateless, status pembayaran dapat dicek menggunakan ID pengguna sendiri tanpa perlu tabel subscriptions atau pengelolaan customer_id
  • Menyediakan Full-Stack SDK sehingga di backend bisa menggunakan flowgladServer.getBilling(), dan di frontend status pelanggan dapat tercermin secara real-time dengan hook useBilling()
  • Menguji model harga di mode test lalu menerapkannya ke production dengan satu klik, serta memungkinkan pergantian paket tanpa redeploy aplikasi
  • Mengurangi kompleksitas dan biaya integrasi pembayaran untuk meningkatkan pengalaman pengembang (DX), serta menyediakan fondasi agar koneksi ke berbagai penyedia pembayaran dapat diperluas melalui satu integrasi

Fitur utama

  • Struktur stateless membuat webhook, tabel langganan, ID pelanggan, dan pengelolaan environment variable tidak diperlukan
    • Flowglad menanganinya langsung tanpa perlu mengelola mapping harga dan fitur secara manual
  • Sebagai single source of truth, dapat digunakan untuk mengecek status penagihan terbaru pelanggan, hak akses fitur, dan kredit penggunaan
  • Mendukung akses berbasis ID kustom, sehingga status pelanggan dapat dicek memakai ID pengguna atau organisasi dari sistem autentikasi yang sudah ada
  • Menyediakan Full-Stack SDK
    • Memanggil flowgladServer.getBilling() di backend
    • Mencerminkan status pembayaran secara real-time di frontend React dengan hook useBilling()
  • Pengelolaan model harga yang fleksibel
    • Menguji paket harga baru di mode test dan menerapkannya ke production dengan satu klik
    • Memutar paket harga tanpa redeploy aplikasi
Iklan

Instalasi dan integrasi

  • Pasang paket @flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server sesuai jenis proyek
  • Contoh integrasi Next.js
    • Membuat instance FlowgladServer dan meneruskan ID pelanggan sendiri
    • Menggunakan nextRouteHandler di route API untuk berkomunikasi dengan aman dengan Flowglad
    • Menambahkan FlowgladProvider ke root layout agar status pembayaran dimuat otomatis di frontend
  • Untuk B2C gunakan user.id, untuk B2B gunakan organization.id atau team.id sebagai ID pelanggan
  • Flowglad tidak mengharuskan pengelolaan ID pelanggan terpisah atau perubahan pada sistem autentikasi

Contoh frontend

  • Periksa akses fitur (checkFeatureAccess) dan penggunaan (checkUsageBalance) dengan hook useBilling()
  • Tampilkan pesan panduan upgrade jika akses fitur dibatasi
  • Jika penggunaan tidak mencukupi, buat sesi pembayaran dengan createCheckoutSession

Contoh backend

  • Periksa akses fitur dan penggunaan di sisi server dengan flowglad(user.id).getBilling()
    • Contoh: memeriksa apakah fitur fast_generations dapat diakses lalu menentukan alur pemrosesan
    • Contoh: memunculkan error jika kredit penggunaan chat_messages tidak mencukupi
    Iklan

Memulai

  • Buat model harga menggunakan template di dashboard
  • Jenis template yang disediakan
    • Batas penggunaan + langganan hibrida (mirip Cursor)
    • Penggunaan tak terbatas (tipe konsumen ChatGPT)
    • Akses bertingkat + kredit penggunaan (mirip Midjourney)
    • Langganan dengan penguncian fitur (mirip Linear)
  • Jika perlu, model juga bisa dibuat langsung tanpa template

Tumpukan teknologi

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

Tujuan proyek

  • Dalam 15 tahun terakhir, tumpukan pengembangan makin beragam tetapi hampir tidak ada inovasi di ranah pembayaran
  • Sebagian besar layanan pembayaran bahkan mengharuskan pengaturan akun melalui tim sales, sehingga opsi pembayaran self-service masih kurang
  • Akibatnya, perbaikan pada pengalaman pengembang (DX) dan biaya terkait pembayaran mengalami stagnasi
  • Flowglad bertujuan meminimalkan waktu integrasi dan pemeliharaan pembayaran, serta memungkinkan penggunaan banyak penyedia pembayaran melalui satu integrasi
  • Di tengah lingkungan penagihan startup yang makin kompleks akibat meluasnya AI, Flowglad berfokus membangun lapisan pembayaran yang ramah pengembang

Bacaan terkait

1 komentar

 
GN⁺ 2025-11-27
Opini Hacker News

  • Saya kurang paham kenapa ini disebut A) 'payment processor'
    Rasanya aneh menyebutnya begitu kalau sebenarnya tidak memproses pembayaran secara langsung
    Lalu B) katanya 'open source', tetapi tampaknya semuanya berjalan lewat SaaS dan datanya juga disimpan di DB mereka
    Saya paham masalah yang ingin diselesaikan, karena mereka mencoba membangun sistem yang fleksibel untuk feature gate, kredit penggunaan, dan skema pembayaran, tetapi rasanya tidak benar-benar memberikan sebesar yang dijanjikan judulnya

    • Terima kasih atas empatinya, dan saya ingin mendengar pendapat tentang cara menyelesaikannya dengan lebih baik
      Untuk soal open source, bagian SaaS dilisensikan AGPLv3, sisanya MIT license
      Istilah 'processor' kami pakai untuk memperjelas bahwa meskipun pembayaran diproses lewat Stripe Connect, ini bukan sekadar billing SaaS, melainkan juga mencakup pemrosesan pembayaran
      Misalnya, kami ikut memikirkan masalah chargeback bersama merchant. Tidak seperti SaaS yang hanya memakai kunci Stripe, dalam arsitektur kami chargeback menjadi isu langsung bagi kami juga, seperti halnya di Stripe
    • Di file lisensi memang tercantum dua lisensi: MIT dan AGPL

  • Produk ini memang membuat beberapa hal menjadi mudah, tetapi saya belum yakin apakah benar-benar lebih baik
    Kalau setiap kali ingin memeriksa status langganan pelanggan dan semacamnya harus mengirim request API ke server Flowglad, responsivitasnya bisa menurun
    Data yang sering diakses memang bisa di-cache, tetapi itu justru mengurangi makna lapisan ini
    Integrasi Stripe memang rumit, tetapi kalau tidak akan menyimpan apa pun secara lokal, saya rasa lebih baik langsung pakai Stripe API
    Saya jauh lebih nyaman punya status yang di-cache di DB — karena bisa langsung menjalankan query yang kompleks
    Dengan arsitektur seperti ini, Anda harus berharap Flowglad menyediakan API yang dibutuhkan, dan kalau tidak, Anda mungkin harus mengirim request API sebanyak jumlah pelanggan

    • Itu benar
      Kami berencana memungkinkan sisi merchant menyimpan lebih banyak data, sambil tetap memanfaatkan model data yang sudah kami rapikan dan usability SDK yang sama
      Bahkan kalau langsung memakai Stripe API, Anda tetap harus mengelola sendiri pemetaan price id, plan, feature, dan customer id, dan kami ingin menghilangkan pekerjaan berulang seperti itu
      Stripe adalah sistem yang berorientasi tulis, jadi mereka tidak menyarankan penggunaannya sebagai layer baca real-time (dokumentasi Stripe rate limits)
      Tujuan kami adalah memberi developer pengalaman pembayaran + perpindahan nilai yang terpadu, seperti yang Shopify berikan kepada brand DTC

  • Awalnya saya salah paham, tetapi ternyata hanya SDK dan kodenya yang open source, sedangkan data billing yang sebenarnya dikirim ke server Flowglad, jadi tampaknya Anda tidak benar-benar memiliki datanya sendiri

    • Betul, judulnya memang mudah menimbulkan salah paham dalam banyak hal

  • Selamat atas peluncuran beta!
    Saya juga mengalami masalah serupa, jadi saya membuat library integrasi Stripe dengan DX yang mirip Flowglad (meski fiturnya tidak sekaya itu)
    Ada juga tulisan blog tentang alasan saya membuatnya
    Perbedaan utamanya ada pada tempat penyimpanan informasi billing final — kami menyediakan skema DB dan handler webhook agar semuanya tercatat di DB lokal
    Kalau berguna, saya juga merekomendasikan library open source MIT yang kami buat

  • Selamat atas peluncuran beta, produknya mengesankan dan saya sedang mempertimbangkan untuk mengintegrasikannya
    Tapi saya penasaran kenapa perlu dependensi React
    Apakah tidak ada cara untuk membuat UI yang diinginkan tanpa React?
    Kami berbasis Svelte, jadi merepotkan kalau harus menarik React gara-gara library seperti ini

    • Poin yang bagus
      Kami mulai dengan React karena itu yang paling kami kuasai dan komunitas kami juga ada di sana
      Kami tidak terpaku pada React, dan dukungan Svelte dan Vue juga akan segera ditambahkan
      Setelah model data dan flow-nya stabil, kami berencana mem-porting SDK ke framework lain
    • Kalau memilih Svelte, situasi seperti ini akan sering terjadi
      Basis pengguna React 10–50 kali lebih besar, jadi ketidaknyamanan seperti ini sulit dihindari
      Namun React bukan framework, melainkan layer rendering komponen, jadi kalau library eksternal itu dienkapsulasi dengan baik, biasanya tetap bisa dipakai di dalam Svelte tanpa masalah

  • Desain landing page-nya benar-benar indah
    Saya tidak bermaksud terdengar negatif, hanya agak kecewa karena dibangun di atas Stripe

    • Saya juga suka, mengingatkan pada zed.dev
    • Terima kasih! Sebenarnya situsnya sengaja kami pertahankan sebagai satu halaman
      Karena setahun terakhir kami curahkan untuk mengembangkan engine billing, model data, dan SDK

  • webhook populer karena sederhana, andal, dan bekerja dengan baik
    Tetapi kalau memakai ini, Anda mungkin perlu membangun infrastruktur terpisah untuk melacak penggunaan, tier langganan, pembatalan, dan sebagainya

    • webhook cocok untuk pekerjaan asinkron atau domain berbasis event, tetapi mungkin bukan model terbaik untuk area seperti pembayaran atau otorisasi
      Di dunia yang ideal, ketika uang berpindah maka fitur yang bisa diakses pelanggan harus otomatis ditentukan berdasarkan itu
      Shopify adalah contoh seperti itu — mereka memang punya webhook, tetapi itu bukan titik integrasi utamanya
      Webhook pembayaran pada dasarnya adalah solusi hacky untuk menghindari masalah pemodelan domain yang kompleks

  • Sudah ada proyek bernama GNU Taler, dan itu adalah sistem yang dibuat oleh para ahli sungguhan
    https://www.taler.net/en/
    Ciri khasnya adalah pembayaran online yang berfokus pada privasi, pembayaran tanpa registrasi, desain anti-penipuan, bisa menjalankan infrastrukturnya sendiri, dan merupakan free software

  • Saya penasaran bagaimana ini bekerja terkait rekening bank merchant
    Apakah perlu sesuatu selain repositori ini?

    • Betul, saat ini belum ada cara untuk self-host kemitraan acquiring bank
      Saat ini akun merchant disiapkan lewat Stripe Connect
      Jika Anda adalah badan usaha di negara yang didukung Stripe untuk pembayaran merchant, Anda bisa langsung memakainya
      Dalam jangka panjang, rencananya kami akan terintegrasi lebih dalam ke sisi pembayaran
    • Anda tetap memerlukan penyedia pembayaran atau akun merchant
      Secara struktural ini mirip layanan gateway lain, tetapi karena ada biaya perantara tambahan, biaya per transaksi bisa menjadi lebih tinggi

  • Mereka bilang webhook event Stripe ada lebih dari 250 dan itu kompleks, tetapi Anda tidak perlu mendengarkan semuanya

    • Tetapi Anda tetap harus menentukan sendiri event mana yang penting bagi siklus hidup bisnis aplikasi Anda
      Misalnya, Anda perlu memikirkan bagaimana menangani charge.succeeded, payment_intent.succeeded, dan customer.subscription.created masing-masing sambil menghindari duplikasi
      Anda memang butuh banyak pengetahuan rinci seperti ini untuk bisa mengintegrasikan Stripe dengan benar
    • Stripe sudah terlalu meluas fungsinya dari UI sampai API
      Sepuluh tahun lalu saya mengintegrasikannya dalam 20 menit, tetapi belakangan ini sampai makan waktu seharian