Khách chọn một phòng, đi tới thanh toán rồi rời trang. Lễ tân nhìn thấy yêu cầu chưa trả tiền nhưng không biết phòng đang bị giữ tới khi nào. Một lúc sau, hệ thống nhận thông tin thanh toán trong khi phòng có thể đã được bán cho khách khác. Đặt thời hạn giữ phòng chỉ giải quyết một nửa bài toán; nửa còn lại là xử lý tiền đến muộn mà không tạo thêm cam kết chỗ.
Bài viết dùng một tình huống giả định để thiết kế giữ phòng chưa thanh toán trên website. WooCommerce Bookings và trạng thái đơn được dùng làm nền tham chiếu, không coi chúng là một hệ quản trị khách sạn hoàn chỉnh. Thời hạn, cách xác minh và người quyết định ngoại lệ là chính sách đề xuất cần doanh nghiệp chốt trước khi triển khai.
Giữ phòng chưa thanh toán và nhận tiền là hai tiến trình
Giả sử yêu cầu R4 chọn phòng P2 cho hai đêm. Khách sạn cho giữ tạm trong một khoảng thời gian do mình quy định và ghi rõ trên giao diện. Đồng hồ giữ chỗ theo dõi khả năng dành phòng cho R4. Tiến trình thanh toán theo dõi khoản tiền và bằng chứng xử lý từ phương thức đã cấu hình. Hai tiến trình liên quan nhưng không phải cùng một trạng thái.
Tài liệu quan hệ booking và order mô tả các trạng thái đặt chỗ và mối liên kết với đơn. Một booking unpaid không có nghĩa khách sạn đã nhận tiền. Đồng thời, các trạng thái booking có thể tham gia giữ lịch theo cách riêng, nên cần xem đúng hành vi của phiên bản đang dùng thay vì suy từ tên trạng thái.
Giao diện khách nên nói họ đang giữ tạm hay đã được xác nhận lưu trú. Thông báo tiếp nhận yêu cầu không nên hứa chắc phòng nếu còn điều kiện thanh toán hoặc duyệt. Một email có chữ xác nhận nhưng hệ thống vẫn đang chờ khiến lễ tân phải giải thích điều mà thiết kế ban đầu đã làm mơ hồ.
Với R4, cần lưu rõ thời điểm hết hạn, phạm vi phòng hoặc loại phòng đang giữ và điều kiện chuyển sang xác nhận. Nếu chỉ lưu “chưa thanh toán” mà không có mốc, nhân viên không thể phân biệt yêu cầu mới với yêu cầu đã bị bỏ nhiều giờ. Nếu mốc chỉ ở trình duyệt khách, đóng trang có thể khiến hệ thống mất cơ sở xử lý.
Đi qua ba thời điểm của một yêu cầu giả định
Ở thời điểm đầu, R4 chưa hết hạn và chưa có tiền. Website có thể tiếp tục cho khách hoàn thành đúng yêu cầu, tùy phương thức thanh toán. Nếu khách mở lại, nên tìm lại R4 thay vì tạo một yêu cầu mới rồi giữ thêm phòng. Cần kiểm thử điều này trên luồng checkout thực tế, không chỉ dựa vào nội dung trang thanh toán.
Ở thời điểm thứ hai, thời hạn giữ kết thúc mà chưa có bằng chứng thanh toán. Một tác vụ đề xuất sẽ đối chiếu trạng thái hiện tại rồi giải phóng đúng phần giữ của R4. Không đặt lại toàn bộ phòng thành trống bằng một lệnh chung, vì phòng còn có thể bị ràng buộc bởi yêu cầu khác hoặc khoảng bảo trì.
Ở thời điểm thứ ba, thông tin tiền đến sau khi R4 đã hết giữ. Nếu phòng vẫn còn, doanh nghiệp có thể cân nhắc xác nhận lại theo chính sách. Nếu phòng không còn, phải có người xử lý ngoại lệ. Không chuyển thẳng sang trạng thái đã có phòng chỉ vì một thông báo thanh toán hợp lệ vừa xuất hiện.
Khoản tiền cần được đối chiếu với đúng yêu cầu và đúng trạng thái xử lý. Một trang khách quay về báo thành công không thay thế việc xác minh theo cơ chế thanh toán hợp lệ. Bài viết không hướng dẫn thao tác tiền thật; đội triển khai cần dùng môi trường thử và tài liệu của phương thức cụ thể cho phần đó.
Tham chiếu trạng thái đơn WooCommerce giúp phân biệt pending payment, on hold và các trạng thái đã xử lý trong ngữ cảnh nền tảng. Tên trạng thái không phải chính sách giữ phòng chung. Đừng mặc định một thiết lập giữ hàng của cửa hàng sẽ giải quyết đầy đủ việc giữ tài nguyên lưu trú.
Hai tác vụ đến gần nhau cần quyết định nhất quán
Trường hợp khó nhất là tác vụ hết hạn và thông tin thanh toán được xử lý gần cùng lúc. Nếu cả hai cùng đọc trạng thái cũ rồi tự cập nhật, có thể một bên xác nhận trong khi bên kia đã giải phóng. Thiết kế tích hợp cần một bước đối chiếu có kiểm soát để mỗi lần chỉ có một quyết định được công nhận cho yêu cầu đó.
Đây là yêu cầu về tính nhất quán của ứng dụng, không phải lời khẳng định WooCommerce tự cung cấp mọi khóa giao dịch cho tùy chỉnh của bạn. Người triển khai phải chỉ rõ nơi kiểm tra trạng thái, cách phát hiện thay đổi đồng thời và đường xử lý khi không chắc kết quả. Thêm một khoảng chờ tùy ý không chứng minh đã giải quyết cuộc đua này.
Chính sách ngoại lệ cần có trước khi khách gặp lỗi
Khách sạn cần quyết định ai được xác nhận lại, ai được đề xuất phòng khác và ai có quyền xử lý hoàn tiền qua phương thức phù hợp. Hệ thống nên đưa đủ bằng chứng tối thiểu để người đó ra quyết định, không tự hứa một kết quả thay họ. Mọi lựa chọn ảnh hưởng khách cần được thông báo theo chính sách đã công bố.
Không cần nhân viên kiểm tra mọi yêu cầu chưa trả tiền bằng tay. Luồng thường có thể tự giải quyết trong giới hạn đã chứng minh đúng; chỉ nhánh muộn hoặc không rõ mới cần người xử lý. Cách chia này giúp tự động hóa phần lặp lại mà vẫn giữ trách nhiệm rõ ở những trường hợp có nguy cơ vượt năng lực phòng.
Thông báo cho khách cần phản ánh tiến trình thật. Có thể nói đã nhận thông tin và đang đối chiếu chỗ nếu đó là trạng thái hiện tại. Không dùng câu phòng đã được bảo đảm trong khi người phụ trách chưa xác nhận. Ngược lại, đừng báo không nhận được tiền nếu hệ thống đã có bằng chứng nhận nhưng đang xử lý phân bổ phòng.
Nhật ký nên ghi mã yêu cầu, thời điểm giữ hết, thời điểm xử lý bằng chứng tiền và quyết định cuối. Không đưa thông tin thẻ, token hay dữ liệu cá nhân không cần thiết vào log hỗ trợ. Phần kiểm tra giao dịch phải theo quyền của phương thức thanh toán, không yêu cầu khách gửi thông tin nhạy cảm vào chat.
Hướng dẫn quản lý booking là nguồn đối chiếu cho thao tác xem và quản lý trạng thái. Trước khi viết tác vụ tự động, cần thử việc trạng thái nào chiếm lịch trên cấu hình thực tế. Đừng dùng ví dụ dọn in-cart để khẳng định mọi booking unpaid cũng tự hết hạn theo cùng một mốc.
Đo nghiệm thu bằng sự nhất quán, không chỉ tốc độ
Bộ thử cần có yêu cầu trả tiền trong hạn, hết hạn chưa trả, tiền đến muộn khi còn phòng và tiền đến muộn khi phòng đã có cam kết khác. Dùng tài nguyên thử và phương thức sandbox được cho phép. Với mỗi tình huống, ghi kỳ vọng riêng cho đặt chỗ, đơn và thông báo khách.
Thử dừng tác vụ hết hạn rồi chạy lại để kiểm tra nó không giải phóng hai lần hoặc làm đổi booking đã xác nhận. Thử xử lý lại thông tin thanh toán để xác nhận không tạo thêm yêu cầu phòng. Việc một thông báo được nhận hai lần không nên tương đương hai lần khách được phân bổ chỗ.
Tiếp theo, đưa hai tác vụ gần cùng mốc để quan sát nhánh đồng thời. Kết quả cần có một trạng thái cuối có thể giải thích, không vừa báo còn chỗ trên một màn hình vừa báo hết trên màn hình khác. Nếu cấu hình hoặc tích hợp chưa hỗ trợ kiểm thử này, chưa nên gọi luồng giữ phòng tự động là đã được chứng minh.
Chỉ số vận hành nên gồm số yêu cầu hết hạn, số ngoại lệ muộn và thời gian đối chiếu. Chúng khác doanh thu đã thu hoặc tỷ lệ đặt thành công. Một yêu cầu được giải phóng đúng không phải đơn bán bị lỗi; có thể khách đơn giản không tiếp tục. Phân biệt đúng sẽ giúp đội vận hành cải thiện luồng mà không chạy theo số đơn ảo.
Nếu cần Onter rà soát giữ phòng, booking và ngoại lệ thanh toán trên website, hãy Nhận tư vấn & báo giá theo chính sách của cơ sở và công cụ đang dùng. Giá liên hệ; mọi thử nghiệm giao dịch cần được thực hiện trong phạm vi đã cho phép.
