เช็กลิสต์ความปลอดภัยเมื่อเชื่อม API รับชำระเงินเข้าระบบร้าน

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

1. การเก็บและใช้คีย์ API

API ของ PPay ยืนยันตัวตนด้วย API key ที่ส่งในหัว Authorization: Bearer คีย์นี้เท่ากับสิทธิ์ใช้งานบัญชีของคุณ จึงควรปฏิบัติดังนี้

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

รายละเอียดเพิ่มเติมอ่านที่ ความปลอดภัยของ API key

2. ตรวจ webhook ให้แน่ใจว่ามาจากต้นทางจริง

เอกสาร API ระบุว่า webhook มีลายเซ็นแบบ HMAC-SHA256 ในหัว Signature ที่ประกอบด้วยเวลาและค่าลายเซ็น ฝั่งรับควรทำดังนี้

1. คำนวณลายเซ็นจากเนื้อหาดิบ (raw body) และความลับของ webhook ตามวิธีที่เอกสารกำหนด
2. เทียบด้วยฟังก์ชันเปรียบเทียบแบบเวลาคงที่ ไม่ใช้เครื่องหมายเท่ากับธรรมดา
3. ตรวจเวลาในลายเซ็นว่าอยู่ในช่วงที่ยอมรับได้ เพื่อกันการนำข้อความเก่ามาส่งซ้ำ
4. ออกแบบให้รับซ้ำได้อย่างปลอดภัย (idempotent) เพราะ webhook อาจถูกส่งมาหลายครั้ง

พื้นฐานเรื่อง webhook ดูได้ที่ พื้นฐาน webhook สำหรับการชำระเงิน และรายละเอียดจริงอยู่ที่ เอกสาร API

3. อย่าเชื่อข้อมูลจากฝั่งผู้ใช้

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

4. จัดการข้อผิดพลาดและการลองใหม่

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

5. log และการเฝ้าระวัง

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

6. ความปลอดภัยของระบบรอบข้าง

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

เช็กลิสต์ฉบับย่อ

หัวข้อ	ตรวจแล้ว
คีย์อยู่ในตัวแปรสภาพแวดล้อม ไม่อยู่ในโค้ด	[ ]
เรียก API ผ่านเซิร์ฟเวอร์เท่านั้น	[ ]
ตรวจลายเซ็น webhook และเวลา	[ ]
รองรับ webhook ซ้ำได้	[ ]
คำนวณยอดฝั่งเซิร์ฟเวอร์	[ ]
log ไม่มีข้อมูลลับ	[ ]
มีแผนหมุนเวียนคีย์	[ ]

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