Đối soát WooCommerce sau go-live: trạng thái, tồn kho và hoàn tiền

Ngày website bắt đầu nhận thanh toán thật cũng là lúc những tình huống ngoài demo xuất hiện: khách đóng trình duyệt, callback tới sau khi đơn bị hủy, email gửi lại hoặc tồn kho chưa khớp. Người vận hành cần biết đơn nào đang chờ bình thường và đơn nào thực sự cần kiểm tra, thay vì đổi trạng thái hàng loạt cho nhanh.

Tự động hóa đối soát cho website thương mại điện tử WordPress vì thế tiếp tục sau bước tích hợp checkout. Sau go-live, đội vận hành WooCommerce cần theo dõi trạng thái đơn, tồn kho, email, tác vụ nền và hoàn hàng trong cùng hồ sơ. Với luồng Pay2S được giới thiệu trên hoadontudong.com.vn, khoản thu phải dẫn tới đúng việc đã thực hiện cho khách, đồng thời cho biết bước nào còn chờ hoặc cần xử lý.

Đọc đúng trạng thái trước khi xử lý đơn

Trong WooCommerce, Processing thường cho biết đã nhận thanh toán và đơn đang chờ thực hiện; Completed thể hiện đã hoàn tất. Pending payment và On hold liên quan những giai đoạn chờ thanh toán hoặc xác nhận theo phương thức. Vì vậy, một đơn còn Processing không tự đồng nghĩa cổng thanh toán lỗi.

Giữ quy tắc cho loại hàng thực tế. Đơn hàng vật lý còn cần xử lý giao; sản phẩm số hoặc extension chuyên dụng có thể có hành vi khác. Không áp một thao tác đưa tất cả paid sang Completed khi chưa hiểu tác động của trạng thái đó.

Đội hỗ trợ cần nhìn cả phương thức, mã giao dịch và order notes. Một trạng thái tóm tắt không đủ để giải thích diễn biến. Nếu có custom status, ghi rõ nó có ý nghĩa thanh toán hay thực hiện hàng hóa để các bộ phận không dùng cùng một nhãn cho hai quyết định.

Tổ chức danh sách cần kiểm tra mỗi ngày

Danh sách vận hành nên ưu tiên các mâu thuẫn: có khoản thu nhưng đơn chưa xác nhận, đơn đã paid nhưng tác vụ phía sau lỗi, đơn hủy nhận tiền muộn và khoản hoàn chưa rõ kết quả. Tách chúng khỏi những đơn Pending payment chưa có chứng cứ khách trả.

Mỗi dòng cần số tiền, tuổi xử lý, mã nguồn, trạng thái hàng và người nhận việc. Nếu chỉ có một bộ lọc “đơn lỗi”, nhân viên sẽ mở nhiều đơn không cần thiết. Phân loại theo nguyên nhân giúp giao đúng việc cho bán hàng, kỹ thuật hoặc kế toán.

Giữ mốc cuối cùng đã kiểm tra và hành động tiếp theo. Khi đổi ca, người sau không nên yêu cầu khách gửi lại toàn bộ chứng cứ. Những khoản lớn hoặc đơn đã giao nhưng thanh toán chưa rõ cần mức ưu tiên phù hợp với chính sách cửa hàng.

Có tiền nhưng đơn chưa cập nhật: lần theo từng lớp

Đầu tiên, xác minh khoản nhận ở nguồn được phép truy cập và tìm đúng tham chiếu đơn. Sau đó kiểm tra thông báo đã gửi, endpoint đã nhận và dữ liệu đã được lưu chưa. Cuối cùng mới xem logic đổi trạng thái WooCommerce cùng tác vụ liên quan.

Với Pay2S, redirect trình duyệt chỉ phục vụ hiển thị; xác nhận bền vững dựa vào IPN hoặc kiểm tra server theo luồng. Khách không quay lại trang cảm ơn không chứng minh chưa trả. Bài phân biệt redirect và IPN giúp đội hỗ trợ chọn đúng nơi cần kiểm tra.

Nếu IPN đã nhận nhưng đơn không đổi, xem chữ ký, kết quả, số tiền và mapping merchant/order. Không sửa đơn sang paid chỉ vì request xuất hiện trong access log. Đội kỹ thuật có thể tham khảo hướng dẫn IPN Pay2S để đối chiếu điều kiện đã qua và điều kiện còn lỗi.

Tồn kho phải đi cùng luồng trạng thái của WooCommerce

Tích hợp cần sử dụng API đơn phù hợp, tránh sửa trực tiếp dữ liệu rồi bỏ qua các tác động nền tảng. Tài liệu gateway WooCommerce nêu payment_complete() cho luồng đã trả, giúp xử lý trạng thái và tác động liên quan. Không thêm một lần giảm tồn riêng khi nền tảng đã thực hiện.

Sau go-live, kiểm tra đơn paid có được giữ hoặc giảm tồn đúng một lần theo cấu hình. Nếu có plugin kho ngoài, xác định nơi chịu trách nhiệm và cơ chế đồng bộ. Hai hệ thống cùng tự giảm cho một sự kiện có thể làm tồn sai dù số tiền hoàn toàn đúng.

Khi đơn đã hủy hoặc hết thời gian giữ hàng rồi mới nhận tiền, kiểm tra khả năng thực hiện đơn trước khi khôi phục. Hàng có thể đã được bán cho người khác. Khoản tiền cần được lưu và giao xử lý; trạng thái cũ không nên tự bị đảo chỉ vì callback đến muộn.

Email là tác vụ có thể thất bại riêng

WooCommerce có email gắn với các chuyển trạng thái. Một khoản thanh toán có thể đã lưu đúng nhưng email không gửi được; ngược lại, email đã gửi không phải chứng cứ ngân hàng. Đội hỗ trợ cần nguồn trạng thái đơn để trả lời khách, không suy từ hộp thư.

Đối với email hoặc thông báo tùy chỉnh sau thanh toán, giữ định danh tác vụ để callback gửi lại không tạo thêm yêu cầu gửi. Nếu cần gửi lại cho khách, đó là thao tác có chủ đích với dấu vết riêng. Không dùng lại toàn bộ handler thanh toán chỉ để gửi email lần nữa.

Khi nhiều plugin cùng nghe sự kiện paid, rà những tác vụ phát sinh: email, giao vận, hóa đơn, điểm thưởng và quyền tải. Mỗi nơi cần xử lý an toàn khi nhận lại sự kiện. Một lớp chống trùng ở gateway không luôn bảo đảm mọi extension tùy chỉnh phía sau đều đã làm đúng.

Theo dõi hàng đợi thay vì chỉ xem callback

Callback có thể lưu thành công rồi đưa việc sang tác vụ nền. Nếu worker không chạy, đơn hoặc nghiệp vụ phía sau vẫn mắc kẹt. Quan sát tuổi tác vụ, số lỗi, lần thử và lý do; không chỉ nhìn số request IPN nhận được.

Action Scheduler cung cấp hàng đợi và log trạng thái tác vụ cho hệ sinh thái WordPress. Cách nó được kích hoạt và runner thực tế cần được kiểm tra trong hosting đang dùng. Có lịch chạy không chứng minh mọi tác vụ đã hoàn thành đúng giờ.

Khi chạy lại một tác vụ lỗi, xác định tác động nào đã xảy ra trước lỗi. Một job có thể đã tạo phiếu giao hàng rồi lỗi ở email. Replay từ đầu mà không có khóa nghiệp vụ sẽ tạo thêm tác động. Xem kiểm soát xử lý trùng để đặt yêu cầu cho từng bước.

Callback đến muộn cần một nhánh xử lý riêng

Đơn có thể bị khách hoặc nhân viên hủy trong lúc lệnh chuyển vẫn đang xử lý. Khi tiền đến sau, giữ giao dịch và trạng thái đơn hiện tại. Kiểm tra hàng, thỏa thuận khách và những tác vụ đã chạy trước khi quyết định tiếp tục bán hoặc xử lý khoản nhận.

Không tự tạo đơn mới hoặc chuyển tiền sang một đơn khác chỉ vì cùng khách và số tiền. Cần giữ liên hệ với sự việc gốc để tra cứu. Nếu khách đã thanh toán bằng phương thức thay thế, hai khoản thật phải được nhìn thấy để xử lý thu thừa.

Runbook nên quy định ai được quyết định, chứng cứ nào cần giữ và cách phản hồi khách. Endpoint kỹ thuật chỉ ghi nhận đúng sự kiện; quyết định thực hiện hàng hóa trong tình huống mâu thuẫn thuộc quy trình của cửa hàng.

Refunded chưa tự chứng minh tiền đã hoàn

Tài liệu WooCommerce phân biệt hoàn tự động qua gateway tương thích với hoàn thủ công. Hoàn thủ công ghi nhận ở cửa hàng nhưng merchant vẫn phải trả tiền bằng phương thức phù hợp. Chỉ đổi trạng thái sang Cancelled hoặc Refunded không tự hoàn cho khách.

Người vận hành cần kiểm tra khoản hoàn ở nguồn thanh toán, mã giao dịch và order notes phù hợp. Với hoàn một phần, giữ dòng hàng, số lượng và giá trị được xử lý. Không xem một email hoàn tiền là bằng chứng duy nhất rằng tiền đã chuyển thành công.

Quyền hoàn, duyệt và xác nhận kết quả cần rõ ràng. Nếu response hoàn bị timeout, kiểm tra trạng thái trước khi bấm thực hiện lần nữa. Hai thao tác đều có thể hợp lệ ở giao diện nhưng chỉ một khoản hoàn được phép theo quyết định đã duyệt.

Đối soát ngày cần nối tiền, đơn và việc đã thực hiện

So theo bản ghi, không chỉ tổng tiền. Một đơn gán nhầm có thể làm tổng vẫn khớp trong khi hai khách đều gặp vấn đề. Khoản thu chưa phân bổ và đơn chưa rõ kết quả cần danh sách riêng, không ẩn đi để dashboard chỉ còn trạng thái xanh.

Log phải nối được giao dịch nguồn, đơn và tác vụ. Tham khảo quan sát calls, log và lỗi Pay2S cho đầu nguồn. Phía WooCommerce cần giữ diễn biến order notes và log ứng dụng, đồng thời che khóa cùng dữ liệu cá nhân không phục vụ xử lý.

Kiểm tra lại luồng sau mỗi thay đổi có ảnh hưởng

Cập nhật gateway, checkout, plugin kho, email hoặc hóa đơn đều có thể thay đổi tác động sau thanh toán. Giữ một bộ thử đại diện để chạy trên staging: đúng đơn, callback lại, đến muộn, mạng lỗi, hoàn một phần và tác vụ nền bị dừng.

Đừng đổi mã đơn hoặc tái tạo thanh toán của đơn đang chờ chỉ để thử phiên bản mới. Khi triển khai, theo dõi các đơn đi qua thời điểm chuyển phiên bản và giữ khả năng nhận kết quả của cấu hình cũ theo kế hoạch. Tắt phương thức ở checkout không làm những khoản đang xử lý biến mất.

Người phụ trách nên ghi lại dấu hiệu bất thường trong vài ca đầu sau thay đổi. Nếu mọi bộ phận đều tìm được khoản tiền, trạng thái hàng và việc còn chờ từ cùng hồ sơ, hệ thống đã hỗ trợ được vận hành. Khi có lỗi, mục tiêu là phục hồi đúng bước chưa hoàn tất mà vẫn giữ nguyên những tác động đã thực hiện.