การยกเลิกคำสั่งซื้อผ่าน API เมื่อลูกค้าส่งลิงก์มาไม่ถูกต้อง

ขั้นแรก ตรวจสอบว่าคำสั่งซื้อถูกส่งไปยังผู้ให้บริการแล้วหรือไม่

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

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

ตรวจสอบสถานะคำสั่งซื้อกับผู้ให้บริการ

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

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

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

ยกเลิกคำสั่งซื้อก่อนเริ่มให้บริการ

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

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

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

อย่าเปลี่ยนลิงก์ในคำสั่งซื้อที่สร้างแล้วโดยไม่มีการยืนยัน

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

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

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

ทำอย่างไรเมื่อดำเนินการไปแล้วบางส่วน

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

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

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

หากคำสั่งซื้อเสร็จสิ้นแล้ว ให้ยื่นคำขอแก้ไขแยกต่างหาก

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

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

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

แจ้งลูกค้าเกี่ยวกับสถานการณ์ก่อนเริ่มต้นใหม่

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

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

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

บันทึกบันทึกและหลักฐานเกี่ยวกับการดำเนินการ

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

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

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

ตรวจสอบการจัดการข้อผิดพลาดในการเชื่อมต่อ

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

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

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

กำหนดขั้นตอนการยกเลิกที่ชัดเจนสำหรับทีม

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

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

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