สิ่งที่ AI ทำพลาดเมื่อออกแบบระบบชำระเงิน (and How to Fix It)
AI สามารถออกแบบระบบชำระเงินที่ดูดีได้ในเวลาไม่กี่นาที แต่ความล้มเหลวกลับซ่อนอยู่ในเรื่องการคำนวณตัวเลข ภาษี การคืนเงิน และการชำระเงิน นี่คือจุดที่ระบบชำระเงินที่สร้างโดย AI มักจะพัง และวิธีแก้ไขในแต่ละจุด

AI มักจะทำสิ่งหนึ่งผิดพลาดเสมอเมื่อออกแบบระบบชำระเงิน: มันออกแบบมาเพื่อการสาธิต ไม่ใช่เพื่อการทำรายการครั้งที่หนึ่งหมื่น ลองขอให้เครื่องมือสร้างแอปด้วย AI ออกแบบระบบชำระเงินดู แล้วคุณจะได้ระบบที่ดูน่าเชื่อถือภายในไม่กี่นาที ตะกร้าสินค้าที่สะอาด ปุ่มที่จัดวางอย่างเป็นระเบียบ หน้าจอชำระเงินที่ดูมั่นใจ แต่ความล้มเหลวกลับซ่อนอยู่ในทุกสิ่งที่ภาพหน้าจอไม่สามารถแสดงได้: วิธีที่ขั้นตอนการทำงานจัดการกับการคืนเงิน การแยกชำระเงิน กฎภาษี หรือแถวลูกค้าที่ยาวเหยียดในเวลาเที่ยงวันเสาร์
วิธีแก้ไขไม่ใช่การป้อนคำสั่ง (prompt) ที่ดีขึ้น แต่เป็นการตัดสินใจว่าส่วนใดของระบบชำระเงินที่ AI ควรเป็นผู้ดูแล และส่วนใดที่ไม่ควรปล่อยให้ AI คิดขึ้นมาเองโดยเด็ดขาด นี่คือจุดที่ระบบชำระเงินที่สร้างโดย AI มักจะพังจริง ๆ และสิ่งที่คุณควรทำในแต่ละกรณี
ทำไมระบบชำระเงินที่ออกแบบโดย AI จึงดูดีแต่ใช้งานจริงไม่ได้?
มีสองเหตุผล ประการแรก AI เรียนรู้การออกแบบระบบชำระเงินจากระบบชำระเงินที่มีอยู่เดิม ซึ่งระบบเหล่านั้นก็อยู่ในระดับปานกลาง สถาบัน Baymard ระบุว่าอัตราการละทิ้งตะกร้าสินค้าออนไลน์โดยเฉลี่ยอยู่ที่ 70.22%¹ และพบว่าระบบชำระเงินโดยเฉลี่ยในสหรัฐฯ แสดงช่องกรอกข้อมูลถึง 23.48 ช่อง ในขณะที่ขั้นตอนการทำงานที่เหมาะสมที่สุดต้องการเพียง 12 ถึง 14 ช่องเท่านั้น¹ โมเดลที่ได้รับการฝึกฝนจากค่าเฉลี่ยจึงสร้างผลลัพธ์ที่อยู่ในระดับเฉลี่ย รวมถึงข้อผิดพลาดเหล่านั้นด้วย
ประการที่สอง ความลำเอียงแบบกรณีปกติราบรื่น (happy-path bias) ซอฟต์แวร์ที่ถูกสร้างขึ้นมักถูกตัดสินในแบบเดียวกับการสาธิต: กรณีปกติทำงานได้หรือไม่? แต่ระบบชำระเงินถูกตัดสินในแบบเดียวกับเครื่องเก็บเงิน: ทุกกรณีทำงานได้ถูกต้องทุกครั้งต่อหน้าลูกค้าหรือไม่? นั่นเป็นมาตรฐานที่แตกต่างกัน และช่องว่างระหว่างสองมาตรฐานนี้จะยังคงมองไม่เห็นจนกว่าจะมีเงินจริงไหลผ่านระบบ

สิ่งที่ AI ทำพลาดจริง ๆ ในระบบชำระเงินคืออะไร?
ความล้มเหลวห้าประการที่ปรากฏขึ้นซ้ำแล้วซ้ำเล่า (สำหรับช่องว่างด้านโครงสร้างพื้นฐานที่ลึกซึ้งยิ่งขึ้นเบื้องหลังสิ่งเหล่านี้ โปรดดูที่ คุณสามารถสร้าง POS ด้วย Lovable หรือ Replit ได้หรือไม่? รายการนี้จะเน้นเฉพาะตัวระบบชำระเงินเท่านั้น)
การคำนวณตัวเลข โค้ดที่สร้างขึ้นมักจะคำนวณค่าเงินด้วยเลขทศนิยมลอยตัว (floating point ซึ่งเป็นการคำนวณทศนิยมที่ปัดเศษอย่างไม่แน่นอน) ส่งผลให้เศษสตางค์คลาดเคลื่อนไปในส่วนลด ภาษี และการแยกชำระเงิน อาการจะปรากฏขึ้นตอนปิดยอด: ยอดรวมไม่ตรงกัน (ไม่ตรงกันแม้แต่เศษสตางค์) กับ รายงานสรุปยอดประจำวัน ของคุณ
ภาษี AI มักจะเขียนอัตราภาษีตายตัวไว้ในโค้ด แต่ภาษีมูลค่าเพิ่มหรือภาษีการขายจริงขึ้นอยู่กับเขตอำนาจศาล ประเภทสินค้า ข้อยกเว้น และวันที่ และมันเปลี่ยนแปลงได้โดยไม่แจ้งให้โค้ดของคุณทราบ ระบบชำระเงินที่เดาภาษีไม่ใช่ระบบชำระเงิน แต่เป็นภาระผูกพันทางกฎหมายที่มีหน้าตาโปรแกรมสวยงาม
กรณีที่ไม่เป็นไปตามปกติ (unhappy paths) การคืนเงิน การยกเลิกรายการ การชำระเงินบางส่วน การปรับเปลี่ยนราคาด้วยตนเอง การเชื่อมต่อหลุดระหว่างการเรียกเก็บเงิน การสาธิตไม่เคยทดสอบสิ่งเหล่านี้ แต่เคาน์เตอร์แคชเชียร์ต้องเจอทุกวัน ระบบชำระเงินที่สร้างโดย AI ส่วนใหญ่ไม่มีฟังก์ชันเหล่านี้เลย
ความเร็วของพนักงานแคชเชียร์ AI คัดลอกรูปแบบของอีคอมเมิร์ซที่สร้างขึ้นสำหรับผู้ซื้อที่ชำระเงินเพียงครั้งเดียว แต่พนักงานแคชเชียร์ต้องใช้งานขั้นตอนเดียวกันนี้หลายร้อยครั้งต่อกะ ดังนั้นการแตะเพิ่มขึ้นทุกครั้งจะสะสมกลายเป็นเวลาที่ลูกค้าต้องยืนรอคิว แม้แต่ทางเลือกเล็ก ๆ น้อย ๆ ก็เปลี่ยนพลวัตของหน้าเคาน์เตอร์ได้ เช่น จุดที่แสดงข้อความแจ้งเตือนเรื่องทิป ก็เป็นการตัดสินใจที่สำคัญในตัวเอง
การชำระเงิน ปุ่มชำระเงินไม่ใช่การชำระเงินจริง การรับบัตรด้วยตนเองต้องใช้ผู้ให้บริการประมวลผลการชำระเงิน การปฏิบัติตามมาตรฐาน PCI (กฎความปลอดภัยของข้อมูลในอุตสาหกรรมบัตรชำระเงิน) และฮาร์ดแวร์เครื่องอ่านบัตรที่ได้รับการรับรอง สิ่งเหล่านี้ไม่สามารถสร้างขึ้นจากคำสั่ง (prompt) ได้ แต่ต้องมีอยู่จริง สิ่งที่โครงสร้างพื้นฐานการชำระเงินรวมอยู่จริง ๆ นั้นมีรายละเอียดมากกว่าที่คนส่วนใหญ่คิด

คุณจะแก้ไขระบบชำระเงินที่ออกแบบโดย AI ได้อย่างไร?
แบ่งงานออกเป็นสองส่วน AI นั้นเก่งจริง ๆ ในส่วนของการออกแบบ: เลย์เอาต์ ลำดับขั้นตอน การใช้คำ และการปรับแต่งหน้าจอให้เข้ากับวิธีการขายจริงของร้านค้าของคุณ ปล่อยให้มันดูแลส่วนนั้นไป ส่วนเรื่องเงิน (การคำนวณตัวเลข ภาษี การประมวลผลการชำระเงิน บันทึกการทำรายการ) ควรมาจากโครงสร้างพื้นฐานทางการค้าที่เป็นแบบกำหนดแน่นอน (deterministic ซึ่งให้ผลลัพธ์ที่ถูกต้องเหมือนเดิมทุกครั้ง) ไม่ใช่จากโค้ดที่คิดขึ้นมาใหม่ตามแต่ละคำสั่ง
"แค่ป้อนคำสั่งให้จัดการภาษีอย่างถูกต้อง" ไม่สามารถแก้ปัญหานี้ได้ เพราะคุณไม่สามารถบอกได้จากการมองดูว่ามันทำงานได้จริงหรือไม่ ระบบชำระเงินอาจคำนวณผิดพลาดไปไม่กี่เซนต์ต่อรายการเป็นเวลาหลายเดือนก่อนที่จะมีใครสังเกตเห็น ดังนั้นการแก้ไขจึงต้องทำที่โครงสร้าง:
กำหนดขอบเขตแทนการป้อนคำสั่ง ใช้แพลตฟอร์มที่ยอดรวม ภาษี และวิธีการชำระเงินถูกสร้างมาในตัวแล้ว และ AI ทำได้เพียงจัดวางสิ่งเหล่านั้น ไม่ใช่สร้างขึ้นมาใหม่
ทดสอบกรณีที่ไม่เป็นไปตามปกติก่อนเปิดใช้งานจริง ทดลองทำการคืนเงิน การยกเลิกรายการ การแยกชำระเงิน และการยกเลิกระหว่างการชำระเงิน หากขาดสิ่งใดสิ่งหนึ่งไป แสดงว่าคุณมีเพียงระบบสาธิต ไม่ใช่ระบบชำระเงินจริง
ตรวจสอบยอดเงินตั้งแต่วันแรก เปรียบเทียบยอดรวมของระบบชำระเงินกับบันทึกของผู้ให้บริการประมวลผลการชำระเงินหลังจากการขายจริงวันแรก ความคลาดเคลื่อนของเศษสตางค์จะปรากฏให้เห็นทันทีหรือไม่ก็ไม่เกิดขึ้นเลย
เฝ้าดูการเลี่ยงขั้นตอนการทำงาน หากพนักงานหาวิธีเลี่ยงขั้นตอนการทำงานในสัปดาห์แรก แสดงว่าการออกแบบนั้นล้มเหลว จงแก้ไขก่อนที่ การเลี่ยงขั้นตอนจะกลายเป็นระบบหลักที่ใช้จริง

สรุปแล้ว AI ทำอะไรผิดพลาดเมื่อออกแบบระบบชำระเงิน?
มันทำให้ภาพลักษณ์ภายนอกดูถูกต้องแต่ระบบภายในกลับพัง: ขั้นตอนการทำงานแบบกรณีปกติราบรื่น การคำนวณเงินที่คิดขึ้นมาเอง การเดาภาษี และไม่มีวิธีจัดการสำหรับการคืนเงิน การแยกชำระเงิน หรือการชำระเงินด้วยบัตรต่อหน้า สิ่งเหล่านี้ไม่มีทางแก้ไขได้ด้วยคำสั่งที่ดีขึ้น แต่แก้ไขได้โดยการวาง AI ไว้บนโครงสร้างพื้นฐานที่จัดการเรื่องเงินอยู่แล้ว กฎเหล็กคือ: ปล่อยให้ AI ออกแบบขั้นตอนการทำงาน แต่อย่าปล่อยให้มันคิดคำนวณเรื่องเงินเอง
การแบ่งส่วนดังกล่าวคือแนวคิดเบื้องหลังเครื่องมือสร้างตามคำสั่งอย่าง Build ของ Final ที่ซึ่งคุณเพียงอธิบายระบบชำระเงินที่คุณต้องการ โดยที่ยอดรวม ภาษี และการทำรายการของ Final Pay ด้านล่างนั้นมาจากระบบที่คำนวณถูกต้องเสมอ หากต้องการดูการใช้งานจริง สร้างขั้นตอนการทำงานแรกของคุณ ในเวลาประมาณสิบนาที หรือมองภาพรวมด้วย AI สำหรับธุรกิจ: สิ่งที่ทำได้ (และทำไม่ได้)
คำถามที่พบบ่อย
AI สามารถออกแบบระบบชำระเงินที่ดีได้หรือไม่?
ได้ สำหรับส่วนของการออกแบบ: เลย์เอาต์ ลำดับขั้นตอน ข้อความ และการปรับหน้าจอให้เข้ากับวิธีการขายของร้านค้า แต่จะล้มเหลวเมื่อต้องคิดคำนวณตัวเลขทางการเงิน ตรรกะภาษี และการจัดการการชำระเงิน ซึ่งจำเป็นต้องมาจากโครงสร้างพื้นฐานด้านการค้าที่แท้จริง
ทำไมระบบชำระเงินที่สร้างโดย AI ถึงล้มเหลวในร้านค้าจริง?
ระบบเหล่านี้ถูกสร้างและประเมินจากกรณีการใช้งานปกติ (happy path) แต่เคาน์เตอร์จริงต้องเจอกับการคืนเงิน การยกเลิกรายการ การแยกชำระเงิน กรณีภาษีที่ซับซ้อน และการเชื่อมต่อหลุดในทุกๆ วัน ซึ่งโค้ดที่สร้างขึ้นมักจะไม่สามารถจัดการกับปัญหาเหล่านี้ได้
สิ่งใดที่ AI ไม่ควรเข้ามาจัดการในระบบชำระเงิน?
การคำนวณสกุลเงิน การคำนวณภาษี และการประมวลผลการชำระเงิน สิ่งเหล่านี้ต้องการโครงสร้างพื้นฐานที่แน่นอน และสำหรับการชำระเงินแบบต่อหน้า (card-present) จะต้องเป็นไปตามมาตรฐาน PCI และใช้ฮาร์ดแวร์เครื่องอ่านบัตรที่ได้รับการรับรอง ซึ่งไม่มีสิ่งใดเลยที่สามารถสร้างขึ้นได้จากคำสั่ง (prompt)
ฉันจะทดสอบระบบชำระเงินที่สร้างด้วย AI ก่อนนำไปใช้งานจริงได้อย่างไร?
ทดสอบกรณีการใช้งานที่เกิดปัญหา (unhappy path): การคืนเงิน การยกเลิกรายการ การแยกชำระเงิน และการยกเลิกระหว่างหักเงิน จากนั้นให้ตรวจสอบยอดรวมของวันแรกที่ใช้งานจริงกับบันทึกของผู้ให้บริการประมวลผลการชำระเงินให้ตรงกันทุกบาททุกสตางค์
