Ưu Đãi Khi Mua Hosting
Mã giảm giá 10% : HOSTING1205
Khi tích hợp ZaloPay, bạn cần log đủ để biết yêu cầu thanh toán đã đi đến đâu, lỗi xảy ra ở bước nào và đơn hàng nào cần tra soát. Cách làm an toàn là ghi sự kiện theo danh sách trường cho phép, không lưu nguyên gói dữ liệu gửi nhận, đồng thời giữ khóa bí mật và thông tin xác thực ngoài hệ thống log.
Hướng dẫn này dành cho lập trình viên và người vận hành website. Bạn sẽ có mẫu log minh họa, cách xử lý thông báo thanh toán, quy trình kiểm thử và nguyên tắc phân quyền. Tên trường tích hợp, cơ chế xác thực và quy tắc phản hồi phải đối chiếu tài liệu ZaloPay áp dụng cho sản phẩm đang sử dụng.
Trước khi thêm lệnh ghi log, hãy xác định nhu cầu tra soát. Với một đơn thanh toán, nhân viên kỹ thuật cần tìm được thời điểm tạo yêu cầu, kết quả kết nối, sự kiện thông báo nhận được và lần cập nhật trạng thái cuối cùng.
Mỗi sự kiện nên có một cấu trúc thống nhất:
Không dùng số điện thoại hoặc email làm mã tương quan. Nếu một yêu cầu bị timeout, log phải thể hiện chưa xác định kết quả, không tự kết luận giao dịch thất bại.
Không ghi toàn bộ request, response, header hoặc đối tượng lỗi rồi mới tìm cách xóa bí mật. Cách này dễ bỏ sót dữ liệu khi cấu trúc tích hợp thay đổi. Hãy tạo một đối tượng log mới, chỉ lấy các trường đã được duyệt.
Có thể cân nhắc lưu số tiền và đơn vị tiền tệ nếu chúng cần cho đối soát, nhưng không kèm toàn bộ hồ sơ khách hàng. Với mã kết quả từ nhà cung cấp, lưu giá trị cần thiết và diễn giải theo tài liệu; không suy đoán ý nghĩa từ tên mã.
Nếu cần nhận diện một thông tin đã che, chỉ hiển thị phần tối thiểu thực sự hữu ích. Việc băm số điện thoại không mặc nhiên biến nó thành dữ liệu vô danh, vì không gian giá trị có thể bị dò. Ưu tiên mã khách hàng nội bộ và kiểm soát quyền truy cập.
Trước khi gửi yêu cầu từ server tới ZaloPay, ghi mã đơn, mã tương quan và tên thao tác. Sau khi nhận phản hồi, ghi thời lượng, trạng thái HTTP nếu có và kết quả nghiệp vụ đã được phân loại. Hai lớp kết quả này cần tách biệt: kết nối HTTP thành công không đồng nghĩa thanh toán đã hoàn tất.
Ví dụ sau là dữ liệu giả lập; tên sự kiện và trường đều do ứng dụng tự quy ước, không phải cấu trúc API ZaloPay:
{
"timestamp": "2026-01-15T09:30:00+07:00",
"event": "payment_request_completed",
"correlation_id": "trace_demo_82",
"order_id": "order_demo_17",
"provider": "ZaloPay",
"http_status": 200,
"business_state": "pending",
"duration_ms": 240
}Trong ví dụ, trạng thái đang chờ là kết quả giả định của ứng dụng. Khi triển khai, chỉ ánh xạ trạng thái từ các giá trị đã được tài liệu xác định.
Với callback hoặc webhook từ phía dịch vụ, ghi nhận sự kiện đến, kết quả xác minh và quyết định xử lý. Xác minh tính xác thực theo đúng tài liệu ZaloPay trước khi dùng dữ liệu để thay đổi trạng thái đơn. Không tự thiết kế cách kiểm chữ ký dựa trên phỏng đoán.
Không tin trang chuyển hướng hoặc callback chạy trong trình duyệt như bằng chứng thanh toán. Khi xử lý phía server, đối chiếu mã đơn, số tiền và thông tin bên nhận hoặc định danh merchant theo các trường mà tài liệu hỗ trợ.
Nếu giao dịch dùng để nạp số dư, cần chống cộng tiền hai lần bằng định danh giao dịch duy nhất trong phạm vi phù hợp và ràng buộc duy nhất ở cơ sở dữ liệu. Việc ghi nhận giao dịch và cộng số dư phải nằm trong cùng một transaction cơ sở dữ liệu. Log chỉ ghi quyết định như đã áp dụng hoặc bỏ qua do trùng; log không thay thế sổ giao dịch.
Khi mất kết nối, ghi nhóm lỗi như timeout hoặc lỗi phân giải tên miền, kèm số lần thử. Không tự động gửi lại thao tác tạo thanh toán nếu chưa xác định cơ chế chống trùng được hỗ trợ. Retry cần tuân theo tài liệu và giữ khả năng liên kết với yêu cầu ban đầu.
Với thông báo được gửi lại, hệ thống phải xử lý an toàn theo trạng thái đã lưu. Một thông báo hợp lệ nhưng trùng nên tạo log ngắn về việc bỏ qua, thay vì thực hiện lại nghiệp vụ. Trường hợp không xác định được kết quả cần vào danh sách đối soát, sử dụng chức năng tra cứu được hỗ trợ hoặc xử lý thủ công.
Các lỗi ghi log thường gặp gồm:
Không đặt tệp log trong thư mục web có thể tải công khai. Giới hạn quyền đọc, bảo vệ đường truyền khi chuyển log sang hệ thống tập trung và áp dụng thời hạn lưu theo nhu cầu vận hành, nghĩa vụ liên quan. Bản sao lưu và bản xuất log cũng phải chịu cùng chính sách.
Thực hiện kiểm thử trên môi trường thử nghiệm được hỗ trợ, hoặc mô phỏng ở lớp ứng dụng:
Kết quả đạt yêu cầu là vừa tra được nguyên nhân lỗi, vừa không tìm thấy bí mật giả trong các kênh thu thập. Nếu hệ thống log gặp sự cố, ứng dụng cần có cơ chế quan sát thay thế, nhưng vẫn dựa vào dữ liệu giao dịch bền vững để đối soát.
Không nên mặc định lưu nguyên nội dung vào log. Nếu có nhu cầu lưu bằng chứng, hãy thiết kế kho dữ liệu riêng với mục đích rõ ràng, quyền truy cập chặt chẽ và thời hạn lưu; chỉ thu thập dữ liệu thực sự cần thiết.
Nên ưu tiên ghi kết quả xác minh, phiên bản cấu hình nội bộ và nhóm nguyên nhân lỗi. Không ghi khóa hoặc dữ liệu đầu vào nhạy cảm. Chỉ thu thập thêm trong phạm vi kiểm soát khi đã đánh giá rủi ro và đối chiếu tài liệu.
Không. Trạng thái phải dựa trên quy trình xác minh và bản ghi nghiệp vụ trong cơ sở dữ liệu. Log phục vụ điều tra, không phải nguồn duy nhất để quyết định giao hàng hay cộng số dư.
Hãy chọn một đơn thử nghiệm, liệt kê mọi nơi dữ liệu đi qua rồi kiểm tra từng bản ghi. Chuẩn hóa danh sách trường được phép trước, sau đó bổ sung kiểm thử chống lộ bí mật và chống xử lý trùng. Nếu cần hỗ trợ rà soát phần tích hợp, bạn có thể trao đổi với sieuthicode.com về phạm vi công việc và xác nhận khả năng hỗ trợ trước khi lựa chọn.
