เชื่อม PromptPay กับเว็บไซต์อย่างเป็นระบบ

ก่อนเริ่ม: QR กับการยืนยันเงินเป็นคนละขั้นตอน

การแสดง QR ช่วยให้ลูกค้าเริ่มจ่าย แต่ไม่ใช่หลักฐานว่าร้านได้รับเงินแล้ว ระบบขายต้องมีสถานะคำสั่งซื้อที่แยก “รอชำระ”, “กำลังตรวจสอบ”, “ชำระสำเร็จ”, “หมดอายุ” และ “ต้องตรวจด้วยคน” เพื่อไม่ปล่อยสินค้าหรือยืนยันบริการจากภาพหน้าจอเพียงอย่างเดียว

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

ดูขอบเขตเว็บไซต์ขายของและการเชื่อมชำระเงิน →

เลือกรูปแบบรับเงินจาก workflow ของธุรกิจ

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

ผูกคำสั่งซื้อกับรายการชำระอย่างตรวจสอบได้

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

ยืนยันสถานะจากผู้ให้บริการฝั่งเซิร์ฟเวอร์

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

ออกแบบให้รับรายการซ้ำและเหตุการณ์ผิดลำดับ

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

ให้ทีมบัญชีและบริการลูกค้าตรวจย้อนหลังได้

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

ข้อมูลที่ควรเตรียมก่อนขอประเมินงาน

ส่งตัวอย่าง flow การซื้อ ประเภทสินค้า จำนวนช่องทางรับเงิน ระบบสต็อก/ออกใบเสร็จที่ใช้ และกรณีคืนเงินหรือยกเลิกที่เกิดจริง ข้อมูลเหล่านี้ช่วยแยกว่าควรใช้ระบบสำเร็จรูป ปรับ checkout เดิม หรือพัฒนาการเชื่อมต่อเฉพาะ

ชุดทดสอบ PromptPay ก่อนเปิดขาย

ใช้ sandbox หรือวิธีทดสอบที่ผู้ให้บริการระบุ ตรวจ expected amount order reference และสถานะจากเซิร์ฟเวอร์ กำหนดวิธีกระทบยอดและกรณีคืนเงินตาม provider อย่าอ้างว่า QR ที่สร้างเองรองรับการยืนยันอัตโนมัติโดยไม่มีระบบรับ event หรือสอบถามสถานะที่เชื่อถือได้

ข้อมูลที่ควรส่งให้ทีมประเมิน

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

อ่านคู่มือที่เกี่ยวข้อง →