BillingMeld: ทำไมเซิร์ฟเวอร์ควรตรวจสอบการซื้อ ไม่ใช่แค่แอปพลิเคชัน

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

สำหรับนักพัฒนากระบวนการนี้ซับซ้อนกว่ามาก ต้องยืนยันการซื้อเอง คำนึงถึงการต่ออายุ การหมดอายุของการสมัคร การคืนเงิน การอัปเดตสถานะธุรกรรม การเปลี่ยนอุปกรณ์ และความแตกต่างระหว่างร้านค้า Apple กับ Google

ปัญหาหลักเกิดขึ้นเมื่อเซิร์ฟเวอร์เริ่มเชื่อถือข้อมูลจากแอปพลิเคชันของลูกค้าเป็นแหล่งความจริง

หากแอปแจ้งว่า: «ซื้อเสร็จสิ้น» เซิร์ฟเวอร์จะเปิดการเข้าถึงและอิงจากข้อมูลสถานะเดียวกันที่ได้รับครั้งแรก แต่กระบวนการชีวิตของการซื้อยังไม่สิ้นสุด

การสมัครอาจต่ออายุ การต่ออายุอัตโนมัติอาจถูกปิด การชำระเงินอาจถูกคืนเงิน หรือธุรกรรมสามารถถูกยกเลิกโดยร้านค้าเอง

ดังนั้นใน BillingMeld การยืนยันการซื้อไม่ใช่โดยแอป แต่เป็นโดยเซิร์ฟเวอร์

ลูกค้ารายงาน แต่ไม่ได้ตัดสินใจ

ในสถาปัตยกรรมของ BillingMeld แอปพลิเคชันบนมือถือไม่ใช่แหล่งข้อมูลหลักเกี่ยวกับการซื้อ

ลูกค้าสามารถส่งข้อมูลเกี่ยวกับธุรกรรมที่เกิดขึ้น แต่เป็นเพียงฐานสำหรับการตรวจสอบเท่านั้น ส่วนตัดสินใจสุดท้ายเป็นของส่วนเซิร์ฟเวอร์ BillingMeld ซึ่งตรวจสอบข้อมูลผ่านโครงสร้างพื้นฐานของ Apple หรือ Google

นี่คือความแตกต่างเชิงหลัก

แอปในโทรศัพท์อาจทำงานกับข้อมูลเก่าไม่ได้รับการอัปเดตทันเวลา หรือส่งข้อมูลที่ไม็ตรงกับสภาวะปัจจุบันของการซื้อ

นอกจากนี้ ลูกค้าไม่ควรมีสิทธิ์ในการตัดสินใจเองว่าผู้ใช้งานสมควรได้รับการเข้าถึงแบบพชำระแล้วหรือไม่

BillingMeld ตรวจสอบเช่น:

• การซื้อดังกล่าวยังมีอยู่จริงหรือไม่;

• เกี่ยวข้องกับแอปหรือผลิตภัณฑ์ที่ถูกต้องหรือไม่;

• ระยะเวลาที่ชำระไว้ยังมีผลใช้ได้หรือไม่;

• ต่ออายุล่าสุดเกิดขึ้นหรือไม่;

• การต่ออายุอัตโนมัติถูกปิดใช้งานหรือไม่;

• มีการขอคืนเงินหรือไม่;

• ธุรกรรมถูกยกเลิกหรือไม่;

• ระยะเวลาที่ชำระไว้หมดอายุหรือไม่

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

แหล่งข้อมูลเดียวของความจริงสำหรับเซิร์ฟเวอร์

บริการที่เชื่อมต่อไม่จำเป็นต้องดำเนินการรวมระบบเต็มรูปแบบพร้อมกันกับ Apple และ Google

พวกเขาสามารถอ้างอิงไปยัง BillingMeld พร้อมรับสถานะการซื้อที่เป็นปกติแล้ว

เช่น การเข้าถึงยังใช้งานได้ อยู่ระยะเวลาที่ชำระหมดแล้ว การต่ออายุใหม่ได้รับการยืนยัน การต่ออายุอัตโนมัติถูกปิด หรือลงทะเบียนการยกเลิกการซื้อ

นี่ช่วยให้แบ่งความรับผิดชอบได้อย่างชัดเจน

Apple และ Google เป็นแหล่งข้อมูลสถานะของธุรกรรมร้านค้า BillingMeld จะตรวจสอบข้อมูลเหล่านี้ ปรับให้เป็นโมเดลเดียวกัน และเก็บสถานะปัจจุบันไว้ ซึ่งระบบปลายทางจะทำการตัดสินใจเข้าถึงบนฐานข้อมูลสถานะของ BillingMeld

สำหรับเซิร์ฟเวอร์ของผลิตภัณฑ์ นี่คือข้อตกลงเดียวแทนการผนึกระบบหลายแห่ง

ไม่จำเป็นต้องดำเนินการตามกฎของ App Store หรือ Google Play แยกกันในแต่ละบริการ แล้วพยายามปรับให้เข้ากันในรูปแบบ สถานะ หรือเหตุการณ์ต่าง ๆ

ทำไมไม่ควรพึ่งพาแค่ลูกค้าเต็มที่

แอปพลิเคชันบนอุปกรณ์ทำงานบนเครื่องของผู้ใช้

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

โดยไม่จำเป็นต้องมีการแทรกแซงจากผู้ใช้ ก็ยังทำให้ลูกค้าเป็นแหล่งข้อมูลสุดท้ายที่ไม่น่าเชื่อถือ

ตัวอย่างเช่น ผู้ใช้ทำการสมัครและรับการเข้าถึง และต่อมาอาจมีการคืนเงินหรือร้านค้าระงับธุรกรรม

หากเซิร์ฟเวอร์รับรู้แค่ข้อความเริ่มต้นจากลูกค้า ก็จะยังคงคิดว่าการซื้อยังคงใช้งานได้อยู่

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

หากระบบทำงานด้วยสถานะง่าย ๆ เช่น “สมัครสมาชิกมี / ไม่มี” ก็อาจปล่อยให้เข้าใช้งานผิดพลาดหรือปิดก่อนเวลาที่ควร

BillingMeld สร้างมาโดยใช้แนวคิดที่ต่างออกไป: ลูกค้าไม่ยืนยันสิทธิ์ของตนเอง แต่เป็นการรายงานเหตุการณ์ และเซิร์ฟเวอร์เป็นผู้กำหนดสถานะของการซื้อที่แท้จริง

การซื้อไม่ใช่เหตุการณ์เดียว

ข้อผิดพลาดที่สำคัญในสถาปัตยกรรมการชำระเงินคือการมองว่าการซื้อเป็นเหตุการณ์เดียว

แท้จริงแล้วมันมีวงจรชีวิตของตัวเอง

ก่อนอื่นมีการดำเนินการซื้อ จากนั้นร้านค้าจะยืนยัน แต่ละซื้อระยะเวลาที่ชำระไว้เริ่มต้นขึ้น และอาจมีการต่ออายุครั้งต่อไป

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

การชำระครั้งต่อไปอาจล้มเหลว หรือเกิดการคืนเงิน การซื้ออาจถูกยกเลิกในบางกรณี

ดังนั้น การรู้แค่ว่าสนับสนุนให้ “ซื้อครั้งเดียวก็พอ” ก็ไม่เพียงพออีกต่อไป

สำคัญคือเซิร์ฟเวอร์จำเป็นต้องเข้าใจว่าสถานะของการซื้อในปัจจุบันเป็นอย่างไร

การคืนเงินเป็นสิ่งที่ตรวจจับได้เสมอ

โดยเฉพาะเมื่อเกิดการคืนเงินหรือยกเลิกธุรกรรมแล้ว ข้อมูลจะมีการเปลี่ยนแปลงและต้องอัปเดตในระบบ

การซื้ออาจเคยถูกต้องและสมบูรณ์ แต่ภายหลังสถานะเปลี่ยนแปลง หาก BillingMeld ได้รับข้อมูลอัปเดต ก็จะปรับสถานะตาม และหากจำเป็นตรวจข้อมูลกับร้านค้าอีกครั้ง

ส่วนบริการที่เชื่อมต่อแล้วจะทำงานกับสถานะใหม่ทันที

ด้วยวิธีนี้ แอปพลิเคชันไม่จำเป็นต้องเชื่อในความถูกต้องของข้อมูลการซื้อครั้งเก่า ๆ อีกต่อไป และสามารถอัปเดตสถานะได้อย่างแม่นยำ

การยกเลิกสมัครและการสิ้นสุดการเข้าถึงไม่เท่ากัน

มีความแตกต่างสำคัญระหว่างการยกเลิกการสมัครอัตโนมัติและการสิ้นสุดการเข้าถึง

หากผู้ใช้ปิดการต่ออายุอัตโนมัติ นั่นไม่ได้หมายความว่าการเข้าถึงจะสิ้นสุดทันที

ระยะเวลาที่ชำระไว้ยังคงใช้งานได้จนกว่าจะหมดอายุ

ในกรณีนี้ BillingMeld ควรบันทึกข้อมูลว่า การต่ออายุในอนาคตถูกปิดไปแล้ว แต่ก็ต้องรู้วันหมดอายุในระยะเวลาที่ชำระไว้เช่นกัน

และหลังจากหมดอายุโดยไม่มีการต่ออายุใหม่ การเข้าถึงจะถูกพิจารณาว่าไม่ใช้งานอีกต่อไป

นี่เป็นหนึ่งในเหตุผลว่าทำไมการเก็บเพียงค่า boolean subscription = true สำหรับการชำระเงินปกติจึงไม่เพียงพอ

สถานะของการสมัครมักเกี่ยวข้องกับเวลาและเหตุการณ์ในวงจรชีวิตของมัน

การต่ออายุเป็นการตรวจสอบอีกแบบหนึ่ง

การต่ออายุไม่ได้จบลงแค่การชำระในครั้งแรก

เซิร์ฟเวอร์จำเป็นต้องรู้ว่ามีการต่ออายุในครั้งถัดไปหรือไม่ และมั่นใจว่าสถานะของช่วงเวลาถัดไปได้รับการยืนยันแล้ว

BillingMeld ตรวจสอบการเปลี่ยนแปลงนี้และอัปเดตสถานะของการสมัคร

หากการต่ออายุได้รับการยืนยัน สิทธิเข้าถึงจะดำเนินต่อไป

แต่ถ้าการจ่ายเงินครั้งถัดไปล้มเหลวหรือร้านค้าไม่รับรองระยะเวลาใหม่ ระบบก็ไม่ควรยกเลิกการต่ออายุโดยอัตโนมัติ

สำหรับผู้ใช้ นี่คือแนวทางปฏิบัติที่เป็นธรรมและสมเหตุสมผล: การเข้าถึงควรดำเนินต่อเนื่องตราบใดที่การสมัครสมาชิกยังมีผล

สำหรับนักพัฒนา นี่หมายความว่าไม่ต้องเขียนโลจิกในการต่ออายุซ้ำในแต่ละแอป

ตัวอย่างการทำงานปกติ

ผู้ใช้สมัครสมาชิกในแอปมือถือ

แอปส่งข้อมูลการซื้อและข้อมูลที่จำเป็นไปยัง BillingMeld แต่ข้อความนี้ยังไม่สามารถถือเป็นการยืนยันซื้อที่สมบูรณ์

BillingMeld ตรวจสอบธุรกรรมกับร้านค้า

หาก App Store หรือ Google Play ยืนยันการซื้อและสภาพตรงตามกฎของผลิตภัณฑ์ BillingMeld จะบันทึกสิทธิ์ใช้งานที่ใช้งานได้

หลังจากนั้น บริการเชื่อมต่อจะแสดงผลการใช้งานที่ได้รับชำระแล้วแก่ผู้ใช้

สภาพเหล่านี้ยังคงอยู่แม้จะเปลี่ยนข้อความจากลูกค้าในภายหลัง

หากการต่ออายุต่อเนื่อง BillingMeld จะอัปเดตเป็นช่วงเวลาที่ชำระใหม่

ถ้าผู้ใช้ปิดการต่ออายุ อัตราปัจจุบันก็สามารถใช้งานต่อจนกว่าจะหมดระยะ

แต่ถ้ามีการคืนเงินหรือยกเลิก การเปลี่ยนแปลงสถานะก็จะเกิดขึ้นอีกครั้ง

ในกรณีนี้ แอปไม่มีการเก็บ “ความจริง” ของการซื้อแยกต่างหาก แต่ทำงานกับสถานะที่รับรองและบันทึกโดย BillingMeld

การเปลี่ยนอุปกรณ์แล้วสถานะยังคงอยู่

โมเดลเซิร์ฟเวอร์นี้มีประโยชน์มาก เมื่อผู้ใช้เปลี่ยนโทรศัพท์หรือดาวน์โหลดแอปใหม่อีกครั้ง

สิทธิในการซื้อไม่ควรขึ้นอยู่กับรอยเท้าของอุปกรณ์ใดอุปกรณ์หนึ่งเท่านั้น

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

นี่เป็นอีกเหตุผลหนึ่งที่ควรหลีกเลี่ยงการเก็บข้อมูลสิทธิ์การเข้าถึงไว้ภายในแอปเพียงอย่างเดียว

สิ่งที่เป็นประโยชน์ต่อผู้พัฒนา

สำหรับทีมพัฒนาที่ปล่อยหลายแอป หรือทำงานใน iOS และ Android พร้อมกัน การจัดการการชำระเงินกลายเป็นงานสถาปัตยกรรมแยกต่างหากอย่างรวดเร็ว

ต้องคำนึงถึง:

• รูปแบบข้อมูลของ Apple และ Google ที่แตกต่างกัน

• การยืนยันการซื้อเริ่มต้น

• การต่ออายุสมาชิก

• การสิ้นสุดระยะเวลาการชำระ

• การปิดการต่ออายุอัตโนมัติ

• การคืนเงิน

• การยกเลิกธุรกรรม

• การติดตั้งแอปซ้ำ

• การเปลี่ยนอุปกรณ์

• การกู้คืนการซื้อ

• การเปลี่ยนแปลงสถานะที่ไม่ผ่านการควบคุมโดยลูกค้า

BillingMeld รวมกระบวนการนี้ไว้ในชั้นเฉพาะทาง ซึ่งเซิร์ฟเวอร์ของผลิตภัณฑ์ทำงานตามข้อตกลงเดียวและไม่ต้องเข้าใจรายละเอียดแต่ละร้านค้าเอง ซึ่งช่วยลดโค้ดซ้ำและลดความเสี่ยงที่แอปพลิเคชันต่างๆ จากบริษัทเดียวกันจะเข้าใจผิดเกี่ยวกับเหตุการณ์เดียวกัน

สิ่งสำคัญไม่ใช่ใบรับรอง แต่เป็นสิทธิ์ที่เป็นปัจจุบัน

สิ่งที่น่าสนใจที่สุดในสถาปัตยกรรมนี้คือการเปลี่ยนจากการตรวจสอบการซื้อแบบแยกเดี่ยวไปเป็นการควบคุมสภาพปัจจุบันของสิทธิ์

ข้อเท็จจริงที่ว่ามีการซื้อครั้งแรกสำเร็จแล้ว ยังไม่ตอบคำถามสำคัญของผลิตภัณฑ์ว่า:

ผู้ใช้ปัจจุบันทันและมีสิทธิ์ในฟังก์ชันแบบชำระเงินหรือไม่?

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

อาจมีการต่ออายุที่ได้รับการยืนยันแล้ว หรือการคืนเงิน การยกเลิกธุรกรรมจากร้านค้า

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

นี่คือข้อมูลที่ BillingMeld ส่งต่อไปยังบริการอื่น ๆ

BillingMeld เป็นตัวกลางระหว่างร้านค้าและผลิตภัณฑ์

โดยทำให้เกิดขอบเขตเชิงสถาปัตยกรรมที่ชัดเจน

ด้านหนึ่งเป็น App Store และ Google Play ที่มีรูปแบบ ข้อมูล เหตุการณ์ และวงจรชีวิตของการซื้อของตัวเอง อีกด้านหนึ่งเป็นแอปและบริการภายใน ที่ส่วนใหญ่ต้องการคำตอบง่าย ๆ: สิทธิ์ในปัจจุบันของผู้ใช้คืออะไร

ระหว่างสองฝ่ายคือ BillingMeld ซึ่งรับข้อมูลจากร้านค้า ตรวจสอบ เรียบเรียงให้เป็นโมเดลของตัวเอง แล้วให้ข้อมูลในรูปแบบที่เป็นปกติแก่โครงสร้างพื้นฐาน

ด้วยวิธีนี้ ผลิตภัณฑ์ไม่จำเป็นต้องเข้าใจรายละเอียดของแต่ละแพลตฟอร์มการชำระเงิน และสามารถดำเนินการได้อย่างราบรื่น

ทำไมสำคัญสำหรับผู้ใช้

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

หากการซื้อได้รับการยืนยันและระยะเวลาที่ชำระไว้ยังคงใช้งานได้ สิทธิ์ควรทำงานต่อเนื่อง

หากผู้ใช้ปิดการต่ออายุอัตโนมัติ ระยะเวลาแบบจ่ายแล้วไม่ควรหมดก่อนเวลา

ถ้ามีการต่ออายุใหม่ที่ได้รับการยืนยัน ระบบควรดำเนินการต่อ

และหากร้านค้าส่งคืนหรือยกเลิก การเปลี่ยนแปลงสิทธิ์ควรทำอย่างถูกต้อง

ในกรณีที่เปลี่ยนอุปกรณ์หรือเพียงแค่ติดตั้งแอปใหม่ ผู้ใช้ไม่ควรต้องพิสูจน์ทุกส่วนของโครงสร้างพื้นฐานว่า มีการซื้อที่แท้จริงอยู่

กฎง่าย ๆ จึงเป็น:

ลูกค้ารายงานการซื้อ ร้านค้าเป็นแหล่งข้อมูลภายนอกของสถานะ ปรับข้อมูลโดย BillingMeld และส่วนอื่น ๆ ตัดสินใจบนข้อมูลที่ได้รับการยืนยันแล้ว

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

รายละเอียดเพิ่มเติมเกี่ยวกับโครงการ: billingmeld.de.