ระบบ B2B E-commerce สำหรับสั่งซื้อสินค้าระหว่างธุรกิจ

Payment Gateway คืออะไร? เว็บไซต์ขายของต้องเชื่อมอย่างไร

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

ระบบ B2B E-commerce สำหรับสั่งซื้อสินค้าระหว่างธุรกิจ

Payment Gateway ทำหน้าที่อะไร

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

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

Flow การชำระเงินที่ควรออกแบบ

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

ระบบควรตรวจ callback หรือ webhook ตามคู่มือผู้ให้บริการ ตรวจลายเซ็นหรือกลไกยืนยัน และป้องกันการประมวลผล event ซ้ำ จากนั้นบันทึก transaction reference ที่ทีมตรวจสอบได้

คืนเงิน ยกเลิก และกระทบยอด

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

เปรียบเทียบรายงานธุรกรรมกับยอดรับเงินจริงและค่าธรรมเนียมเป็นประจำ อย่าให้สถานะในเว็บเป็นแหล่งเดียวสำหรับงานบัญชี

เช็กลิสต์ก่อนเปิดรับเงินจริง

ทดสอบ sandbox การยืนยันล้มเหลว webhook ซ้ำ การปิดหน้ากลางคัน และการคืนเงิน ตรวจการใช้ HTTPS การเก็บ secret ในฝั่ง server การจำกัดสิทธิ์ และการไม่บันทึกข้อมูลบัตรที่ไม่จำเป็น

ผู้ให้บริการอย่าง Stripe มีหลายแนวทาง checkout ทั้งหน้า hosted และองค์ประกอบแบบฝัง รายละเอียดควรเลือกให้ตรงกับความต้องการและข้อกำหนดของผู้ให้บริการ อ่าน Stripe Checkout quickstarts เป็นตัวอย่างเอกสารการเชื่อมต่อ

คำถามที่พบบ่อย

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

ไม่เสมอ ควรยืนยันจากข้อมูลฝั่ง server หรือ webhook ตามเอกสารผู้ให้บริการ ไม่ใช้ข้อความจาก browser เพียงอย่างเดียว

ควรทดสอบสภาพแวดล้อมทดสอบก่อน เพื่อครอบคลุมกรณีผ่าน ไม่ผ่าน ยกเลิก และ callback ซ้ำ

ได้ แต่ควรทำ mapping สถานะ วิธีชำระ ค่าธรรมเนียม และวิธีกระทบยอดให้เป็นมาตรฐานเดียว

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

เราใช้คุกกี้เพื่อปรับปรุงประสบการณ์ของคุณบนเว็บไซต์ของเรา การเรียกดูเว็บไซต์นี้แสดงว่าคุณยอมรับการใช้คุกกี้ของเรา