วิธีตั้งค่าเติมเงินอัตโนมัติใน SMM Panel ผ่าน API

สิ่งที่ต้องเตรียมก่อนตั้งค่าเติมเงินอัตโนมัติ

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

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

แยกการตรวจสอบยอดคงเหลือออกจากการตัดสินใจชำระเงิน

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

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

เลือกเกณฑ์และตรรกะของจำนวนเงินที่เติม

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

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

ตั้งข้อจำกัดทางการเงินแยกจากเกณฑ์

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

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

สร้างคีย์แยกและป้องกันการเข้าถึง

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

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

สร้างรายการชำระเงินพร้อมรหัสเฉพาะ

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

ด้านล่างคือตัวอย่างคำขอทั่วไป ให้เปลี่ยนชื่อฟิลด์และที่อยู่เป็นค่าจากเอกสารของผู้ให้บริการรายนั้น ๆ ตัวแปร PAYMENT_ID เก็บ ID เฉพาะที่สร้างไว้ล่วงหน้า และ CALLBACK_URL ชี้ไปยังตัวจัดการเว็บฮุก

curl -X POST "$PAYMENT_API_URL/payments" \
-H "Authorization: Bearer $PAYMENT_API_KEY" \
-H "Idempotency-Key: $PAYMENT_ID" \
-H "Content-Type: application/json" \
-d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID","callback_url":"$CALLBACK_URL"}'

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

ตรวจสอบยอดคงเหลือและบันทึกสถานะธุรกรรม

ควรเรียกดูยอดคงเหลือก่อนตัดสินใจเติมเงินครั้งใหม่และหลังการเติมเงินสำเร็จ คำขอทั่วไปอาจมีลักษณะดังนี้: curl -X GET "$PANEL_API_URL/balance" -H "Authorization: Bearer $PANEL_API_KEY" ในการตอบกลับ ให้บันทึกไม่เพียงจำนวนเงิน แต่รวมถึงเวลาที่ตรวจสอบ เพื่อไม่ให้ตัดสินใจจากข้อมูลที่ล้าสมัย

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

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

รับเว็บฮุกและกระทบยอดสถานะการชำระเงิน

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

หลังตรวจสอบเว็บฮุก ควรขอสถานะการชำระเงินล่าสุดจากผู้ให้บริการ ตัวอย่างเช่น: curl -X GET "$PAYMENT_API_URL/payments/$PROVIDER_PAYMENT_ID" -H "Authorization: Bearer $PAYMENT_API_KEY" กระทบยอดสถานะกับข้อมูลในบันทึก แล้วส่งคำขอเติมเงินไปยัง SMM Panel ด้วย ID ภายในเดียวกัน

เว็บฮุกที่ส่งซ้ำต้องไม่สร้างการเติมเงินครั้งที่สอง ตัวจัดการจะค้นหาธุรกรรมจาก ID ภายนอก เห็นสถานะ "เติมเงินแล้ว" และส่งการตอบกลับสำเร็จโดยไม่ดำเนินการใหม่ ข้อเสียของเว็บฮุกคืออาจล่าช้าหรือไม่มาถึงหากตัวจัดการไม่พร้อมใช้งาน

จัดการกับ timeout การลองใหม่ และการชำระเงินที่ค้างอยู่

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

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

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

เติมเงินที่ยืนยันแล้วเข้าสู่ SMM Panel

ก่อนเติมเงิน ตัวจัดการจะตรวจสอบอีกครั้งว่า จำนวนเงินไม่เกินขีดจำกัด สกุลเงินตรงกัน ธุรกรรมไม่ถูกยกเลิก และสถานะยังไม่ใช่ "เติมเงินแล้ว" คำขอจะส่งจำนวนเงินและรหัสการชำระเงินภายนอก หาก API ของ panel รองรับคีย์ idempotency ให้ใช้ ID ธุรกรรมภายในเดียวกัน

รูปแบบคำขอทั่วไป: curl -X POST "$PANEL_API_URL/balance/topups" -H "Authorization: Bearer $PANEL_API_KEY" -H "Content-Type: application/json" -H "Idempotency-Key: $PAYMENT_ID" -d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID"}'

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

เพิ่มการแจ้งเตือน สวิตช์ปิด และการตรวจสอบการเริ่มทำงาน

การแจ้งเตือนจำเป็นสำหรับความผิดปกติ: ยอดคงเหลือต่ำกว่าระดับวิกฤต การชำระเงินถูกปฏิเสธ ไม่ได้รับเว็บฮุก เกินขีดจำกัด API ไม่พร้อมใช้งาน หรือธุรกรรมต้องตรวจสอบด้วยมือ ในข้อความเพียงระบุ ID ภายใน สถานะ และสาเหตุ อย่าใส่ API key ลายเซ็นเว็บฮุก และข้อมูลการชำระเงินลงไป

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

เช็กลิสต์ก่อนเปิดใช้งานการเติมเงินอัตโนมัติ

• การตรวจสอบยอดคงเหลือไม่สร้างรายการชำระเงินขณะที่มีธุรกรรมที่ยังไม่เสร็จสิ้น
• แต่ละรายการชำระเงินมี ID ภายในและคีย์ idempotency ที่ไม่ซ้ำกัน
• ตั้งขีดจำกัดต่อหนึ่งธุรกรรมและต่อช่วงเวลาที่เลือกไว้แล้ว
• เว็บฮุกถูกตรวจสอบด้วยลายเซ็น จำนวนเงิน สกุลเงิน และรหัส
• เมื่อไม่ได้รับเว็บฮุก จะเริ่มการกระทบยอดสถานะซ้ำผ่าน API
• timeout ไม่ทำให้เกิดการชำระเงินครั้งที่สองก่อนตรวจสอบครั้งแรก
• การเติมเงินใน panel ทำเพียงครั้งเดียวและบันทึกไว้ในบันทึก
• โหมดทดสอบได้รับการตรวจสอบทั้งกรณีสำเร็จ ปฏิเสธ เว็บฮุกซ้ำ และ API ไม่พร้อมใช้งาน