Hai thông báo tiền về giống nhau chưa chắc là hai khoản thu. Có thể ngân hàng gửi lại sự kiện cũ, ứng dụng ghi sổ hai lần, hoặc khách thực sự chuyển tiền hai lần. Xóa một dòng chỉ vì trùng số tiền có thể làm mất khoản thu thật; hoàn tiền ngay khi thấy hai thông báo có thể khiến doanh nghiệp trả nhầm.
Muốn xử lý đúng, cần lần theo khoản tiền từ dữ liệu nguồn đến đơn hàng và tác vụ giao hàng. Trên hoadontudong.com.vn, quy trình dưới đây đặt khóa chống trùng ở từng nơi có thể phát sinh tác động: ghi nhận giao dịch, phân bổ tiền và chuyển trạng thái đơn. Khoản khách trả dư đi qua một nhánh xử lý riêng, có bằng chứng và người duyệt.
Cách xử lý giao dịch ngân hàng bị trùng lặp tự động: phân biệt ba lớp
Trùng thông báo xảy ra khi một giao dịch được gửi đến máy chủ nhiều lần. Chẳng hạn, máy chủ đã lưu khoản thu nhưng phản hồi bị đứt kết nối, bên gửi chưa biết lần nhận trước thành công nên thử lại. Đây vẫn là một khoản tiền. Dữ liệu cần giữ một bản ghi thanh toán và nhiều bản ghi tiếp nhận, thay vì cộng thêm vào công nợ sau mỗi lần gọi.
Trùng ghi sổ lại nằm bên trong ứng dụng. Chỉ một thông báo đến nhưng hai tiến trình cùng xử lý, hoặc nhân viên nhập thêm khoản đã được hệ thống ghi tự động. Khi đó phải kiểm tra lịch sử thao tác, chứng từ liên quan và nguồn tạo bản ghi. Việc sửa cần bảo toàn dấu vết; không xóa lịch sử để làm báo cáo trông có vẻ khớp.
Thanh toán hai lần là hai khoản ghi có thật, thường có mã tham chiếu khác nhau. Khách có thể bấm chuyển lại vì màn hình chờ, hoặc phụ huynh và học viên cùng trả một khoản. Doanh nghiệp cần ghi nhận cả hai giao dịch rồi xác định phần thanh toán dư. Khóa chống trùng phải chặn việc xử lý lặp một giao dịch, đồng thời cho phép hai giao dịch độc lập đi vào hàng đợi kiểm tra.
Thu thập bằng chứng trước khi sửa dữ liệu
Khi có cảnh báo, nhân viên nên tạm dừng tác vụ phát sinh thêm cho đúng đơn đang điều tra: giao hàng lần hai, nạp ví hoặc phát hành thêm chứng từ. Không cần đóng toàn bộ hoạt động nếu sự cố chỉ giới hạn ở một đơn. Ghi lại mã đơn, tài khoản nhận đã che bớt, số tiền, thời điểm ghi nhận, mã giao dịch phía ngân hàng và các lần gọi thông báo.
Tiếp theo, đối chiếu lịch sử giao dịch được truy xuất từ nguồn ngân hàng hoặc kênh dữ liệu đã liên kết. Ảnh chụp biên lai của khách chỉ hỗ trợ tìm kiếm. Nếu ứng dụng có hai dòng nhưng nguồn ghi có chỉ có một giao dịch, điều tra luồng dữ liệu trước khi bàn chuyện hoàn tiền. Nếu nguồn có hai khoản khác nhau, chuyển sang xử lý trả dư theo chính sách của doanh nghiệp.
Hướng dẫn về webhook giao dịch ngân hàng và chống ghi nhận lặp giúp đội kỹ thuật hình dung điểm tiếp nhận dữ liệu. Trong hồ sơ sự cố, cần phân biệt thời điểm giao dịch phát sinh, thời điểm thông báo đến và thời điểm ứng dụng xử lý. Ba mốc này không nhất thiết bằng nhau, nhất là khi máy chủ ngừng hoạt động hoặc xử lý lại dữ liệu cũ.
Đặt khóa chống trùng theo giao dịch, không theo số tiền
Khóa tốt phải dựa trên định danh ổn định của khoản thu trong đúng phạm vi nguồn dữ liệu. Nếu nhiều tổ chức hoặc nhiều nhà cung cấp dùng chung một hệ thống, phạm vi khóa còn cần chứa tổ chức và nguồn. Chỉ dùng số tiền, nội dung chuyển khoản hoặc thời gian làm khóa sẽ dễ nhầm: hai khách cùng mua gói 500.000 đồng có thể thanh toán trong cùng phút.
Việc kiểm tra và ghi khóa nên nằm trong một thao tác nhất quán ở cơ sở dữ liệu. Cách làm kiểm tra trước, rồi một lúc sau mới lưu có thể thất bại khi hai tiến trình cùng nhận thông báo. Ràng buộc duy nhất tại nơi lưu dữ liệu giúp hệ thống xác định tiến trình nào được tạo bản ghi, thay vì trông chờ hai tiến trình tự nhường nhau.
Với thông báo đã xử lý, ứng dụng cần trả kết quả nhận phù hợp mà không chạy lại các tác vụ tiền. Với thông báo đang xử lý, nên ghi nhận trạng thái chờ và để tiến trình chịu trách nhiệm hoàn tất. Nếu lần trước thất bại sau khi đã lưu khoản thu, lần chạy lại phải tiếp tục phần việc chưa xong; không được cộng công nợ lần nữa rồi mới kiểm tra giao hàng.
Khóa chống trùng là đề xuất thiết kế của ứng dụng doanh nghiệp. Tên trường, phạm vi định danh và cách phản hồi phải đối chiếu với tài liệu đúng loại API đang sử dụng.
Xác thực thông báo rồi mới cập nhật đơn
Thông báo hợp lệ về mặt định danh chưa đủ để xác nhận thanh toán. Ứng dụng còn cần kiểm tra nguồn gửi, tài khoản nhận, đơn liên quan, số tiền, loại tiền và trạng thái. Một yêu cầu giả chứa mã giao dịch mới vẫn có thể vượt qua khóa duy nhất nếu hệ thống không xác thực. Vì vậy, bảo mật và chống trùng là hai lớp cần được triển khai cùng nhau.
Tài liệu IPN Pay2S mô tả thông báo đến máy chủ và yêu cầu kiểm tra chữ ký, đơn, số tiền. Khi thiết kế luồng nhận, đội triển khai nên đọc đặc tả chính thức thay vì lấy dữ liệu trình duyệt làm kết luận cuối cùng. Bài phân biệt redirect và IPN giải thích rõ hai điểm tiếp xúc này.
Sau khi lưu khoản thu hợp lệ, tác vụ phía sau cần có khóa riêng theo nghiệp vụ. Đơn chỉ được giao một lần; một quyền sử dụng chỉ được kích hoạt theo số lần đã mua; một yêu cầu xuất chứng từ chỉ được tạo theo quy tắc được duyệt. Nếu chỉ chống trùng ở cổng vào nhưng chương trình gửi hàng tự thử lại thiếu kiểm soát, sự cố vẫn có thể xảy ra ở bước cuối.
Tình huống giả định: hai thông báo và hai khoản thu
Giả định cửa hàng có đơn A trị giá 800.000 đồng. Hệ thống nhận thông báo giao dịch T1, lưu khoản thu và chuyển đơn sang đã thanh toán. Sau đó T1 được gửi lại. Ứng dụng tìm thấy khóa đã hoàn tất, ghi thêm lần tiếp nhận và không tạo khoản thu mới. Khoản công nợ đã thanh toán vẫn là 800.000 đồng, không phải 1.600.000 đồng.
Cũng trong ví dụ này, khách chuyển thêm một khoản T2 trị giá 800.000 đồng. Vì T2 là giao dịch khác, hệ thống lưu khoản thu thứ hai nhưng không xuất thêm hàng cho đơn A. Khoản này được gắn trạng thái cần xác minh trả dư. Nhân viên liên hệ qua thông tin khách hàng đã có trong đơn, kiểm tra chủ thể nhận hoàn và trình người có quyền phê duyệt.
Nếu T2 thanh toán cho đơn B trong tình huống giả định này, nhân viên phân bổ với lý do và bằng chứng kèm theo. Nếu khách yêu cầu hoàn, hồ sơ hoàn liên kết tới T2 và lưu kết quả riêng. Như vậy, thao tác xử lý khoản dư không xóa dấu vết hai khoản thu ban đầu.
Kiểm thử cả dữ liệu lặp và tác vụ bị gián đoạn
Bộ thử nghiệm nên có một giao dịch gửi nhiều lần, hai giao dịch thật cùng số tiền, hai tiến trình nhận đồng thời và một lần máy chủ dừng ngay sau khi lưu khoản thu. Thêm tình huống thông báo cũ đến sau thông báo mới, đơn đã hủy, số tiền không đúng và chữ ký không hợp lệ. Mỗi lần thử phải kiểm tra cả dữ liệu thanh toán lẫn tác vụ giao hàng hoặc cấp quyền.
Tài liệu mô phỏng thanh toán đơn demo của Pay2S có lựa chọn gửi lại IPN cho đơn demo đã thanh toán. Đây là điểm kiểm tra hữu ích cho luồng chống xử lý lặp. Đội triển khai vẫn phải tự kiểm thử trạng thái ứng dụng, vì việc gửi lại thông báo thành công chưa chứng minh hệ thống kho, công nợ và thông báo khách hàng đều hoạt động đúng.
Tiêu chí đạt nên đo bằng kết quả: một khoản thu cho một giao dịch, một lần giao cho một lệnh hợp lệ, không tăng số dư sau lần gửi lại, và có hồ sơ cho mọi khoản trả dư. Có thể dùng checklist thử nghiệm trước khi chạy thật để bổ sung điều kiện môi trường, quyền truy cập và khả năng phục hồi.
Theo dõi sau triển khai và xử lý khoản dư có kiểm soát
Báo cáo vận hành nên tách số lần nhận thông báo khỏi số giao dịch ngân hàng và số khoản thu được phân bổ. Nếu chỉ nhìn số request, một ngày có nhiều lần thử lại có thể bị hiểu nhầm là doanh thu tăng. Cần theo dõi riêng giao dịch chưa gắn đơn, bản tin lặp, tác vụ chờ và khoản tiền dư đang đợi quyết định.
Với sự cố diện rộng, hãy đánh dấu khoảng thời gian bị ảnh hưởng và lập danh sách giao dịch cần kiểm tra lại. Sau khi sửa lỗi, đối chiếu từng khoản với đơn và tác vụ đã chạy trước khi mở lại việc xử lý tự động. Chỉ gửi lại thông báo theo một danh sách kiểm soát, giữ kết quả từng lần và có điều kiện dừng nếu số liệu tiếp tục lệch. Cách phục hồi này giúp tránh sửa lỗi cũ rồi tạo thêm giao hàng hoặc cộng tiền lặp.
Với lỗi ghi sổ, doanh nghiệp nên tạo điều chỉnh có lý do và người thực hiện theo quy trình kế toán đang áp dụng. Với lỗi giao hàng hai lần, phải xử lý cả tồn kho và chăm sóc khách hàng. Với khoản trả dư, cần xác minh rồi mới hoàn hoặc bù trừ theo thỏa thuận. Không tự chuyển tiền theo số tài khoản được gửi trong một tin nhắn lạ.
Luồng chống trùng chỉ hoàn chỉnh khi có thể truy từ khoản thu đến lần giao hàng hoặc hoàn tiền tương ứng. Với sự cố còn khó xác định, đội tư vấn giải pháp Pay2S cần xem mẫu sự kiện đã che thông tin nhạy cảm, lịch sử cập nhật đơn và quy tắc phân bổ. Ba dữ liệu này giúp tìm đúng chỗ phát sinh tác động lặp để sửa, thay vì thêm một bộ lọc số tiền ở đầu vào.
