Khách đã chuyển khoản nhưng đơn trên website vẫn chờ xác nhận: khoảng trống thường nằm giữa dữ liệu ngân hàng và backend bán hàng. QR giúp khách nhập thông tin thuận tiện hơn, còn việc biết tiền đã về, thuộc đơn nào và có đủ điều kiện giao hàng hay không cần một luồng kiểm tra riêng.
Đó là bài toán khi tích hợp đối soát ngân hàng cho website bán hàng không qua cổng thanh toán. Với cửa hàng muốn bớt mở ứng dụng ngân hàng để dò đơn, phần cần thiết kế gồm nguồn giao dịch, quy tắc khớp và nơi xử lý khoản chưa xác định. Kiến trúc dưới đây là phương án triển khai; các chi tiết Pay2S được đối chiếu với tài liệu chính thức.
Tích hợp đối soát ngân hàng cho website bán hàng không qua cổng thanh toán cần những gì?
Trước hết, cần thống nhất ý nghĩa của “không qua cổng thanh toán”: người mua chuyển khoản vào tài khoản của cửa hàng, website không bắt buộc dùng một trang checkout trung gian. Tuy vậy, cửa hàng vẫn có thể sử dụng dịch vụ API ngân hàng hoặc webhook để lấy dữ liệu. Dịch vụ kết nối dữ liệu, phí ngân hàng và công triển khai vẫn cần được tính vào ngân sách.
Ba thành phần tối thiểu là hệ thống đơn hàng, nguồn thông tin giao dịch và bộ quy tắc đối chiếu. Hệ thống đơn ghi giá trị phải thu từ server. Nguồn giao dịch cho biết tài khoản nhận, số tiền thực nhận và mã tham chiếu. Bộ đối chiếu quyết định khoản tiền nào thuộc đơn nào, đủ điều kiện giao hàng hay cần nhân viên kiểm tra.
Với website chưa có backend hoặc chỉ là trang giới thiệu, cần xây phần quản lý đơn trước. Một form đặt hàng gửi email có thể đáp ứng giai đoạn đầu nhưng khó bảo đảm đồng bộ trạng thái khi nhiều nhân viên cùng xử lý. Hãy xác định rõ nơi lưu trạng thái chính thay vì duy trì đồng thời nhiều bảng khác nhau.
Thiết kế luồng từ đặt hàng đến xác nhận tiền
Luồng đề xuất bắt đầu khi server tạo đơn và sinh mã thanh toán duy nhất. Website hiển thị tài khoản nhận, số tiền, nội dung chuyển khoản cùng QR tương ứng. Khách thực hiện chuyển tiền trên ứng dụng ngân hàng. Khi backend nhận dữ liệu giao dịch hợp lệ, hệ thống đối chiếu rồi chuyển đơn sang đã thanh toán hoặc chờ xác minh.
Theo giới thiệu chuyển nhanh NAPAS 247 bằng VietQR, quét mã giúp giảm thao tác nhập thông tin ngân hàng và tài khoản; người chuyển vẫn cần kiểm tra người thụ hưởng trước khi xác nhận. Vì vậy, giao diện nên hiển thị rõ tên nhận tiền, tránh đặt QR như một hình ảnh tách rời khỏi đơn.
Nên để màn hình chờ thanh toán gọi trạng thái từ backend theo khoảng thời gian phù hợp. Khi khách đóng trình duyệt hoặc rời website để mở ứng dụng ngân hàng, quy trình ghi nhận tiền vẫn phải tiếp tục. Trang cảm ơn nên phản ánh trạng thái đã được server kiểm chứng, có hướng dẫn liên hệ nếu tiền đã chuyển nhưng đơn còn chờ.
Chuẩn hóa dữ liệu trước khi viết phần kết nối
Mã đơn và mã thanh toán nên tách biệt nếu hệ thống có nhiều kênh bán hàng. Mã thanh toán cần duy nhất trong phạm vi vận hành, đủ ngắn để người mua kiểm tra và ổn định khi khách tải lại trang. Khi thay đổi số tiền hoặc nội dung đơn, ghi lại phiên bản thay vì âm thầm sửa dữ liệu mà khách đã dùng để chuyển khoản.
| Nhóm | Thông tin chính | Mục đích |
|---|---|---|
| Đơn hàng | Mã đơn, giá trị phải thu, trạng thái, hạn thanh toán | Biết cửa hàng đang chờ khoản nào |
| Tài khoản | Chủ thể nhận, ngân hàng, ID liên kết | Kiểm tra tiền về đúng nơi |
| Giao dịch | ID nguồn, số tiền, chiều, thời điểm, nội dung | Truy vết khoản tiền thực nhận |
| Phân bổ | Giao dịch nào trả đơn nào, số tiền phân bổ | Tránh dùng một khoản tiền cho nhiều đơn |
Giữ số tài khoản và mã tham chiếu dưới dạng chuỗi để không mất số không ở đầu. Lưu riêng nội dung gốc và nội dung đã chuẩn hóa phục vụ tìm kiếm. Khi nhân viên ghép một khoản tiền bằng tay, hệ thống phải lưu người thao tác, lý do và thông tin trước/sau để giải thích được khi khách khiếu nại.
Kết nối Pay2S theo đúng loại dữ liệu
Tài liệu quản lý ngân hàng Pay2S mô tả API liên kết tài khoản, xác nhận OTP và kiểm tra danh sách. Phương thức kết nối có thể khác nhau theo ngân hàng, loại tài khoản và cấu hình. Đội triển khai cần đọc lại trạng thái sau liên kết, thay vì xem phản hồi ban đầu là bằng chứng tài khoản đã sẵn sàng nhận dữ liệu.
Webhook giao dịch dùng để chuyển thông tin tiền vào hoặc ra tới endpoint của đối tác. Tài liệu webhook Partner API có phần token riêng, lịch sử gửi và gửi lại. Đây là nguồn để xây lớp nhận dữ liệu; việc khớp khoản tiền với đơn và cho phép giao hàng vẫn phải được website kiểm soát.
Trên hoadontudong.com.vn, bạn có thể đọc hướng dẫn BankHub và API thanh toán ngân hàng Pay2S trước khi giao việc cho developer. Cần phân biệt webhook giao dịch với thông báo tiến trình liên kết tài khoản. Hai loại phục vụ mục đích khác nhau và không nên dùng chung bộ xử lý chỉ vì đều được gửi bằng HTTP.
Nhận webhook an toàn và chống cập nhật lặp
Endpoint nhận dữ liệu nên chạy qua HTTPS, xác thực theo đúng tài liệu của loại webhook đang dùng và giới hạn payload hợp lệ. Sau khi nhận, lưu bản ghi cần thiết vào cơ sở dữ liệu rồi đưa nghiệp vụ vào hàng đợi. Nếu chưa lưu được, không trả thành công chỉ để làm đẹp tỷ lệ nhận webhook; dữ liệu có thể bị bỏ qua trong ứng dụng.
Một giao dịch có thể được gửi lại khi nhân viên phục hồi sự cố hoặc hệ thống kết nối thực hiện lại yêu cầu. Vì thế, khóa chống trùng cần được kiểm tra tại database, không chỉ trong bộ nhớ của một máy chủ. Hai tiến trình nhận đồng thời vẫn phải chỉ tạo một tác động ghi nhận tiền cho cùng giao dịch nguồn.
Luồng khái niệm dưới đây là giả mã kiến trúc, không phải tên endpoint hay schema Pay2S:
Xác thực nguồn gửi
Lưu sự kiện bằng khóa duy nhất
Đối chiếu tài khoản, mã đơn, số tiền
Ghi nhận phân bổ trong giao dịch database
Tạo tác vụ giao hàng hoặc gửi thông báo một lần
Phản hồi theo hợp đồng webhookĐọc thêm cách nhận webhook ngân hàng và chống trùng để xây tiêu chí kiểm thử cho receiver. Đừng gộp lỗi gửi thông báo với lỗi thanh toán: khách có thể đã trả tiền đúng dù email xác nhận chưa gửi thành công.
Đặt quy tắc cho trả thiếu, sai mã và đơn hết hạn
Khoản tiền đúng mã nhưng thấp hơn số phải thu nên vào trạng thái thanh toán một phần hoặc chờ bổ sung theo chính sách của shop. Nếu hệ thống chưa hỗ trợ thu nhiều lần, giữ đơn để nhân viên xử lý. Không tự giao đủ hàng chỉ vì đã tìm thấy một khoản tiền có nội dung gần giống mã đơn.
Với nội dung thiếu mã, tạo danh sách tiền chưa phân bổ. Nhân viên tra cứu bằng thời điểm, tài khoản nhận, số tiền và thông tin khách cung cấp, sau đó xác minh thêm trước khi ghép. Hai khách cùng thanh toán một giá trị là tình huống có thể xảy ra; số tiền đơn lẻ không đủ xác định người trả.
Đơn hết hạn nhưng tiền đến muộn cần một chính sách riêng: kiểm tra tồn kho và giá hiện tại, liên hệ khách để tiếp tục hoặc hoàn theo quy trình. Đừng tự chuyển khoản trả vào số tài khoản được gửi trong tin nhắn mà chưa xác minh. Khi có khoản trả thừa, lưu phần chênh lệch để xử lý riêng, không sửa số tiền gốc của đơn.
Tình huống giả định: khách chuyển tiền khi đã đóng website
Giả sử một shop đồ gia dụng tạo đơn 680.000 đồng và khách đóng trình duyệt sau khi lưu QR. Khách thanh toán vài phút sau. Endpoint đã nhận sự kiện nhưng công cụ gửi email đang lỗi. Thiết kế đúng vẫn ghi đơn đã thanh toán trong database; email được đưa vào hàng đợi xử lý lại, không yêu cầu khách chuyển tiền lần thứ hai.
Sáng hôm sau, khách mở đường dẫn đơn và thấy trạng thái mới từ server. Nhân viên chăm sóc khách tra được mã giao dịch, thời điểm và lịch sử email trong cùng hồ sơ. Đây là tình huống giả định để minh họa việc tách trạng thái thanh toán khỏi trạng thái thông báo, không phải case khách hàng hoặc số liệu kết quả triển khai Pay2S.
Kiểm thử và vận hành trước khi mở cho mọi đơn
Hãy thử một tài khoản và một nhóm đơn có người theo dõi. Bộ thử phải có đúng tiền, thiếu tiền, sai mã, webhook lặp, hai sự kiện đến đồng thời và website tạm ngừng. Kiểm tra cả việc khách tải lại trang, đơn đổi giá, hủy đơn trước khi chuyển và tiền đến sau giờ chốt ngày.
Đối soát cuối ngày nên so tổng khoản nhận với giao dịch đã lưu, rồi so giao dịch đã lưu với tiền đã phân bổ cho đơn. Ba tập dữ liệu này có thể khác nhau vì khoản chưa xác định hoặc sự cố kết nối. Ghi rõ chênh lệch và người phụ trách thay vì ép tất cả trạng thái thành đã khớp.
Đội kỹ thuật cần thống nhất với vận hành về thời gian chờ cảnh báo, người được gửi lại sự kiện và cách xử lý khi mất kết nối ngân hàng. Với tác vụ giao hàng, giữ nhật ký rõ đơn đã được chuyển kho chưa. Nếu nối sang hóa đơn, tham khảo quy trình đối soát sau chuyển khoản trước bước hóa đơn và quản lý trạng thái phát hành riêng.
Câu hỏi thường gặp
Chỉ tạo QR có đủ tự xác nhận đơn không?
Chưa đủ. QR giúp khách nhập lệnh chuyển thuận tiện; website cần nhận dữ liệu giao dịch và đối chiếu với đơn để biết khoản tiền đã đến đúng tài khoản.
Website nhỏ có nên triển khai ngay không?
Nên đo số đơn, thời gian kiểm tra và tỷ lệ phải xử lý tay trước. Nếu lượng đơn thấp, chuẩn hóa mã thanh toán và quy trình có thể là bước đầu phù hợp; khi mở rộng mới đầu tư sâu vào tích hợp.
Có thể bỏ kiểm tra cuối ngày sau khi tự động hóa không?
Không nên. Kiểm tra định kỳ giúp phát hiện dữ liệu thiếu, tiền chưa phân bổ hoặc tác vụ sau thanh toán chưa hoàn tất. Tự động hóa làm bước kiểm tra tập trung và nhanh hơn.
Trước khi mở xác nhận tự động cho mọi đơn, hãy thử một luồng bán hàng từ lúc tạo đơn đến khi giao hàng hoặc cấp quyền. Mỗi khoản tiền phải truy được về nguồn, mỗi ngoại lệ phải có nơi xử lý. Nếu nhân viên vẫn không giải thích được vì sao một đơn đã trả mà còn chờ, phần tích hợp chưa hoàn tất dù webhook đã chạy.
