ความยากของการสร้างระบบชำระเงินขึ้นเอง

14 ความเจ็บปวดของการสร้างระบบออกบิล

• ระบบออกบิลและระบบสร้างรายได้เป็นสิ่งจำเป็น หากธุรกิจมีแผนจะสร้างรายได้
• ระบบออกบิลมีความซับซ้อน และเชื่อมโยงกับหลายฝ่าย เช่น การเงิน ผลิตภัณฑ์ ประสบการณ์ผู้ใช้ ฝ่ายสนับสนุนลูกค้า ลูกค้า กฎหมาย การปฏิบัติตามข้อกำหนด และฝ่ายขาย
• ระบบออกบิลเชื่อมต่อกันอย่างแน่นหนา จนหากส่วนหนึ่งล่ม ทั้งระบบก็อาจหยุดชะงักได้ง่าย

รูปแบบ 3 แบบ

• ระบบออกบิลมีอยู่ 3 รูปแบบ ได้แก่ พัฒนาขึ้นเองทั้งหมด ระบบภายนอกแบบครบชุด และระบบแบบผสม
• แต่ละรูปแบบมีข้อดีและข้อเสียเฉพาะตัว

ระบบพัฒนาขึ้นเอง / แบบผสม / ระบบภายนอก

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

สิ่งที่ทีม Billing และ Monetization ต้องกังวล

• ทีมที่ดูแลการออกบิลหรือการสร้างรายได้มีความรับผิดชอบที่หลากหลาย จนแม้แต่ผู้เชี่ยวชาญที่มีประสบการณ์ก็ยังเข้าใจได้ยาก
• เช่นเดียวกับความปลอดภัยหรือการจัดการวันที่ ระบบออกบิลก็ไม่ควรถูกสร้างขึ้นเองตั้งแต่ต้น

ปัญหา 14 ข้อของการออกบิลและการสร้างรายได้

• มีการเรียงลำดับปัญหาต่าง ๆ ที่เกิดขึ้นเมื่อสร้างระบบออกบิลขึ้นเองตามระดับความซับซ้อน
• ปัญหารวมถึง idempotency, การจัดการวันที่, การคิดสัดส่วนและการจัดการยอดคงเหลือ, การวัดการใช้งาน, รูปแบบใบแจ้งหนี้, และโครงสร้างลำดับชั้นลูกค้าที่ซับซ้อน
• ปัญหาเหล่านี้อาจยิ่งซับซ้อนขึ้นเมื่อขนาดธุรกิจเติบโตขึ้น

ทำไมถึงยาก

• ปัญหาบางอย่างเปลี่ยนแปลงบ่อยกว่าที่คาดไว้ ในขณะที่บางอย่างเมื่อตั้งค่าแล้วก็แทบไม่ต้องแตะอีก
• กฎภาษีของแต่ละประเทศทั่วโลกเปลี่ยนแปลงอยู่บ่อยครั้ง และปัญหาที่เกิดจากความผิดพลาดของลูกค้าก็เกิดขึ้นอย่างต่อเนื่อง

สิ่งที่ควรทำ

• ควรมอบปัญหาให้ผู้ให้บริการภายนอกจัดการให้มากที่สุดเท่าที่จะทำได้
• ใช้บริการอย่าง Chargebee, Solvimon, Stripe, Recurly เป็นต้น เพื่อจัดการการออกบิล
• ใช้บริการอย่าง Stigg เพื่อจัดการหน้าราคา การทดลอง และการกำหนดสิทธิ์
• ใช้ ERP สำหรับการรับรู้รายได้/การทำบัญชี

ความเห็นของ GN⁺

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

[GN⁺]

ความคิดเห็นใน Hacker News

• สรุปความคิดเห็นแรก:

  • ตั้งคำถามต่อแนวทางในการรับมือกับความยากของการสร้างระบบเรียกเก็บเงิน
  • ระบบเรียกเก็บเงินมีความซับซ้อน แต่หากไม่สามารถใช้โซลูชันที่มีอยู่แล้วอย่าง Stripe ได้ (เช่น บริษัทในเวเนซุเอลา) ก็จำเป็นต้องสร้างระบบเอง
  • เสนอความเห็นว่าน่าจะดีหากสามารถรวบรวมความรู้ วิธีการ และแพตเทิร์นการเขียนโปรแกรมไว้ในที่เดียว

• สรุปความคิดเห็นที่สอง:

  • มองว่าเป็นบทความที่มีประโยชน์สำหรับผู้ที่ต้องตัดสินใจเกี่ยวกับระบบเรียกเก็บเงิน
  • แชร์ความเห็นส่วนตัวว่าชอบแยกการเรียกเก็บเงินและเครดิตออกจากระบบให้มากที่สุดเท่าที่จะทำได้

• สรุปความคิดเห็นที่สาม:

  • เล่าประสบการณ์เกี่ยวกับความซับซ้อนของระบบเรียกเก็บเงิน พร้อมกล่าวว่าโลกของการเรียกเก็บเงินนั้นคาดเดาไม่ได้

• สรุปความคิดเห็นที่สี่:

  • ในฐานะผู้ร่วมก่อตั้งของ killbill.io อธิบายถึงความซับซ้อนของการสร้างระบบเรียกเก็บเงินและผลกระทบที่มีต่อหลายแผนก
  • แนะนำว่าระบบเรียกเก็บเงินต้องผสานเข้ากับระบบโดยรวม และสำหรับเรื่องนี้จำเป็นต้องมีทีมที่มีทั้งความรู้และแรงจูงใจเพียงพอ

• สรุปความคิดเห็นที่ห้า:

  • พูดถึงความซับซ้อนของการสร้างระบบขายผ่านพาร์ทเนอร์และความเป็นไปได้ในการค่อย ๆ สร้างมันขึ้นมา

• สรุปความคิดเห็นที่หก:

  • ชี้ปัญหาเกี่ยวกับการปิดงบบัญชีและการทำบัญชีกระแสเงินสด พร้อมระบุว่าปัญหาเหล่านี้เชื่อมโยงอย่างใกล้ชิดกับฝ่ายบัญชี

• สรุปความคิดเห็นที่เจ็ด:

  • เสนอความเห็นว่าไม่จำเป็นต้องมีทุกฟังก์ชันของระบบเรียกเก็บเงิน และสามารถค่อย ๆ สร้างตามการเติบโตของธุรกิจได้

• สรุปความคิดเห็นที่แปด:

  • ตั้งคำถามเกี่ยวกับแนวทางต่าง ๆ ในการจัดการสิทธิ์การใช้งานผลิตภัณฑ์ (entitlements) และระบบที่ใช้อยู่

• สรุปความคิดเห็นที่เก้า:

  • แชร์ประสบการณ์จากงานแรกของตน พร้อมแสดงความเห็นส่วนตัวว่าไม่อยากทำงานเกี่ยวกับระบบเรียกเก็บเงินอีก เพราะความซับซ้อนที่เกี่ยวข้องกับการปฏิบัติตาม PCI

• สรุปความคิดเห็นที่สิบ:

  • ตั้งคำถามต่อคำกล่าวอ้างว่าเพราะความซับซ้อนของระบบบางอย่าง (X) จึงไม่ควรสร้างเองและควรใช้โซลูชันสำเร็จรูป
  • สำหรับกรณีของตนเอง มองว่าต้องจัดการเพียงบางส่วนของความซับซ้อนที่จำเป็น จึงสามารถสร้างโซลูชันที่ง่ายกว่าขึ้นเองได้