Flowglad ระบบประมวลผลการชำระเงินโอเพนซอร์สที่ไม่ต้องใช้เว็บฮุก

 (github.com/flowglad)
2 คะแนน โดย GN⁺ 2025-11-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Flowglad เป็นแพลตฟอร์มประมวลผลการชำระเงินแบบโอเพนซอร์สที่ทำงานได้โดยไม่ต้องใช้เว็บฮุก โดยออกแบบมาให้นักพัฒนาสามารถ ผสานฟังก์ชันการเรียกเก็บเงินและการชำระเงิน ได้ด้วยโค้ดเพียงเล็กน้อย
  • ด้วยสถาปัตยกรรมแบบ Stateless จึงสามารถตรวจสอบสถานะการชำระเงินด้วย ID ผู้ใช้ของตัวเองได้ โดยไม่ต้องมีตาราง subscriptions หรือจัดการ customer_id
  • มี Full-Stack SDK ให้ใช้งาน โดยฝั่งแบ็กเอนด์ใช้ flowgladServer.getBilling() และฝั่งฟรอนต์เอนด์ใช้ฮุก useBilling() เพื่อสะท้อนสถานะลูกค้าแบบเรียลไทม์
  • สามารถ ทดลองโมเดลราคาในโหมดทดสอบ และนำขึ้นโปรดักชันได้ด้วยการคลิกครั้งเดียว รวมถึงสลับแพ็กเกจราคาได้โดยไม่ต้อง redeploy แอป
  • ช่วยลดความซับซ้อนและต้นทุนของการผสานระบบชำระเงิน เพื่อปรับปรุง ประสบการณ์นักพัฒนา (DX) และวางรากฐานสำหรับการเชื่อมต่อกับผู้ให้บริการชำระเงินหลากหลายรายผ่านการผสานเพียงครั้งเดียว

ฟีเจอร์หลัก

  • โครงสร้างแบบ Stateless ทำให้ไม่จำเป็นต้องมีเว็บฮุก ตาราง subscription, customer ID หรือการจัดการ environment variables
    • Flowglad จัดการเรื่องราคาและการแมปฟีเจอร์ให้โดยตรง จึงไม่ต้องดูแลด้วยตนเอง
  • ทำหน้าที่เป็น แหล่งข้อมูลจริงเพียงแหล่งเดียว (Single Source of Truth) สำหรับตรวจสอบสถานะการเรียกเก็บเงินล่าสุด สิทธิ์การเข้าถึงฟีเจอร์ และเครดิตการใช้งานของลูกค้า
  • รองรับ การเข้าถึงบนพื้นฐานของ ID ที่กำหนดเอง ทำให้ตรวจสอบสถานะลูกค้าได้ด้วย user ID หรือ organization ID จากระบบยืนยันตัวตนเดิม
  • มี Full-Stack SDK
    • เรียก flowgladServer.getBilling() จากฝั่งแบ็กเอนด์
    • ใช้ฮุก useBilling() ใน React ฟรอนต์เอนด์เพื่ออัปเดตสถานะการชำระเงินแบบเรียลไทม์
  • จัดการโมเดลราคาได้อย่างยืดหยุ่น
    • ทดลองแพ็กเกจราคาใหม่ในโหมดทดสอบ และนำขึ้นโปรดักชันได้ด้วยการคลิกครั้งเดียว
    • หมุนเวียนแพ็กเกจราคาได้โดยไม่ต้อง redeploy แอป

การติดตั้งและการผสานระบบ

  • ติดตั้งแพ็กเกจ @flowglad/nextjs, @flowglad/react, @flowglad/express, @flowglad/server ตามประเภทของโปรเจกต์
  • ตัวอย่างการผสานกับ Next.js
    • สร้างอินสแตนซ์ FlowgladServer แล้วส่ง customer ID ของตัวเองเข้าไป
    • ใช้ nextRouteHandler ใน API route เพื่อสื่อสารกับ Flowglad อย่างปลอดภัย
    • เพิ่ม FlowgladProvider ใน root layout เพื่อให้ฟรอนต์เอนด์โหลดสถานะการชำระเงินอัตโนมัติ
  • สำหรับ B2C ใช้ user.id และสำหรับ B2B ใช้ organization.id หรือ team.id เป็น customer ID
  • Flowglad ไม่ต้องการให้จัดการ customer ID แยกต่างหากหรือเปลี่ยนระบบยืนยันตัวตน

ตัวอย่างฝั่งฟรอนต์เอนด์

  • ใช้ฮุก useBilling() เพื่อตรวจสอบสิทธิ์การเข้าถึงฟีเจอร์ (checkFeatureAccess) และปริมาณการใช้งาน (checkUsageBalance)
  • แสดงข้อความแนะนำให้อัปเกรดเมื่อการเข้าถึงฟีเจอร์ถูกจำกัด
  • หากปริมาณการใช้งานไม่เพียงพอ ให้สร้างเซสชันชำระเงินด้วย createCheckoutSession

ตัวอย่างฝั่งแบ็กเอนด์

  • ใช้ flowglad(user.id).getBilling() เพื่อตรวจสอบสิทธิ์การเข้าถึงฟีเจอร์และปริมาณการใช้งานจากฝั่งเซิร์ฟเวอร์
    • ตัวอย่าง: ตรวจสอบสิทธิ์เข้าถึงฟีเจอร์ fast_generations แล้วค่อยแยกการทำงาน
    • ตัวอย่าง: หากเครดิตการใช้งาน chat_messages ไม่พอ ให้เกิดข้อผิดพลาด

เริ่มต้นใช้งาน

  • สร้างโมเดลราคาจากเทมเพลตได้ที่ แดชบอร์ด
  • ประเภทเทมเพลตที่มีให้
    • แบบไฮบริดจำกัดการใช้งาน + subscription (คล้าย Cursor)
    • ใช้งานไม่จำกัด (แบบผู้บริโภคของ ChatGPT)
    • การเข้าถึงแบบแบ่งระดับ + เครดิตการใช้งาน (คล้าย Midjourney)
    • subscription แบบล็อกฟีเจอร์ (คล้าย Linear)
  • หากต้องการ สามารถสร้างโมเดลเองได้โดยไม่ใช้เทมเพลต

เทคโนโลยีสแตก

  • พัฒนาบน Next.js, tRPC, React.js, Tailwind CSS, Drizzle ORM, Zod, Trigger.dev, Supabase, Better Auth

เป้าหมายของโปรเจกต์

  • แม้สแตกการพัฒนาจะหลากหลายขึ้นในช่วง 15 ปีที่ผ่านมา แต่ แทบไม่มีนวัตกรรมในด้านการชำระเงิน
  • บริการชำระเงินส่วนใหญ่แม้แต่การตั้งค่าบัญชียังต้องผ่านทีมขาย และยัง ขาดตัวเลือกการชำระเงินแบบบริการตนเอง
  • ผลลัพธ์คือ ประสบการณ์นักพัฒนา (DX) และต้นทุนด้านการชำระเงินแทบไม่พัฒนา
  • Flowglad มีเป้าหมายเพื่อลดเวลาการผสานและบำรุงรักษาระบบชำระเงินให้ต่ำที่สุด และเปิดทางให้ใช้ผู้ให้บริการชำระเงินหลายรายผ่านการผสานเพียงครั้งเดียว
  • ท่ามกลางสภาพแวดล้อมการเรียกเก็บเงินของสตาร์ทอัพที่ซับซ้อนขึ้นจากการเติบโตของ AI โปรเจกต์นี้มุ่งสร้าง เลเยอร์การชำระเงินที่เป็นมิตรต่อนักพัฒนา

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-11-27
ความคิดเห็นจาก Hacker News

  • ฉันไม่ค่อยเข้าใจว่าทำไมถึงเรียกสิ่งนี้ว่า A) ‘payment processor’
    มันรู้สึกแปลกที่เรียกแบบนั้นทั้งที่ไม่ได้ประมวลผลการชำระเงินจริงโดยตรง
    แล้วก็ B) บอกว่าเป็น ‘open source’ แต่ดูเหมือนว่าทุกอย่างทำงานผ่าน SaaS และข้อมูลก็ถูกเก็บไว้ใน DB ของพวกเขา
    ฉันเข้าใจปัญหาที่พยายามแก้ เพราะกำลังพยายามสร้างระบบที่ยืดหยุ่นอย่าง feature gate, เครดิตการใช้งาน, payment scheme แต่ก็ยังไม่รู้สึกว่าให้ของจริงได้มากเท่ากับที่หัวข้อสัญญาไว้

    • ขอบคุณที่เข้าใจ และอยากฟังความเห็นว่าจะทำให้แก้ปัญหานี้ได้ดีกว่านี้อย่างไร
      ในส่วนของโอเพนซอร์ส ฝั่ง SaaS เป็น AGPLv3 และส่วนที่เหลือเป็น MIT license
      คำว่า ‘processor’ เราใช้เพื่อให้ชัดเจนว่า แม้เราจะประมวลผลการชำระเงินผ่าน Stripe Connect แต่ก็ไม่ได้เป็นแค่ SaaS สำหรับออกบิลเท่านั้น เรายังครอบคลุมการประมวลผลการจ่ายเงินด้วย
      ตัวอย่างเช่น เรากังวลเรื่อง chargeback ไปพร้อมกับร้านค้า ต่างจาก SaaS ที่แค่เอา Stripe key มาใช้ โครงสร้างของเราทำให้ chargeback เป็นประเด็นโดยตรงกับเราเช่นเดียวกับ Stripe
    • ในไฟล์ไลเซนส์มีระบุไว้ทั้ง MIT และ AGPL สองแบบ

  • ผลิตภัณฑ์นี้ทำให้บางอย่าง ง่ายขึ้น จริง แต่ไม่แน่ใจว่ามัน ดีกว่า จริงหรือเปล่า
    ถ้าทุกครั้งที่ต้องเช็กสถานะ subscription ของลูกค้าต้องยิง API ไปที่เซิร์ฟเวอร์ของ Flowglad ก็อาจทำให้การตอบสนองช้าลง
    ข้อมูลที่เข้าถึงบ่อยอาจแคชได้ แต่ถ้าอย่างนั้นความหมายของเลเยอร์นี้ก็ลดลง
    แม้การเชื่อมต่อ Stripe จะยุ่งยาก แต่ถ้าจะไม่เก็บอะไรไว้ในระบบตัวเองเลย ฉันคิดว่าใช้ Stripe API ตรงๆ น่าจะดีกว่า
    สำหรับฉัน การมีสถานะที่แคชไว้ใน DB สะดวกกว่ามาก — เพราะยิง query ซับซ้อนได้ทันที
    ในโครงสร้างนี้คุณต้องหวังว่า Flowglad จะมี API ที่ต้องการ ไม่งั้นอาจต้องยิง API request ตามจำนวนลูกค้าก็ได้

    • เห็นด้วย
      เราวางแผนจะให้ฝั่งร้านค้าเก็บข้อมูลได้มากขึ้น ขณะเดียวกันก็ยังใช้ data model ที่เราขัดเกลาไว้และ ความใช้งานง่ายของ SDK ได้เหมือนเดิม
      ต่อให้ใช้ Stripe API โดยตรง คุณก็ยังต้องจัดการ mapping ของ price id, plan, feature, customer id เองอยู่ดี ซึ่งเราอยากตัดงานซ้ำๆ แบบนี้ออกไป
      Stripe เป็น ระบบที่เน้นการเขียนข้อมูล จึงไม่ได้แนะนำให้ใช้เป็นเลเยอร์อ่านข้อมูลแบบเรียลไทม์ (เอกสาร Stripe rate limits)
      เป้าหมายของเราคือมอบ ประสบการณ์การชำระเงิน + การเคลื่อนย้ายมูลค่าแบบรวมศูนย์ ให้กับนักพัฒนา คล้ายกับที่ Shopify เคยมอบให้แบรนด์ DTC

  • ตอนแรกฉันเข้าใจผิด คิดว่าเป็นโอเพนซอร์สทั้งหมด แต่จริงๆ เปิดซอร์สแค่ SDK กับโค้ด และ ข้อมูลบิลจริงถูกส่งไปยังเซิร์ฟเวอร์ของ Flowglad ทำให้ดูเหมือนคุณไม่ได้เป็นเจ้าของข้อมูลเองโดยตรง

    • ใช่แล้ว ชื่อหัวข้อนี้ ชวนให้เข้าใจผิด ในหลายมิติ

  • ยินดีกับการเปิดตัวเบต้า!
    ฉันก็เจอปัญหาคล้ายกัน เลยทำ ไลบรารีเชื่อมต่อ Stripe ที่มี DX คล้าย Flowgrad ขึ้นมาเอง (แม้ฟีเจอร์จะน้อยกว่า)
    มี โพสต์บล็อก ด้วยว่าเราทำไปทำไม
    ความต่างหลักคือเก็บข้อมูลบิลสุดท้ายไว้ที่ไหน — เรามีทั้ง DB schema และ webhook handler ให้ เพื่อบันทึกลง local DB
    เผื่อจะเป็นประโยชน์ ขอแนะนำ ไลบรารีโอเพนซอร์ส MIT ที่เราทำไว้ด้วย

  • ยินดีกับการเปิดตัวเบต้า เป็นผลิตภัณฑ์ที่น่าประทับใจและกำลังพิจารณาจะเชื่อมต่อใช้งาน
    แต่สงสัยว่าทำไมถึงต้องมี dependency ของ React
    ไม่มีวิธีทำ UI ตามที่ต้องการโดยไม่ต้องพึ่ง React หรือ?
    เราใช้ Svelte เป็นหลัก เลยรู้สึกไม่สะดวกที่ต้องดึง React เข้ามาเพราะไลบรารีแบบนี้

    • เป็นคำถามที่ดี
      เราเริ่มจาก React เพราะเป็นสิ่งที่เราคุ้นที่สุดและคอมมูนิตี้ก็อยู่ทางนั้น
      เราไม่ได้ยึดติดกับ React และมีแผนเพิ่ม การรองรับ Svelte และ Vue เร็วๆ นี้
      เมื่อ data model และ flow นิ่งแล้ว เราตั้งใจจะพอร์ต SDK ไปยังเฟรมเวิร์กอื่นด้วย
    • ถ้าคุณเลือก Svelte คุณก็คงต้องเจอสถานการณ์แบบนี้บ่อยอยู่แล้ว
      ฐานผู้ใช้ React ใหญ่กว่าราว 10–50 เท่า เลยเลี่ยงความไม่สะดวกแบบนี้ได้ยาก
      แต่ React ไม่ใช่เฟรมเวิร์ก มันเป็นแค่ เลเยอร์เรนเดอร์คอมโพเนนต์ ดังนั้นถ้าเป็นไลบรารีภายนอกที่ encapsulate มาดี ก็ใช้ใน Svelte ได้ไม่มีปัญหา

  • ดีไซน์หน้า landing page ทำออกมาได้ สวยมาก
    ไม่ได้อยากจะมองในแง่ลบ แค่เสียดายที่มันสร้างอยู่บน Stripe

    • ฉันก็ชอบเหมือนกัน ทำให้นึกถึง zed.dev
    • ขอบคุณมาก! จริงๆ เราตั้งใจให้เว็บไซต์เป็น หน้าเดียว โดยเฉพาะ
      เพราะตลอดปีที่ผ่านมาเราเทเวลาทั้งหมดไปกับการพัฒนา billing engine, data model และ SDK

  • เหตุผลที่ webhook ได้รับความนิยมคือมันเรียบง่าย เชื่อถือได้ และใช้งานได้ผลดี
    แต่ถ้าใช้วิธีนี้ คุณอาจต้องสร้างโครงสร้างพื้นฐานแยกต่างหากเพื่อคอยติดตามการใช้งาน subscription tier การยกเลิก และอื่นๆ

    • webhook เหมาะกับงาน asynchronous หรือโดเมนแบบ event-driven แต่สำหรับเรื่องอย่างการชำระเงินหรือการให้สิทธิ์ อาจไม่ใช่โมเดลที่ดีที่สุด
      ในโลกอุดมคติ ถ้ามีการเคลื่อนย้ายเงินเกิดขึ้น ฟีเจอร์ที่ลูกค้าเข้าถึงได้ก็ควรถูกกำหนดตามนั้นโดยอัตโนมัติ
      Shopify เป็นตัวอย่างหนึ่ง — มี webhook ก็จริง แต่ไม่ใช่จุดเชื่อมต่อหลัก
      เดิมที payment webhook เป็น วิธีแก้แบบแฮ็กเพื่อเลี่ยงปัญหาการทำโมเดลโดเมนที่ซับซ้อน

  • มีโปรเจกต์ชื่อ GNU Taler อยู่แล้ว และเป็นระบบที่สร้างโดยผู้เชี่ยวชาญตัวจริง
    https://www.taler.net/en/
    จุดเด่นคือเป็นระบบชำระเงินออนไลน์ที่เน้นความเป็นส่วนตัว ชำระได้โดยไม่ต้องลงทะเบียน ออกแบบมาเพื่อป้องกันการฉ้อโกง รันบนโครงสร้างพื้นฐานของตัวเองได้ และเป็น ซอฟต์แวร์เสรี

  • สงสัยว่าฝั่งบัญชีธนาคารของร้านค้าทำงานอย่างไร
    นอกจากรีโพซิทอรีนี้แล้ว ยังต้องมีอย่างอื่นอีกหรือไม่?

    • ใช่ ตอนนี้ยังไม่มีวิธี self-host สำหรับ acquiring bank partnership
      ตอนนี้การตั้งค่าบัญชีร้านค้าทำผ่าน Stripe Connect
      ถ้าเป็นนิติบุคคลในประเทศที่ Stripe รองรับการชำระเงินสำหรับร้านค้า ก็ใช้งานได้ทันที
      ในระยะยาวเรามีแผนจะเชื่อมลงลึกกับฝั่งการชำระเงินมากขึ้น
    • คุณยังคงต้องมีผู้ให้บริการชำระเงินหรือบัญชีร้านค้าอยู่ดี
      ในเชิงโครงสร้างมันคล้ายบริการเกตเวย์อื่นๆ แต่มี ค่าธรรมเนียมตัวกลาง เพิ่มเข้ามา จึงอาจทำให้ต้นทุนต่อธุรกรรมสูงขึ้น

  • มีคนบอกว่า webhook event ของ Stripe มีมากกว่า 250 แบบจึงซับซ้อน แต่จริงๆ ไม่จำเป็นต้องฟังทุก event

    • แต่คุณต้องตัดสินเองว่า event ไหนสำคัญต่อ วงจรชีวิตทางธุรกิจ ของแอปคุณ
      เช่น ต้องคิดว่าจะจัดการ charge.succeeded, payment_intent.succeeded, customer.subscription.created อย่างไร และจะหลีกเลี่ยงข้อมูลซ้ำซ้อนได้อย่างไร
      ถ้าจะเชื่อมต่อ Stripe ให้ดี คุณต้องมีความรู้เชิงรายละเอียดพวกนี้มากพอ
    • Stripe มี การขยายฟังก์ชันมากเกินไป ตั้งแต่ UI ไปจนถึง API
      เมื่อ 10 ปีก่อนฉันเชื่อมต่อได้ภายใน 20 นาที แต่ช่วงหลังนี้ใช้เวลาทั้งวัน