Hủy đơn hàng API khi khách hàng gửi liên kết không chính xác

Trước tiên hãy kiểm tra xem đơn hàng đã được chuyển cho nhà cung cấp chưa

Liên kết không chính xác không phải lúc nào cũng có nghĩa là quảng bá đã được khởi chạy. Trong cơ sở dữ liệu cá nhân, đơn hàng có thể đã được tạo nhưng chưa được gửi qua API. Trong trường hợp này, việc hủy chỉ phụ thuộc vào logic xử lý của bạn: chỉ cần đánh dấu đơn hàng là đã hủy, dừng thanh toán tự động và không khởi chạy việc truyền dữ liệu.

Kiểm tra mã đơn hàng, thời gian tạo, liên kết, loại dịch vụ và nhật ký yêu cầu API. Nếu yêu cầu đến nhà cung cấp chưa được gửi đi, đừng tạo đơn hàng mới chồng lên đơn hàng cũ. Trước tiên hãy ghi nhận việc hủy yêu cầu ban đầu, nếu không khách hàng có thể nhận được hai lần khởi chạy trên các liên kết khác nhau.

Xác định trạng thái đơn hàng tại nhà cung cấp

Nếu yêu cầu API đã được gửi, hãy yêu cầu trạng thái hiện tại từ nhà cung cấp. Tên các trạng thái khác nhau, nhưng thường có thể chia thành một số nhóm: chờ xử lý, đang xử lý, thực hiện một phần, hoàn thành và đã hủy. Để đưa ra quyết định, điều quan trọng không phải là trạng thái trong bảng điều khiển của bạn mà là phản hồi từ bên khởi chạy dịch vụ.

• Chờ xử lý: đơn hàng có thể vẫn cho phép hủy.
• Đang xử lý: đôi khi có thể dừng, nhưng một phần khối lượng có thể đã được khởi chạy.
• Thực hiện một phần: chỉ có thể hủy phần còn lại nếu nhà cung cấp hỗ trợ thao tác này.
• Hoàn thành: không thể sửa liên kết bằng cách hủy nữa.

Nhược điểm của việc chỉ kiểm tra theo trạng thái nội bộ là nó có thể được cập nhật với độ trễ. Hãy dựa vào phản hồi API gần nhất và thời gian nhận được nó.

Hủy đơn hàng trước khi dịch vụ được khởi chạy

Đối với đơn hàng đang trong hàng đợi, hãy sử dụng phương thức hủy nếu tài liệu của nhà cung cấp có quy định. Truyền mã định danh nhận được khi tạo đơn hàng, không phải số nội bộ của bạn nếu đây là các giá trị khác nhau. Lưu toàn bộ phản hồi: mã thao tác, trạng thái, nội dung lỗi và thời gian yêu cầu.

Đừng coi đơn hàng là đã hủy cho đến khi API xác nhận việc hủy. Phản hồi về việc chấp nhận yêu cầu và việc dừng dịch vụ thực tế có thể là các sự kiện khác nhau. Trong một số tích hợp, trước tiên sẽ có xác nhận chấp nhận, còn trạng thái cuối cùng sẽ thay đổi sau.

Nhược điểm của phương án này là nhà cung cấp có thể không kịp gỡ đơn hàng khỏi quá trình xử lý. Khi đó việc hủy sẽ trả về từ chối hoặc chỉ có hiệu lực đối với phần chưa thực hiện.

Không thay đổi liên kết trong đơn hàng đã tạo mà không có xác nhận

Với nhiều API, liên kết được cố định tại thời điểm tạo đơn hàng. Việc cố gắng truyền liên kết mới với cùng mã định danh có thể bị bỏ qua, được xử lý như lỗi hoặc tạo ra trạng thái không thể dự đoán. Đừng trông đợi rằng việc gửi lại yêu cầu sẽ tự động thay thế địa chỉ.

Nếu tài liệu hỗ trợ trực tiếp việc chỉnh sửa liên kết, trước tiên hãy đảm bảo rằng dịch vụ chưa bắt đầu thực hiện. Sau đó lưu giá trị cũ, giá trị mới và phản hồi API. Điều này sẽ hữu ích khi tranh chấp với khách hàng hoặc nhà cung cấp.

Nhược điểm của việc chỉnh sửa là ngay cả khi phương thức khả dụng, một phần hành động có thể đã được chuyển đến trang cũ trước khi cập nhật. Liên kết đã sửa không chuyển được kết quả đã nhận.

Phải làm gì khi thực hiện một phần

Khi quảng bá đã bắt đầu trên liên kết không chính xác, hãy yêu cầu hủy phần còn lại. Trong yêu cầu gửi nhà cung cấp, ghi rõ mã đơn hàng, liên kết không chính xác, liên kết chính xác, trạng thái hiện tại và thời gian phát hiện lỗi. Đừng thay đổi chi tiết yêu cầu nhiều lần: điều này làm phức tạp việc kiểm tra lịch sử.

Nếu việc hủy phần còn lại được xác nhận, hãy ghi nhận khối lượng đã được thực hiện. Việc hoàn tiền, nếu được quy định trong chính sách của nhà cung cấp, thường chỉ áp dụng cho phần chưa thực hiện. Khối lượng đã thực hiện không thể chuyển về mặt kỹ thuật từ kênh, video hoặc hồ sơ này sang kênh, video hoặc hồ sơ khác.

Nhược điểm của việc hủy một phần là rõ ràng: khách hàng có thể đã nhận được kết quả trên trang không chính xác, và ngân sách cho phần đơn hàng này không phải lúc nào cũng được hoàn lại.

Nếu đơn hàng đã hoàn thành, hãy lập yêu cầu sửa chữa riêng

Đơn hàng đã hoàn thành thường không thể hủy qua API. Trong tình huống này, đừng xóa bản ghi và đừng thay đổi liên kết trong lịch sử: dữ liệu ban đầu cần thiết để đối chiếu. Hãy kiểm tra xem dịch vụ có thực sự được cung cấp cho địa chỉ sai hay không, chứ không chỉ hiển thị với độ trễ.

Tiếp theo có hai hướng: thảo luận về bồi thường với nhà cung cấp theo chính sách của họ hoặc tạo đơn hàng mới trên liên kết chính xác sau khi thống nhất với khách hàng. Đơn hàng mới phải có mã định danh riêng, số tiền và ghi chú rõ ràng về lý do tạo.

Nhược điểm của việc khởi chạy mới là nó đòi hỏi ngân sách bổ sung, và việc bồi thường cho dịch vụ đã hoàn thành có thể không khả dụng.

Thông báo cho khách hàng về tình hình trước khi khởi chạy lại

Đừng tự ý khởi chạy thay thế nếu liên kết thuộc về khách hàng và lỗi đến từ phía họ. Hãy gửi cho họ liên kết ban đầu, trạng thái đơn hàng, khả năng hủy và hậu quả của từng phương án. Điều này đặc biệt quan trọng nếu một phần dịch vụ đã được thực hiện.

• Nếu đơn hàng chưa được chuyển, hãy yêu cầu liên kết chính xác và xác nhận việc hủy yêu cầu cũ.
• Nếu đơn hàng đang trong hàng đợi, hãy thông báo rằng yêu cầu hủy đã được gửi nhưng đang chờ phản hồi từ nhà cung cấp.
• Nếu có thực hiện một phần, hãy chỉ ra rằng chỉ có thể dừng phần còn lại.
• Nếu đơn hàng đã hoàn thành, hãy thống nhất việc khởi chạy mới hoặc cách giải quyết khác.

Nhược điểm của việc thống nhất kéo dài là trong thời gian đó, đơn hàng trong hàng đợi có thể chuyển sang trạng thái xử lý. Vì vậy, trước tiên hãy gửi yêu cầu kỹ thuật để hủy nếu có khả năng đó, sau đó mới làm rõ các bước tiếp theo.

Lưu nhật ký và bằng chứng về thao tác

Đối với mỗi đơn hàng tranh chấp, hãy lưu liên kết ban đầu từ khách hàng, ngày nhận, số nội bộ, mã định danh tại nhà cung cấp, các yêu cầu và phản hồi API. Nếu khách hàng gửi liên kết trong cuộc trò chuyện, đừng thay thế tin nhắn bằng phiên bản đã chỉnh sửa trong thẻ đơn hàng mà không lưu bản gốc.

Ghi nhận riêng ai và khi nào phát hiện lỗi. Điều này giúp phân biệt dữ liệu được truyền sai với lỗi của quản lý, biểu mẫu đơn hàng hoặc việc tự động điền. Khi liên hệ lại với nhà cung cấp, hãy sử dụng một chuỗi dữ liệu duy nhất để tránh mâu thuẫn.

Nhược điểm của việc ghi nhật ký thủ công là mất thời gian. Nhưng không có lịch sử thì khó xác nhận trạng thái hủy và giải thích cho khách hàng tại sao không thể hoàn tiền toàn bộ.

Kiểm tra việc xử lý lỗi trong tích hợp

Sau trường hợp như vậy, hãy kiểm tra cách hệ thống truyền liên kết vào API. Lỗi có thể xuất hiện không chỉ do khách hàng: đôi khi biểu mẫu cắt bớt tham số, thay thế giá trị cũ từ bộ nhớ đệm, chấp nhận liên kết đến hồ sơ thay vì liên kết đến bài đăng hoặc bỏ qua liên kết có ký tự thừa.

Thêm kiểm tra định dạng trước khi tạo đơn hàng: phù hợp với nền tảng, loại dịch vụ và đối tượng mong đợi. Đối với dịch vụ trên video, hệ thống phải phân biệt liên kết đến video với liên kết đến kênh, còn đối với mạng xã hội — hồ sơ với bài đăng riêng lẻ. Kiểm tra không đảm bảo liên kết chính xác nhưng loại bỏ được một số lỗi rõ ràng.

Tốt hơn là tách việc truyền đơn hàng khỏi việc tạo đơn hàng bằng một bước kiểm tra dữ liệu ngắn. Nhược điểm của bước bổ sung là đơn hàng sẽ không được đưa vào xử lý ngay lập tức, nhưng bạn sẽ có thời gian để nhận ra địa chỉ sai.

Thiết lập quy trình hủy rõ ràng cho đội ngũ

Mô tả một quy trình thống nhất: dừng gửi tự động, kiểm tra trạng thái tại nhà cung cấp, gửi yêu cầu hủy, lưu phản hồi, thông báo cho khách hàng và chỉ sau đó mới thống nhất việc khởi chạy lại. Quy trình như vậy không phải để hình thức mà để các nhân viên khác nhau không thực hiện các hành động loại trừ lẫn nhau.

Đừng cấp quyền hủy mà không giới hạn quyền và nhật ký hành động. Nếu nhiều quản lý cùng làm việc với một đơn hàng, một người có thể yêu cầu hủy, còn người khác — tạo đơn thay thế trước khi nhận được phản hồi. Điều này dẫn đến chi phí thừa và nhầm lẫn trong tính toán.

Nhược điểm của quy trình nghiêm ngặt là ít linh hoạt hơn trong các trường hợp khẩn cấp. Nhưng đối với đơn hàng API, điều quan trọng hơn không phải là tốc độ của một hành động riêng lẻ mà là kiểm soát liên kết nào thực sự được đưa vào xử lý.