ओपन सोर्स webhook-रहित payment processor Flowglad

 (github.com/flowglad)
2 पॉइंट द्वारा GN⁺ 2025-11-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Flowglad एक ओपन सोर्स payment processing प्लेटफ़ॉर्म है जो webhook के बिना काम करता है, और डेवलपर्स को न्यूनतम कोड के साथ billing और payment features को integrate करने की सुविधा देता है
  • Stateless architecture के माध्यम से subscriptions table या customer_id मैनेजमेंट के बिना अपने user ID से payment status query किया जा सकता है
  • Full-Stack SDK उपलब्ध है, जिससे backend में flowgladServer.getBilling() और frontend में useBilling() hook के जरिए customer status को real time में reflect किया जा सकता है
  • Test mode में pricing model का experiment किया जा सकता है और एक क्लिक में उसे production में लागू किया जा सकता है, साथ ही app redeploy किए बिना plan switch करना संभव है
  • payment integration की complexity और cost को घटाकर developer experience (DX) बेहतर करता है, और अलग-अलग payment providers के साथ कनेक्शन को एक single integration के जरिए expand करने की नींव देता है

मुख्य फीचर्स

  • Stateless structure के कारण webhook, subscription table, customer ID, और environment variable management की ज़रूरत नहीं
    • price और feature mapping को manually manage करने की आवश्यकता नहीं; Flowglad इसे सीधे संभालता है
  • Single Source of Truth के रूप में customer की latest billing status, feature access permissions, और usage credits को query किया जा सकता है
  • Custom ID आधारित access का समर्थन, जिससे मौजूदा authentication system के user या organization ID से customer status query किया जा सकता है
  • Full-Stack SDK उपलब्ध
    • backend में flowgladServer.getBilling() call
    • React frontend में useBilling() hook के जरिए real time payment status reflect
  • Flexible pricing model management
    • test mode में नए plans का experiment और एक क्लिक में production पर apply
    • app redeploy किए बिना plans rotate करना संभव

इंस्टॉलेशन और integration

  • project type के अनुसार @flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server packages install करें
  • Next.js integration example
    • FlowgladServer instance बनाकर अपना customer ID पास करें
    • API route में nextRouteHandler का उपयोग करके Flowglad के साथ सुरक्षित communication करें
    • root layout में FlowgladProvider जोड़ें ताकि frontend में payment status अपने आप load हो
  • B2C में user.id, और B2B में organization.id या team.id को customer ID के रूप में इस्तेमाल करें
  • Flowglad अलग customer ID management या authentication system में बदलाव की मांग नहीं करता

frontend example

  • useBilling() hook से feature access (checkFeatureAccess) और usage (checkUsageBalance) की जाँच करें
  • feature access सीमित होने पर upgrade मार्गदर्शन संदेश दिखाएँ
  • usage कम होने पर createCheckoutSession से payment session बनाएँ

backend example

  • flowglad(user.id).getBilling() से server side पर feature access और usage की जाँच
    • उदाहरण: fast_generations feature access उपलब्ध है या नहीं, उसके आधार पर processing branch करें
    • उदाहरण: chat_messages usage credits कम होने पर error उत्पन्न करें

शुरुआत करें

  • Dashboard में template का उपयोग करके pricing model बनाएँ
  • उपलब्ध template प्रकार
    • usage limit + subscription hybrid (Cursor जैसा)
    • unlimited usage (ChatGPT consumer-style)
    • tiered access + usage credits (Midjourney जैसा)
    • feature-locked subscription (Linear जैसा)
  • आवश्यकता होने पर template के बिना भी model सीधे बनाया जा सकता है

टेक स्टैक

  • Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase, Better Auth आधारित

प्रोजेक्ट का लक्ष्य

  • पिछले 15 वर्षों में development stack भले विविध हुआ हो, लेकिन payments क्षेत्र में innovation लगभग नहीं हुआ
  • ज़्यादातर payment services में account setup तक के लिए sales team से होकर गुजरना पड़ता है, और self-service payment options की कमी है
  • नतीजतन payment से जुड़ा developer experience (DX) और cost improvement ठहरा हुआ है
  • Flowglad का लक्ष्य payment integration और maintenance time को न्यूनतम करना, और एक single integration से कई payment providers का उपयोग संभव बनाना है
  • AI के प्रसार से जटिल होते startup billing environment में यह developer-friendly payment layer बनाने की दिशा में काम करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-11-27
Hacker News राय

  • मुझे समझ नहीं आता कि इसे A) ‘payment processor’ क्यों कहा जा रहा है
    जब यह खुद सीधे पेमेंट प्रोसेस नहीं करता, तो ऐसा कहना अजीब लगता है
    और B) इसे ‘open source’ भी कहा जा रहा है, लेकिन लगता है कि सब कुछ SaaS के ज़रिए चलता है और डेटा भी इनके DB में स्टोर होता है
    feature gate, usage credits, payment scheme जैसी flexible systems बनाने की कोशिश को मैं समझता हूँ, लेकिन शीर्षक में जो वादा किया गया है उतना वास्तविक रूप से मिलता हुआ नहीं लगता

    • सहमति जताने के लिए धन्यवाद, और मैं यह सुनना चाहूँगा कि इसे बेहतर तरीके से कैसे हल किया जा सकता है
      open source के मामले में, SaaS वाला हिस्सा AGPLv3 है और बाकी MIT लाइसेंस के तहत है
      ‘processor’ शब्द का इस्तेमाल इसलिए किया क्योंकि भले ही हम Stripe Connect के ज़रिए पेमेंट प्रोसेस करते हैं, हम सिर्फ billing SaaS नहीं हैं बल्कि payment processing भी शामिल करते हैं
      उदाहरण के लिए, हम merchants के साथ chargeback की चिंता करते हैं. सिर्फ Stripe key इस्तेमाल करने वाले SaaS के विपरीत, हमारे ढाँचे में chargeback हमारे लिए भी Stripe की तरह सीधा मुद्दा बन जाता है
    • लाइसेंस फ़ाइल में MIT और AGPL, दोनों दिए गए हैं

  • यह प्रोडक्ट कुछ चीज़ें आसान ज़रूर बनाता है, लेकिन यह वास्तव में बेहतर है या नहीं, यह पक्का नहीं है
    अगर हर बार customer subscription status जैसी चीज़ें देखने के लिए Flowglad server को API request भेजनी पड़े, तो responsiveness कम हो सकती है
    frequently accessed data को cache किया जा सकता है, लेकिन तब इस layer का मतलब कम हो जाता है
    Stripe integration कठिन ज़रूर है, लेकिन अगर आप local में कुछ भी store नहीं करने वाले हैं, तो शायद सीधे Stripe API इस्तेमाल करना बेहतर होगा
    मुझे DB में cached state रखना कहीं ज़्यादा सुविधाजनक लगा — क्योंकि तब complex queries भी सीधे चला सकते हैं
    इस architecture में या तो उम्मीद करनी होगी कि Flowglad ज़रूरी API दे, नहीं तो हर customer के लिए API request भेजनी पड़ सकती है

    • सही बात है
      हम यह योजना बना रहे हैं कि merchants अपनी तरफ़ ज़्यादा data store कर सकें, और साथ ही हमारे refined data model और SDK की usability का लाभ भी लेते रहें
      Stripe API सीधे इस्तेमाल करने पर भी price id, plan, feature, customer id mapping खुद संभालनी पड़ती है, और हम यही दोहराव हटाना चाहते हैं
      Stripe एक write-heavy system है, इसलिए इसे real-time read layer की तरह इस्तेमाल करने की सलाह नहीं दी जाती (Stripe rate limits docs)
      हमारा लक्ष्य developers को वैसा integrated payments + movement of value experience देना है जैसा Shopify ने DTC brands को दिया था

  • पहले मुझे गलतफ़हमी हुई थी, लेकिन लगता है कि सिर्फ SDK और code ही open source हैं और असली billing data Flowglad server पर भेजा जाता है, इसलिए डेटा पर सीधा स्वामित्व नहीं रहता

    • सही है, शीर्षक कई मायनों में गुमराह करने वाला है

  • beta release के लिए बधाई!
    मुझे भी इसी तरह की समस्या आई थी, इसलिए मैंने Flowgrad जैसी DX वाली एक Stripe integration library बनाई थी (हालाँकि फीचर कम हैं)
    मैंने इसे क्यों बनाया, इस पर एक blog post भी है
    मुख्य अंतर यह है कि अंतिम billing information कहाँ स्टोर होती है — हम DB schema और webhook handler साथ में देते हैं ताकि सब local DB में लिखा जाए
    शायद काम आए, इसलिए हमारी MIT open source library भी सुझाऊँगा

  • beta release के लिए बधाई, प्रोडक्ट प्रभावशाली है और मैं integration पर विचार कर रहा हूँ
    लेकिन मैं जानना चाहता हूँ कि React dependency की ज़रूरत क्यों है
    क्या React के बिना मनचाहा UI बनाने का कोई तरीका नहीं था?
    हम Svelte-based हैं, इसलिए ऐसी library की वजह से React लाना असुविधाजनक है

    • अच्छा point है
      React से शुरू करने का कारण यह था कि हम उसी में सबसे अधिक सहज थे और community भी वहीं थी
      हमारा React पर अड़ने का इरादा नहीं है, Svelte और Vue support भी जल्द जोड़ा जाएगा
      data model और flow stable होते ही SDK को दूसरे frameworks में port करने की योजना है
    • अगर आपने Svelte चुना है, तो ऐसी स्थिति अक्सर आएगी
      React users 10~50 गुना ज़्यादा हैं, इसलिए इस असुविधा से बचना मुश्किल है
      लेकिन React कोई framework नहीं बल्कि component rendering layer है, इसलिए अगर external library ठीक से encapsulated हो तो उसे Svelte के अंदर भी बिना दिक्कत इस्तेमाल किया जा सकता है

  • landing page का design सच में बहुत सुंदर है
    मेरा इरादा नकारात्मक लगने का नहीं था, बस यह थोड़ा निराशाजनक लगा कि यह Stripe के ऊपर बना है

    • मुझे भी पसंद आया, zed.dev की याद दिलाता है
    • धन्यवाद! सच कहूँ तो साइट को हमने जानबूझकर single page ही रखा
      क्योंकि पिछले एक साल हमने billing engine, data model और SDK बनाने में लगाया है

  • webhook लोकप्रिय इसलिए हैं क्योंकि वे सरल, भरोसेमंद और काम के होते हैं
    लेकिन इन्हें इस्तेमाल करने पर usage, subscription tier, cancellation आदि track करने के लिए अलग infrastructure बनाना पड़ सकता है

    • webhook asynchronous work या event-driven domains के लिए अच्छे हैं, लेकिन payments या authorization जैसे क्षेत्रों में वे सबसे अच्छा model नहीं भी हो सकते
      आदर्श दुनिया में, जैसे ही पैसा चलता है, उसी के अनुसार customer किन features तक पहुँच सकता है यह अपने-आप तय होना चाहिए
      Shopify जैसी सेवाएँ इसका उदाहरण हैं — वहाँ webhook हैं, लेकिन वे core integration point नहीं हैं
      payment webhook मूल रूप से complex domain modeling problem को bypass करने वाला एक hacky solution थे

  • GNU Taler नाम का एक प्रोजेक्ट पहले से मौजूद है, और यह वास्तविक विशेषज्ञों द्वारा बनाया गया सिस्टम है
    https://www.taler.net/en/
    इसकी खासियतें हैं privacy-focused online payments, registration-free payments, fraud-resistant design, अपना infrastructure चलाने की क्षमता, और free software होना

  • merchant के bank account के संदर्भ में यह कैसे काम करता है, यह जानना चाहता हूँ
    क्या इस repository के अलावा और कुछ चाहिए?

    • हाँ, अभी acquiring bank partnership को self-host करने का कोई तरीका नहीं है
      फिलहाल हम Stripe Connect के ज़रिए merchant account सेट करते हैं
      अगर Stripe merchant payments को सपोर्ट करने वाले देश में आपकी company registered है, तो आप तुरंत इसका उपयोग कर सकते हैं
      लंबी अवधि में हमारा plan payments side में और गहराई से integrate होने का है
    • आपको फिर भी payment provider या merchant account चाहिए होगा
      architecture के लिहाज़ से यह दूसरे gateway services जैसा ही है, लेकिन middleman fee जुड़ने से प्रति transaction लागत बढ़ सकती है

  • कहा गया कि Stripe के webhook events 250 से ज़्यादा हैं, इसलिए यह complex है, लेकिन सभी events सुनना ज़रूरी नहीं है

    • लेकिन आपको खुद तय करना पड़ता है कि आपकी app के business lifecycle के लिए कौन से events महत्वपूर्ण हैं
      उदाहरण के लिए charge.succeeded, payment_intent.succeeded, customer.subscription.created को अलग-अलग कैसे handle करें और duplicate processing से कैसे बचें, यह सोचना पड़ता है
      Stripe को सही ढंग से integrate करने के लिए इस तरह का बहुत सारा detail knowledge चाहिए
    • Stripe में UI से लेकर API तक feature expansion हद से ज़्यादा हो चुका है
      10 साल पहले मैंने इसे 20 मिनट में integrate कर लिया था, लेकिन हाल में पूरा दिन लग गया