English
ระบบจองตั๋วเชื่อม Payment Gateway: จุดเสี่ยงของระบบจองตั๋วเชื่อม Payment Gateway ไม่ได้อยู่ที่การเปิดหน้าจ่ายเงิน แต่อยู่ที่เหตุการณ์หลังจากนั้น: ลูกค้าจ่ายสำเร็จแต่ปิดหน้าเว็บ ผลชำระมาช้า หรือผู้ให้บริการส่งผลเดิมซ้ำ ระบบต้องออกตั๋วจากผลที่ยืนยันได้เพียงครั้งเดียว
ระบบจองตั๋วเชื่อม Payment Gateway ทำงานอย่างไร
ระบบสร้างคำสั่งซื้อพร้อมยอดที่คำนวณแล้วและรหัสอ้างอิงเฉพาะ ส่งลูกค้าไปยังช่องทางชำระที่รองรับ เมื่อได้รับผลจากผู้ให้บริการ ระบบตรวจความถูกต้องของธุรกรรมและยอด จากนั้นเปลี่ยนสถานะคำสั่งซื้อก่อนออกตั๋ว หน้าเว็บที่ลูกค้ากลับมาใช้แสดงผล แต่ไม่ควรเป็นหลักฐานชำระเงินเพียงอย่างเดียว
แยกสถานะจอง จ่าย และออกตั๋ว
สถานะที่ควรแยกอย่างน้อยคือรอชำระ ชำระสำเร็จ ชำระล้มเหลว หมดเวลาจอง และออกตั๋วแล้ว หากผลจ่ายมาหลังที่นั่งหมดเวลาล็อก ระบบต้องมีทางจัดการ เช่น คืนเงินหรือส่งให้เจ้าหน้าที่ตรวจ โดยไม่ออกตั๋วชนกับผู้ซื้อรายใหม่
คุมยอดเงินและการออกตั๋วซ้ำ
คำนวณราคาจากฝั่งระบบก่อนสร้างรายการชำระ ไม่รับยอดเงินที่ผู้ใช้แก้จากหน้าเว็บ ทุกเหตุการณ์จากผู้ให้บริการต้องผูกกับเลขธุรกรรมเดียวและประมวลผลซ้ำได้อย่างปลอดภัย เมื่อผลเดิมเข้ามาสองครั้ง ยอดขายและจำนวนตั๋วต้องเพิ่มเพียงครั้งเดียว
การกันที่นั่งระหว่างชำระ
กำหนดเวลาถือสิทธิ์ที่นั่งหรือโควตาให้สัมพันธ์กับเวลาจ่ายจริง แสดงเวลาที่เหลือแก่ลูกค้า และปล่อยสิทธิ์เมื่อหมดเวลา การถือสิทธิ์นานเกินไปทำให้หน้าขายดูเต็มโดยไม่มีเงินจริง ส่วนเวลาสั้นเกินไปทำให้ผู้ซื้อจ่ายทันแต่ไม่ได้ตั๋ว
กระทบยอดและช่วยลูกค้าเมื่อผิดปกติ
ทีมบริการควรค้นจากเลขคำสั่งซื้อ เห็นสถานะที่ตรวจจากผู้ให้บริการ เวลาและยอดจริง หากชำระสำเร็จแต่ตั๋วยังไม่ออก ควรมีคิวงานซ่อมรายการและส่งตั๋วใหม่ได้โดยไม่สร้างการชำระซ้ำ ฝ่ายการเงินต้องเทียบยอดสั่งซื้อ ยอดรับเงิน ค่าธรรมเนียม และยอดคืน
ความปลอดภัยและการทดสอบก่อนเปิดขาย
ประเด็นตรวจสอบสำหรับระบบจองตั๋วเชื่อม Payment Gateway
ใช้ช่องทางชำระที่จัดการข้อมูลบัตรตามข้อกำหนดของผู้ให้บริการ จำกัดสิทธิ์ดูธุรกรรมและบันทึกเหตุการณ์โดยไม่เก็บข้อมูลอ่อนไหวเกินจำเป็น ทดสอบจ่ายสำเร็จ ล้มเหลว ยกเลิก จ่ายช้า ผลซ้ำ และการหมดเวลาของที่นั่งพร้อมกัน
สถาปัตยกรรมการชำระ: หน้าเว็บไม่ควรถือข้อมูลทั้งหมด
แบ่งหน้าที่ระหว่างหน้าซื้อตั๋ว ระบบคำสั่งซื้อ ระบบกันโควตา และตัวเชื่อมผู้ให้บริการชำระเงิน ผู้ให้บริการรับหน้าที่ตามช่องทางจ่าย ส่วนระบบตั๋วเก็บเลขอ้างอิงกับสถานะที่จำเป็น การออกตั๋วและส่งอีเมลอาจทำผ่านคิวงานหลังบันทึกผลชำระแล้ว เพื่อให้การส่งอีเมลล้มเหลวไม่ทำให้ข้อมูลรับเงินหายไปด้วย
ตัวอย่าง: จ่ายสำเร็จก่อนหมดเวลา แต่ผลยืนยันมาทีหลัง
ลูกค้าจ่ายในนาทีสุดท้ายของเวลาล็อกที่นั่ง แต่ข้อความยืนยันมาถึงหลังระบบปล่อยที่นั่งแล้ว ต้องตรวจทั้งเวลาธุรกรรมและสถานะสิทธิ์ปัจจุบัน ไม่ควรสรุปจากเวลาที่ข้อความเข้าระบบอย่างเดียว หากที่นั่งถูกขายให้คนอื่นไปแล้ว ให้เข้าสู่กระบวนการแก้ไขที่ตกลงไว้ เช่น คืนเงินหรือเสนอที่นั่งใหม่โดยลูกค้ายอมรับ กติกานี้ควรกำหนดก่อนเปิดขาย
การส่งผลซ้ำและเหตุการณ์ที่ไม่ได้มาตามลำดับ
ระบบรับผลชำระต้องจดจำเลขเหตุการณ์หรือเลขธุรกรรมที่เคยประมวลผลแล้ว และตรวจสถานะล่าสุดก่อนเปลี่ยนข้อมูล ไม่ควรให้ข้อความล้มเหลวที่มาช้าทับรายการที่ยืนยันสำเร็จไปแล้ว เอกสารผู้ให้บริการแต่ละรายเป็นจุดอ้างอิงสำหรับรูปแบบผลชำระ วิธีตรวจความถูกต้อง และการส่งซ้ำ ทีมพัฒนาต้องทดสอบตามพฤติกรรมของรายที่ธุรกิจเลือกจริง
เลือก Payment Gateway จากงานหลังบ้านด้วย
นอกจากช่องทางชำระและค่าธรรมเนียม ให้พิจารณาว่าค้นธุรกรรม คืนบางส่วน กระทบยอด และดูเหตุการณ์ผิดปกติได้สะดวกหรือไม่ ประเมินเงื่อนไขสมัคร ระยะเวลาเชื่อม สภาพแวดล้อมทดสอบ และการช่วยเหลือเมื่อเปิดขาย หากมีหลายผู้ให้บริการ ควรให้เลขคำสั่งซื้อกลางเชื่อมธุรกรรมทุกช่องทาง เพื่อไม่ให้ฝ่ายบริการต้องค้นคนละระบบ
เช็กลิสต์ก่อนนำระบบไปใช้งาน
- ระบบตรวจยอดและเลขคำสั่งซื้อจากข้อมูลที่เชื่อถือได้
- ผลชำระเดิมเข้าซ้ำไม่ออกตั๋วเพิ่ม
- รายการรับเงินแล้วแต่ยังไม่ออกตั๋วมีทางซ่อม
- ทดสอบจ่ายช้าหลังโควตาหมดอายุ
เอกสาร Stripe ระบุว่าการรับ webhook ต้องตรวจลายเซ็น และระบบควรเตรียมรับเหตุการณ์ซ้ำหรือเหตุการณ์ที่ไม่ได้มาถึงตามลำดับ แนวทางเชื่อมต้องตรวจตามเอกสารของผู้ให้บริการที่เลือกใช้ — Stripe: Webhooks
สรุป
การเชื่อม Payment Gateway ให้พร้อมขายจริงต้องคุมความสัมพันธ์ระหว่างเงินกับสิทธิ์ตั๋ว จุดสำคัญคือรับผลชำระที่ตรวจสอบได้ จัดการผลซ้ำและผลล่าช้า และมีทางช่วยลูกค้าเมื่อรับเงินแล้วแต่ตั๋วยังไม่ออก การทดสอบเส้นทางผิดปกติจึงสำคัญพอ ๆ กับการจ่ายสำเร็จ
อ่านต่อ: ระบบคืนเงินและยกเลิกตั๋วออนไลน์ควรออกแบบอย่างไร
คำถามที่พบบ่อย
ตรวจเลขคำสั่งซื้อกับธุรกรรมจากผู้ให้บริการก่อน แล้วซ่อมสถานะหรือส่งตั๋วโดยไม่เรียกเก็บเงินซ้ำ
ไม่ควรใช้เพียงอย่างเดียว เพราะลูกค้าอาจไม่กลับมาหน้าเว็บหรือข้อมูลหน้าเว็บถูกแก้ได้
เพื่อรับผลชำระจากฝั่งผู้ให้บริการโดยตรงและจัดการกรณีผู้ซื้อปิดหน้าเว็บหลังจ่าย
ได้ แต่ต้องมีเลขคำสั่งซื้อกลางและเก็บเลขธุรกรรมแยกตามผู้ให้บริการ พร้อมกำหนดวิธีกระทบยอดและคืนเงินของแต่ละช่องทาง
ไม่ควร ถ้ามีผลรับเงินที่ยืนยันแล้ว ให้ซ่อมขั้นออกหรือส่งตั๋วจากรายการเดิมโดยไม่สร้างการชำระใหม่
