การเชื่อมต่อ Slip Verification API ช่วยให้ธุรกิจตรวจสอบสลิปโอนเงินได้อัตโนมัติ แต่เมื่อระบบส่ง Request ไปยัง API แล้วได้รับ Error กลับมา หลายคนอาจไม่แน่ใจว่าปัญหาเกิดจาก API Key, IP, โควตาการใช้งาน, ข้อมูลสลิป หรือระบบปลายทางกันแน่
รหัส Error ของ Slip Verification API จึงเป็นข้อมูลสำคัญที่ช่วยให้นักพัฒนาและทีมงานระบุสาเหตุของปัญหาได้เร็วขึ้น โดย Thunder Solution API v2 มีรูปแบบ Error Response ที่เป็นมาตรฐาน พร้อมรหัสที่บอกประเภทของปัญหา เช่น MISSING_API_KEY, INVALID_API_KEY, IP_NOT_ALLOWED, QUOTA_EXCEEDED, VALIDATION_ERROR, SLIP_NOT_FOUND และ API_SERVER_ERROR
บทความนี้จะรวบรวม Error Code ของ Slip Verification API ที่ควรรู้ พร้อมอธิบายว่าแต่ละรหัสหมายถึงอะไร เกิดจากอะไร และควรแก้ไขอย่างไร เพื่อช่วยให้ Developer สามารถ Debug ระบบตรวจสอบสลิปได้เป็นขั้นตอนมากขึ้น
รหัส Error ของ Slip Verification API คืออะไร?
Error Code คือรหัสที่ API ส่งกลับมาเมื่อไม่สามารถประมวลผล Request ได้ตามปกติ โดยช่วยบอกว่าเกิดปัญหาที่ส่วนไหนของกระบวนการ สำหรับ Thunder Solution API v2 รูปแบบ Error Response จะอยู่ในลักษณะนี้:
{
"success": false,
"error": {
"code": "ERROR_CODE",
"message": "Human-readable error message"
}
}
ดังนั้นเวลาระบบเกิด Error ไม่ควรดูเฉพาะ HTTP Status Code เช่น 400 หรือ 403 แต่ควรตรวจสอบค่า error.code และ error.message ด้วย เพราะจะช่วยระบุสาเหตุได้ละเอียดกว่า
รวม Error Code ของ Slip Verification API v2
ตารางต่อไปนี้สรุปรหัส Error หลักจากเอกสาร Thunder Solution API v2
| Error Code | HTTP Status | ความหมาย |
| MISSING_API_KEY | 401 | ไม่มี API Key ใน Request |
| INVALID_API_KEY | 401 | API Key ไม่ถูกต้อง |
| BRANCH_INACTIVE | 403 | API Branch ถูกปิดใช้งาน |
| SERVICE_BANNED | 403 | Service ถูกระงับ |
| USER_BANNED | 403 | User ถูกระงับ |
| IP_NOT_ALLOWED | 403 | IP ที่เรียก API ไม่อยู่ใน Whitelist |
| QUOTA_EXCEEDED | 403 | ใช้งานเกินโควตาที่กำหนด |
| VALIDATION_ERROR | 400 | ข้อมูล Request ไม่ถูกต้องหรือไม่ครบ |
| SLIP_NOT_FOUND | 404 | ไม่พบสลิปหรือข้อมูลสลิปไม่ถูกต้อง |
| API_SERVER_ERROR | 500 | เกิดปัญหาจากระบบ API ภายนอก |
ซึ่งรหัสเหล่านี้เป็น Error Code ที่ระบุไว้ในเอกสาร API v2 ของ Thunder Solution โดยตรง
1. MISSING_API_KEY แปลว่าอะไร?
ความหมาย
MISSING_API_KEY หมายถึง Request ไม่มี API Key ใน Authorization Header ทำให้ระบบไม่สามารถยืนยันตัวตนของผู้เรียก API ได้ ซึ่งทาง Thunder Solution API ใช้ Bearer Token Authentication โดยต้องส่ง API Key ในรูปแบบ Authorization Header
วิธีแก้
ตรวจสอบว่า Request มี Header เช่น Authorization: Bearer YOUR_API_KEY และตรวจสอบว่า Application ของคุณดึง API Key มาใช้งานจริงหรือไม่
เช็กเพิ่มเติม:
- มี Authorization Header หรือไม่
- ใช้คำว่า Bearer ถูกต้องหรือไม่
- Environment Variable มีค่าหรือไม่
- API Key ถูกตัดหรือมีช่องว่างผิดตำแหน่งหรือไม่
2. INVALID_API_KEY แปลว่าอะไร?
ความหมาย
INVALID_API_KEY หมายถึง API Key ที่ส่งไปไม่ถูกต้อง หรือไม่ตรงกับ Key ที่ระบบกำหนดไว้
วิธีแก้
ให้ตรวจสอบ API Key ในระบบ Developer และเปรียบเทียบกับค่าที่ Application ใช้งานอยู่ หากเพิ่งเปลี่ยน API Key ควรตรวจสอบด้วยว่า Server, .env, Docker หรือระบบ Production ใช้ Key ตัวใหม่แล้วหรือยัง
ข้อควรระวัง: ไม่ควรใส่ API Key แบบ Hard Code ใน Source Code ที่เผยแพร่สู่สาธารณะ
3. IP_NOT_ALLOWED แปลว่าอะไร?
ความหมาย
IP_NOT_ALLOWED หมายถึง IP Address ของเครื่องหรือ Server ที่ส่ง Request ไม่อยู่ในรายการ IP ที่อนุญาตให้เรียก API นอกจากนี้ Thunder Solution ยังรองรับการกำหนด IP Whitelist เพื่อเพิ่มความปลอดภัยให้กับ API
วิธีแก้
ตรวจสอบ Public IP ของ Server ที่ใช้เรียก API แล้วนำไปตรวจสอบกับรายการ Whitelist ในระบบ แต่กรณีที่ย้าย Server, เปลี่ยน Hosting หรือระบบ Cloud เปลี่ยน Outbound IP อาจทำให้ Error นี้เกิดขึ้นได้
เช็กก่อนแก้:
- Server ใช้ Public IP อะไร
- IP ดังกล่าวอยู่ใน Whitelist หรือไม่
- มี Proxy หรือ NAT ที่ทำให้ IP เปลี่ยนหรือไม่
- Environment Development และ Production ใช้ IP คนละตัวหรือไม่
4. QUOTA_EXCEEDED แปลว่าอะไร?
ความหมาย
QUOTA_EXCEEDED หมายถึงจำนวนการเรียกใช้ API เกินโควตาที่กำหนดไว้ในแพ็กเกจหรือ Branch เอกสาร Thunder Solution ระบุว่า Request ที่ส่งเข้าระบบจะถูกนับรวมในโควต้ารายเดือน และสามารถตรวจสอบข้อมูลการใช้งานผ่าน Endpoint สำหรับข้อมูล Application ได้
วิธีแก้
ควรตรวจสอบ Usage ปัจจุบันก่อน จากนั้นพิจารณา
- ลด Request ที่ไม่จำเป็น
- ป้องกันการยิง API ซ้ำจากระบบ
- ใช้ Cache ในกรณีที่เหมาะสม
- ตรวจสอบ Retry Logic
- เพิ่มโควต้าหรือเปลี่ยนแพ็กเกจหากปริมาณการใช้งานเพิ่มขึ้น
โดยเฉพาะระบบ E-commerce ที่มีคำสั่งซื้อจำนวนมาก ควรออกแบบ Workflow ให้เรียกตรวจสอบสลิปเท่าที่จำเป็น
5. VALIDATION_ERROR แปลว่าอะไร?
ความหมาย
VALIDATION_ERROR หมายถึงข้อมูลที่ส่งไปยัง API ไม่ครบหรือไม่ตรงตามรูปแบบที่ระบบกำหนด
ตัวอย่างเช่น API v2 /verify/bank ต้องได้รับข้อมูลสำหรับตรวจสอบอย่างน้อยหนึ่งรูปแบบ เช่น payload, image, url หรือ base64 หากไม่มีข้อมูลเหล่านี้ ระบบจะตอบกลับ Validation Error
วิธีแก้
ตรวจสอบ Request Body และ Parameter ว่าส่งข้อมูลถูกต้องหรือไม่
ตัวอย่างที่ควรตรวจสอบ:
- มี payload หรือไม่
- รูปภาพถูกส่งมาถูก Field หรือไม่
- Base64 มี Prefix และ Format ถูกต้องหรือไม่
- URL เป็น HTTP/HTTPS หรือไม่
- Content-Type ถูกต้องหรือไม่
สำหรับการส่งรูปภาพ Thunder Solution ระบุว่ารองรับ JPEG, PNG, GIF และ WebP และไฟล์มีขนาดสูงสุด 4 MB
6. SLIP_NOT_FOUND แปลว่าอะไร?
ความหมาย
SLIP_NOT_FOUND หมายถึงระบบไม่พบข้อมูลสลิปที่ส่งเข้ามา หรือข้อมูลสลิปไม่สามารถตรวจสอบได้ ต้องบอกเลยว่า Error นี้อาจเกิดขึ้นเมื่อ Payload หรือข้อมูลจากสลิปไม่ถูกต้อง หรือระบบไม่สามารถค้นหารายการที่ตรงกันได้
วิธีแก้
ให้ตรวจสอบตามรายละเอียด ดังนี้ั
- QR Code บนสลิปอ่านได้หรือไม่
- Payload ถูกต้องหรือไม่
- รูปภาพเป็นสลิปจริงหรือไม่
- รูปภาพมีความคมชัดเพียงพอหรือไม่
- QR Code ถูกตัดออกจากภาพหรือไม่
- URL รูปภาพสามารถเข้าถึงจาก Server ได้หรือไม่
หากใช้ Image, Base64 หรือ URL เอกสาร Thunder Solution ระบุว่า QR Code ควรมองเห็นได้อย่างชัดเจน
7. API_SERVER_ERROR แปลว่าอะไร?
ความหมาย
API_SERVER_ERROR เป็น Error ระดับ Server หมายถึงเกิดปัญหาภายในระบบ API หรือระบบภายนอกที่เกี่ยวข้องกับการตรวจสอบ HTTP Status สำหรับ Error นี้คือ 500
วิธีแก้
กรณีนี้ไม่ควรแก้ด้วยการเปลี่ยนข้อมูล Request ทันที เพราะ Request อาจถูกต้องอยู่แล้ว
สิ่งที่ควรทำคือ
- ตรวจสอบว่า Error เกิดขึ้นชั่วคราวหรือไม่
- ตรวจสอบระบบ Monitoring ของ Application
- ใช้ Retry Logic อย่างเหมาะสม
- บันทึก Request ID หรือข้อมูล Error ที่เกี่ยวข้อง
- ติดต่อทีม Support หากปัญหาเกิดซ้ำ
ไม่ควรยิง Request ซ้ำแบบถี่ ๆ เพราะอาจทำให้เกิดปัญหา Rate Limit หรือใช้โควตาโดยไม่จำเป็น
Error Code กับ HTTP Status ต่างกันอย่างไร?
สองอย่างนี้มีหน้าที่ต่างกัน HTTP Status Code บอกภาพรวมของผลลัพธ์จาก HTTP Request เช่น
- 200 = สำเร็จ
- 400 = Request ไม่ถูกต้อง
- 401 = ไม่ได้รับอนุญาต
- 403 = ไม่มีสิทธิ์เข้าถึง
- 404 = ไม่พบข้อมูล
- 429 = เรียก API มากเกินไป
- 500 = Server Error
ส่วน Error Code จะลงรายละเอียดมากขึ้น เช่น 401 อาจเกิดจาก MISSING_API_KEY หรือ INVALID_API_KEY ดังนั้น Developer ควรตรวจทั้ง HTTP Status และ Error Code เพื่อวิเคราะห์ปัญหาให้แม่นยำ
วิธี Debug เมื่อ Slip Verification API Error
เมื่อ API ตอบ Error กลับมา แนะนำให้ตรวจสอบตามลำดับนี้
- ขั้นตอนที่ 1 ตรวจ HTTP Status ดูว่า Error อยู่ในกลุ่ม 400, 401, 403, 404 หรือ 500
- ขั้นตอนที่ 2 ตรวจ Error Code อ่านค่า error.code เพื่อระบุสาเหตุที่แท้จริง
- ขั้นตอนที่ 3 ตรวจ Message อ่านข้อความใน error.message เพื่อดูรายละเอียดเพิ่มเติม
- ขั้นตอนที่ 4 ตรวจ Request ตรวจ API Endpoint, Header, Body, Payload และรูปภาพ
- ขั้นตอนที่ 5 ตรวจระบบของตัวเอง ดู Log, Environment Variable, IP Address, Retry Logic และระบบ Queue
- ขั้นตอนที่ 6 ตรวจ Usage หากพบ QUOTA_EXCEEDED ให้ตรวจสอบจำนวน Request และโควต้าคงเหลือ
แนวทางนี้ช่วยให้ทีม Developer แยกได้ว่า ปัญหาเกิดจาก Client, Authentication, Configuration, ข้อมูลสลิป หรือ Server แทนการแก้โค้ดแบบลองผิดลองถูก
API v1 กับ v2 มี Error Code ต่างกันอย่างไร?
Thunder Solution มี API v1 และ v2 โดยปัจจุบันเอกสารแนะนำ API v2 สำหรับโปรเจกต์ใหม่ ส่วน v1 เป็น Legacy API
API v1 ใช้รูปแบบ Response เช่น
{
"status": 400,
"message": "error_code"
}
และมี Error Code เช่น unauthorized, access_denied, application_expired, application_deactivated, quota_exceeded, invalid_payload, duplicate_slip, slip_not_found และ server_error
ดังนั้นก่อนนำ Error Code จากบทความหรือ Documentation ไปแก้ระบบ ควรเช็กก่อนว่า Integration ของคุณใช้ API v1 หรือ API v2
ป้องกัน Error จาก Slip Verification API ตั้งแต่ต้นได้อย่างไร?
การแก้ Error เป็นเรื่องสำคัญ แต่การออกแบบระบบให้ลดโอกาสเกิด Error ตั้งแต่ต้นจะช่วยให้ระบบมีเสถียรภาพมากกว่า
- Validate ข้อมูลก่อนส่ง API: ตรวจสอบ Payload, รูปภาพ และข้อมูลคำสั่งซื้อก่อนยิง Request
- จัดการ API Key อย่างปลอดภัย: เก็บ API Key ใน Environment Variable หรือ Secret Management แทนการเขียนไว้ใน Source Code
- ทำระบบ Retry อย่างเหมาะสม: ควร Retry เฉพาะ Error ที่มีโอกาสเกิดจากปัญหาชั่วคราว และกำหนดจำนวนครั้งหรือระยะห่างระหว่าง Retry
- ทำ Logging: ควรบันทึก HTTP Status, Error Code, Timestamp และข้อมูลที่จำเป็นสำหรับ Debug โดยหลีกเลี่ยงการเก็บข้อมูลสำคัญเกินความจำเป็น
- รองรับ Duplicate Detection: หากธุรกิจต้องการป้องกันการนำสลิปเดิมกลับมาตรวจสอบซ้ำ API ของ Thunder Solution รองรับการตรวจจับสลิปซ้ำ และ API v2 สามารถใช้ checkDuplicate ในการตรวจสอบได้
สรุป รหัส Error ของ Slip Verification API แปลว่าอะไร?
รหัส Error ของ Slip Verification API คือข้อมูลสำคัญสำหรับวิเคราะห์ว่าการตรวจสอบสลิปไม่สำเร็จเพราะอะไร โดย API v2 ของ Thunder Solution มี Error Code หลัก เช่น MISSING_API_KEY, INVALID_API_KEY, IP_NOT_ALLOWED, QUOTA_EXCEEDED, VALIDATION_ERROR, SLIP_NOT_FOUND และ API_SERVER_ERROR
หลักสำคัญคืออย่าดูแค่ข้อความว่า “API Error” แต่ควรตรวจสอบ HTTP Status + Error Code + Error Message + Request ที่ส่งไป พร้อมดู Log ของระบบประกอบ หากเป็นโปรเจกต์ใหม่ ควรพิจารณาใช้ API v2 เนื่องจากเป็นเวอร์ชันปัจจุบันของ Thunder Solution และมีรูปแบบ Response กับ Error Handling ที่เป็นมาตรฐานมากขึ้น
สำหรับธุรกิจที่ต้องการนำ ระบบตรวจสอบสลิปโอนเงินอัตโนมัติ ไปเชื่อมกับเว็บไซต์ แอป หรือระบบหลังบ้าน Thunder Solution รองรับการตรวจสอบผ่าน Payload, รูปภาพ, Base64 และ URL พร้อมรองรับ Account Matching และ Amount Validation ใน API v2
คำถามที่พบบ่อย (FAQ)
1. รหัส Error ของ Slip Verification API ดูได้จากตรงไหน?
สำหรับ API v2 ให้ตรวจสอบ Response เมื่อ Request ไม่สำเร็จ โดยดูที่ error.code และ error.message ส่วน API v1 จะใช้ message เป็น Error Code ตามรูปแบบ Response ของ v1
2. Error 401 จาก Slip Verification API เกิดจากอะไร?
โดยทั่วไปควรตรวจสอบ Authentication ก่อน สำหรับ API v2 อาจเกี่ยวข้องกับ MISSING_API_KEY หรือ INVALID_API_KEY ซึ่งหมายถึงไม่มี API Key หรือ API Key ไม่ถูกต้อง
3. ทำไมถึงขึ้น QUOTA_EXCEEDED?
หมายถึงจำนวนการใช้งาน API เกินโควต้าที่กำหนด ควรตรวจสอบ Usage และจำนวน Request รวมถึงตรวจสอบว่าระบบมีการยิง API ซ้ำโดยไม่จำเป็นหรือไม่
4. SLIP_NOT_FOUND แก้ยังไง?
ตรวจสอบ Payload, QR Code และข้อมูลสลิปก่อน โดยเฉพาะกรณีส่งรูปภาพ ควรตรวจสอบว่าภาพชัดและ QR Code มองเห็นได้ รวมถึงตรวจสอบรูปแบบไฟล์และขนาดไฟล์ตามข้อกำหนดของ API
5. API v1 และ API v2 ใช้ Error Code เดียวกันหรือไม่?
ไม่เหมือนกันทั้งหมด โดย v1 และ v2 มีรูปแบบ Response และชุด Error Code ที่แตกต่างกัน และเอกสารปัจจุบันแนะนำให้ใช้ v2 สำหรับโปรเจกต์ใหม่
API เช็กสลิปมี Error บ่อย? ให้ Thunder Solution ช่วยจัดการ
การพัฒนา Slip Verification API เองอาจต้องดูแลทั้ง Authentication, API Integration, Error Handling, Duplicate Detection และการตรวจสอบข้อมูลธุรกรรม ซึ่งหากระบบมีปริมาณการใช้งานเพิ่มขึ้น การออกแบบ Workflow ที่เหมาะสมยิ่งมีความสำคัญ
Thunder Solution ให้บริการ Slip Verification API สำหรับธุรกิจที่ต้องการตรวจสอบสลิปโอนเงินแบบอัตโนมัติ สามารถเชื่อมต่อกับเว็บไซต์ แอปพลิเคชัน และระบบหลังบ้าน พร้อมรองรับการตรวจสอบผ่าน Payload, รูปภาพ, Base64 หรือ URL โดย API v2 ยังรองรับ Account Matching และ Amount Validation
สำหรับตรวจสอบบัญชีผู้รับและยอดเงินตามที่ระบบต้องการ หากธุรกิจต้องการลดงานตรวจสอบสลิปแบบ Manual และสร้างระบบยืนยันการชำระเงินที่ทำงานอัตโนมัติ เริ่มต้นเชื่อมต่อ Slip Verification API กับ Thunder Solution ได้เลย ดูรายละเอียด Slip Verification API จาก Thunder Solution
