Tích hợp thanh toán QR cho website không qua cổng thanh toán có thể giúp khách chuyển khoản trực tiếp vào tài khoản nhận của cửa hàng, đồng thời giữ trải nghiệm theo từng đơn trên website. Phần cần thiết kế kỹ là dữ liệu QR, hạn thanh toán và trạng thái xác nhận. Một mã hiển thị đúng không tự chứng minh khách đã trả, còn một màn hình hết giờ không tự ngăn được mọi khoản chuyển đến tài khoản.
Bài viết tập trung vào trải nghiệm QR theo đơn: khách nhìn thấy gì, được dùng mã nào và website xử lý thế nào khi đơn thay đổi hoặc tiền đến muộn. Lớp kết nối ngân hàng và backend cần được xây theo tài liệu của dịch vụ thực tế.
Hiểu phạm vi chuyển khoản trực tiếp trên website
Trong mô hình này, người mua dùng ứng dụng ngân hàng để chuyển tới tài khoản nhận đã chỉ định. Website có thể hiển thị QR ngay trong trang đơn thay vì bắt buộc đưa khách sang một trang checkout khác. Tuy nhiên, việc lấy dữ liệu và đối soát vẫn có thể cần dịch vụ API hoặc webhook cùng chi phí triển khai.
NAPAS mô tả VietQR giúp khởi tạo chuyển khoản bằng quét mã và hướng dẫn kiểm tra người thụ hưởng trước xác nhận. Vì vậy, trang thanh toán nên hiển thị tên nhận, số tiền và mục đích bằng chữ, không chỉ một ảnh QR để khách phải tự đoán.
Cần xác định mô hình đang dùng là QR chứa thông tin chuyển khoản, QR gắn yêu cầu thanh toán hay dịch vụ có tài khoản định danh theo đơn. Cách hết hạn, xử lý tiền sai và nhận trạng thái có thể khác nhau. Không áp hành vi của một mô hình sang tất cả mã QR chỉ vì hình thức quét giống nhau.
Tạo QR từ dữ liệu đơn trên server
Server phải quyết định số tiền, tài khoản nhận và mã thanh toán từ hồ sơ đơn đã được kiểm tra. Không tin một số tiền do trình duyệt gửi lên mà chưa đối chiếu lại giỏ hàng hoặc đơn. Người dùng có thể tải lại trang, đổi tham số hoặc sử dụng dữ liệu cũ; frontend không nên là nguồn giá trị cuối cùng.
Mỗi mã thanh toán cần nối về một phiên bản đơn. Khi khách thêm hàng, dùng mã giảm giá hoặc thay phương thức giao, hệ thống xác định yêu cầu cũ còn hiệu lực hay phải tạo phiên bản mới. Lưu quan hệ để khoản chuyển theo QR đã lưu trước đó vẫn được tìm thấy và xử lý.
Pay2S giới thiệu cơ chế ký và xác minh dữ liệu thanh toán/QR. Nếu chọn luồng sản phẩm đó, đội triển khai cần đối chiếu tài liệu và kiểm thử đúng cơ chế. Xác minh tính toàn vẹn dữ liệu hiển thị là một lớp bảo vệ; việc tiền thực nhận có đúng đơn vẫn cần đối soát riêng.
Thiết kế trang thanh toán để khách biết bước tiếp theo
Trang nên có thông tin đơn, số tiền, bên nhận, QR và hướng dẫn ngắn. Người dùng máy tính có thể quét bằng điện thoại; người dùng điện thoại cần cách lưu hoặc sao chép thông tin phù hợp với ứng dụng họ dùng. Không buộc khách phải ghi nhớ nội dung dài rồi rời trang để gõ lại.
Nút “Tôi đã chuyển khoản” có thể giúp khách yêu cầu kiểm tra hoặc mở hướng dẫn, nhưng không được trực tiếp đặt đơn thành đã thanh toán. Giao diện cần nói rõ đang chờ hệ thống xác nhận. Khi dữ liệu đến, hiển thị trạng thái từ backend thay vì suy ra từ thao tác bấm nút.
| Thông tin | Mục đích |
|---|---|
| Mã đơn và nội dung thanh toán | Giúp khách kiểm tra, nhân viên tra cứu |
| Tên bên nhận và tài khoản | Xác nhận đúng nơi chuyển |
| Số tiền và phiên bản đơn | Tránh dùng giá đã thay đổi |
| Thời hạn theo chính sách | Biết khi nào cần mở lại yêu cầu |
| Trạng thái server | Phân biệt đang chờ với đã xác nhận |
| Đầu mối hỗ trợ | Giải quyết tiền đã chuyển nhưng chưa khớp |
Đừng đưa dữ liệu kỹ thuật không giúp khách quyết định lên màn hình. Token, chữ ký hoặc log thuộc lớp xử lý, không nên xuất hiện như hướng dẫn cho người mua. Người mua cần biết kiểm tra thông tin, thực hiện thanh toán và xem kết quả ở đâu.
Hết hạn là quy tắc đơn hàng cần được thực thi
Bộ đếm thời gian trên trình duyệt chỉ hỗ trợ trải nghiệm. Server mới quyết định đơn hoặc yêu cầu còn được xử lý theo điều kiện nào. Khi hết hạn, trang cần ngừng mời khách dùng thông tin cũ và hướng dẫn kiểm tra hoặc tạo yêu cầu mới phù hợp.
Với QR chuyển vào tài khoản thông thường, việc website ngừng hiển thị mã chưa chắc ngăn khách chuyển từ ảnh đã lưu. Cần chính sách cho tiền đến muộn: kiểm tra tồn kho, giá và tình trạng đơn, sau đó quyết định tiếp tục hoặc xử lý khoản nhận. Không tự coi mọi tiền sau hạn là không tồn tại.
Nếu dùng sản phẩm có khả năng hủy hoặc hết hạn ở phía dịch vụ, kiểm tra đúng trạng thái và contract. Hướng dẫn xử lý hủy yêu cầu thanh toán Pay2S là tài liệu liên quan khi chọn luồng đó; không áp thao tác này cho một ảnh QR tĩnh không có yêu cầu tương ứng.
Chống sửa số tiền bằng đối soát, không chỉ bằng giao diện
Dù website hiển thị số tiền từ server, backend vẫn phải so khoản thực nhận với giá trị cần thanh toán. Khả năng thay đổi trường khi chuyển phụ thuộc ứng dụng và dịch vụ đang dùng. Quy tắc an toàn là không giả định tiền vào luôn đúng số chỉ vì khách đã quét QR.
Trả thiếu, trả thừa và mã không rõ cần trạng thái riêng. Với trả nhiều lần, lưu từng giao dịch và phần đã phân bổ. Không cho một khoản nhận trả đủ hai đơn, cũng không xóa khoản thứ hai thật chỉ vì giống giá trị khoản đầu. Dữ liệu nguồn và quy tắc nghiệp vụ phải được kiểm tra cùng nhau.
Website có thể dùng nguồn giao dịch từ BankHub Pay2S cho phần xác nhận, nếu tài khoản và luồng kết nối phù hợp. API cung cấp dữ liệu không tự thay cho việc kiểm tra tồn kho, giao hàng hay điều kiện sử dụng dịch vụ.
Xác nhận từ backend, kể cả khi khách rời trang
Khách thường phải chuyển sang ứng dụng ngân hàng rồi quay lại. Một số người đóng trình duyệt sau khi lưu mã. Do đó, quy trình nhận giao dịch cần tiếp tục độc lập với trang đang mở. Khi khách trở lại đường dẫn đơn, website lấy trạng thái đã được server xác nhận.
Tài liệu webhook Pay2S mô tả thông báo giao dịch và lịch sử gửi. Nếu dùng webhook, receiver cần xác thực nguồn, lưu dữ liệu và chống tác động lặp. Trạng thái thành công chỉ được cập nhật khi điều kiện đối chiếu đạt, không phải khi website nhận bất kỳ request nào.
Đội triển khai có thể đọc cách nhận sự kiện ngân hàng và chống trùng để xây bài thử. Khi cùng sự kiện được gửi lại, đơn không được giao hoặc cấp quyền hai lần. Nếu thông báo cho khách lỗi, xử lý lại thông báo dựa trên đơn đã trả, không lặp ghi nhận tiền.
Tình huống giả định: khách dùng QR trước khi đổi đơn
Giả sử khách lưu QR rồi thay giỏ hàng, làm số tiền cần trả tăng. Họ vẫn chuyển theo ảnh cũ. Nếu website chỉ tìm đúng mã rồi xác nhận, cửa hàng có thể giao đơn mới dù tiền nhận dành cho phiên bản cũ và chưa đủ.
Thiết kế đề xuất giữ phiên bản đơn và yêu cầu thanh toán. Khoản đến được lưu, hệ thống xác định chênh lệch rồi đưa cách bổ sung hoặc xử lý theo chính sách. Đây là tình huống giả định về trải nghiệm QR, không phải case của Pay2S hoặc sự bảo đảm một cấu hình mặc định sẽ tự giải quyết.
Đào tạo hỗ trợ cho các trạng thái khách nhìn thấy
Nhân viên cần biết “đang chờ”, “cần kiểm tra”, “đã trả một phần” và “đã xác nhận” khác nhau thế nào. Khi khách gọi, họ tra theo mã đơn và khoản nguồn, không yêu cầu gửi lại hàng loạt ảnh. Câu trả lời nên nêu bước tiếp theo và mốc cập nhật phù hợp.
Đối với tiền sai nội dung hoặc đến muộn, giữ một hồ sơ hỗ trợ có người phụ trách. Không sửa trạng thái chỉ để khách bớt chờ khi bằng chứng chưa đủ. Nếu cần ghép tay, ghi lý do và kiểm tra đơn chưa được thanh toán bằng khoản khác.
Website nên có hướng dẫn ngắn ngay trên trang chờ để giảm câu hỏi lặp. Tránh dùng thông báo “thất bại” cho mọi trường hợp chưa nhận dữ liệu, vì khách có thể đã chuyển thành công. Giao diện cần phân biệt chưa xác nhận với ngân hàng đã từ chối theo dữ liệu thực sự có.
Kiểm thử QR trên cả hành vi bình thường và ngoại lệ
Thử trên thiết bị và ứng dụng phù hợp với khách mục tiêu: quét trực tiếp, dùng ảnh đã lưu, quay lại trang, tải lại và mở lại đơn. Kiểm tra QR cùng thông tin chữ có nhất quán không. Không dùng một lần quét thành công trên máy của developer làm kết luận cho toàn bộ trải nghiệm.
Bộ thử nghiệp vụ cần có đổi đơn, hết hạn, tiền đến muộn, trả thiếu, trả thừa và gửi lại sự kiện. Yêu cầu số tiền nguồn, phân bổ và trạng thái cuối giải thích được. Một QR đẹp nhưng không có cách xử lý khoản lệch sẽ đẩy việc về nhân viên hỗ trợ sau khi chạy thật.
Nếu nối hóa đơn, giữ quy tắc riêng cho nghiệp vụ và thời điểm lập. Tham khảo kiểm tra dữ liệu sau chuyển khoản trước bước hóa đơn để tách tác vụ. Việc khách quét mã hoặc tiền đã khớp chưa tự chứng minh mọi điều kiện chứng từ đều đầy đủ.
Câu hỏi thường gặp
QR theo đơn có tự ngăn khách trả sai số tiền không?
Không nên mặc định. Cần kiểm tra hành vi của sản phẩm, ngân hàng và ứng dụng đang dùng. Backend vẫn phải đối chiếu số tiền thực nhận với nghĩa vụ.
Đơn hết hạn thì có thể bỏ mọi khoản chuyển đến sau đó không?
Không. Cần lưu và xử lý khoản tiền đã nhận theo chính sách, kiểm tra tình trạng đơn và trao đổi với khách. Hết hạn giao diện không tự đảo một giao dịch ngân hàng.
Khách bấm đã chuyển tiền có được xác nhận đơn không?
Nút đó chỉ nên hỗ trợ trải nghiệm hoặc yêu cầu kiểm tra. Xác nhận phải dựa trên dữ liệu nguồn đã được backend đối chiếu và lưu.
Trên hoadontudong.com.vn, cách triển khai thực dụng là giữ QR gắn với đơn và đặt nguồn xác nhận ở server. Khi mã cũ, số tiền lệch và tiền đến muộn đều có cách xử lý rõ, chuyển khoản trực tiếp mới trở thành một trải nghiệm có thể vận hành ổn định.
