วางขั้นตอนทดสอบการเชื่อม API ตรวจสลิปก่อนขึ้นระบบจริง

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

ขั้นที่ 1 เตรียมสภาพแวดล้อม

เริ่มจากสมัครสมาชิกและสร้าง API key (ขึ้นต้นด้วย ppk_) ซึ่งระบบแสดงคีย์เต็มครั้งเดียว จึงควรเก็บเข้า environment variable หรือ secret manager ทันที ไม่ใส่ในโค้ดและไม่ commit ลง Git ถ้าทีมของคุณมีหลายสภาพแวดล้อม เช่น ทดสอบและใช้งานจริง ให้แยกคีย์ตามแอปพลิเคชัน คู่มือระบุว่าสร้างได้สูงสุด 10 คีย์ต่อบัญชี และเพิกถอนได้ทันทีหากรั่วไหล ดูเพิ่มที่ การดูแล API key

ข้อควรจำคือการตรวจสลิปจริงหักโควต้าหรือเครดิตตามปกติ จึงควรวางแผนจำนวนรอบทดสอบและเตรียมรูปสลิปไว้ล่วงหน้า การสร้างรายการรับชำระ (POST /api/v1/invoices) และการสร้าง QR พร้อมเพย์ไม่หักโควต้า จึงเหมาะกับการทดสอบขั้นต้น

ขั้นที่ 2 ยิงด้วย cURL ก่อนเขียนโค้ด

ก่อนเขียนโค้ดจริง ให้ยิงด้วย cURL เพื่อดูหน้าตาผลลัพธ์ที่แท้จริง

curl -X POST "$API_BASE/api/v1/verify" \
  -H "Authorization: Bearer $PPAY_API_KEY" \
  -F "file=@slip.jpg"

สังเกตฟิลด์ valid, code, slip.amount, slip.receiver และ billing จดไว้ว่าข้อมูลใดบ้างที่ระบบของคุณต้องใช้ จากนั้นทดสอบกรณีผิดพลาดเจตนา เช่นไม่แนบ header คีย์ จะได้ 401 INVALID_API_KEY หรือแนบไฟล์ที่ไม่ใช่รูป จะได้ 400 INVALID_FILE คำขอที่ถูกปฏิเสธแบบนี้ไม่หักเงิน

ขั้นที่ 3 ชุดเคสสลิปที่ควรทดสอบ

เตรียมรูปสลิปให้ครอบคลุมสถานการณ์ต่อไปนี้ (ใช้สลิปจากการโอนจริงจำนวนน้อยของคุณเอง)

เคส	สิ่งที่คาดหวัง
สลิปจริง โอนเข้าบัญชีถูกต้อง	valid เป็น true ระบบของคุณเทียบยอดผ่าน
ส่งสลิปใบเดิมซ้ำ	valid เป็น false และ code เป็น DUPLICATE_SLIP
สลิปที่โอนเมื่อกี้	อาจได้ SLIP_NOT_FOUND ลองใหม่ใน 1-2 นาที
รูปที่ถูกครอปหรือบีบอัดมาก	อ่าน QR ไม่ได้ ระบบแสดงข้อความให้ลูกค้าส่งรูปต้นฉบับ
ไฟล์ใหญ่เกิน 5MB	413 FILE_TOO_LARGE
ยอดน้อยกว่าออเดอร์	ระบบของคุณปฏิเสธเอง แม้ valid
โอนเข้าบัญชีอื่น (เมื่อส่ง shop)	valid เป็น false และ code เป็น RECEIVER_MISMATCH

ข้อสุดท้ายใช้ได้เมื่อคุณผูกร้านค้าและส่งฟิลด์ shop ไปด้วย อย่าข้ามเคสยอดน้อยกว่าออเดอร์ เพราะคู่มือระบุชัดว่าการเทียบยอดเป็นหน้าที่ของระบบคุณ

ขั้นที่ 4 ทดสอบแบบคิวและ Webhook

ตั้งค่า URL Webhook (ต้องเป็น https และโดเมนสาธารณะ) แล้วกด "ส่งทดสอบ" ในหน้า API สำหรับนักพัฒนา จะได้เหตุการณ์ webhook.test ที่ใช้ตรวจว่าเซิร์ฟเวอร์ของคุณรับได้และตรวจลายเซ็นผ่าน ระหว่างพัฒนาในเครื่อง คุณอาจต้องใช้บริการอุโมงค์ (tunnel) เพื่อให้ URL สาธารณะชี้เข้าเครื่องคุณ จากนั้นทดสอบ

• ส่งแบบ async พร้อม reference แล้วดูว่า Webhook verification.completed กลับมาพร้อม reference เดิม
• จำลองการตอบ 500 จากเซิร์ฟเวอร์คุณเอง เพื่อดูว่าระบบส่งซ้ำและ handler ของคุณไม่ประมวลผลซ้ำ
• แก้ลายเซ็นจงใจให้ผิด เพื่อดูว่า handler ปฏิเสธ
• ลองดึงผลด้วย GET /api/v1/jobs/{jobId} เทียบกับผลที่ได้ทาง Webhook

เรื่องรายละเอียดการตรวจลายเซ็นอ่านต่อที่ การตรวจสอบ webhook

ขั้นที่ 5 ทดสอบภาระและขอบเขต

ก่อนเปิดจริง ลองส่งหลายใบติดกันเพื่อดูพฤติกรรมเมื่อชนเพดาน 60 ใบต่อนาที ตรวจว่าโค้ดคุณอ่าน Retry-After ได้ ตรวจว่าเมื่อเจอ 402 INSUFFICIENT_BALANCE ระบบแจ้งผู้ดูแลแทนที่จะทำให้ลูกค้างง และทดสอบการตอบ 202 ว่า UI ของคุณมีสถานะ "กำลังตรวจสอบ" ที่ไม่ค้างตลอดไป

เช็กลิสต์ก่อนไปขึ้นจริง

1. คีย์อยู่ใน secret manager ไม่อยู่ใน repository
2. ผ่านทุกเคสสลิปในตารางด้านบน
3. รองรับทั้ง 200 และ 202
4. Webhook ตรวจลายเซ็นและกันซ้ำได้
5. มี log ของ id และ jobId ทุกรายการ
6. มีการแจ้งเตือนเมื่อโควต้าใกล้หมด
7. มีแผนสำรองให้คนตรวจเมื่อ API ใช้งานไม่ได้

ครบแล้วจึงเปิดใช้งาน อ้างอิงรายละเอียดทุก endpoint ที่ คู่มือ API และถ้าต้องการลองเร็ว ๆ เริ่มได้ที่ สมัครสมาชิก