MoMo hay ZaloPay cho website bán hàng: so từ checkout tới hoàn tiền

Khách thấy trang thành công, kho vẫn thấy đơn chờ

Đây là tình huống đáng đem vào buổi so MoMo và ZaloPay hơn câu hỏi ví nào phổ biến. Trình duyệt đã quay về nhưng callback có thể trễ; nhân viên không biết giữ hàng hay giao.

Cả hai hệ đều có tài liệu merchant cho tạo giao dịch, thông báo server và truy vấn. Lựa chọn nằm ở độ khớp với checkout, tệp khách, đội kỹ thuật và quy trình xử lý trạng thái chưa rõ.

Test hành trình trên thiết bị khách thật

Mở website từ Zalo, Facebook, trình duyệt trong app và trình duyệt thường. Test khi đã cài ví, chưa cài, mạng yếu, bấm quay lại và hết thời gian. Đếm số bước cùng tỷ lệ hoàn tất, không chỉ nhìn màn hình đẹp.

Shop có tệp khách khác nhau nên kết quả không thể suy từ thị trường chung. Chạy A/B hoặc mở từng phương thức trong giai đoạn đủ đơn để đo.

IPN/callback là xương sống vận hành

MoMo dùng IPN trong luồng tài liệu; ZaloPay dùng callback. Với cả hai, server shop cần xác minh chữ ký/MAC, số tiền, mã đơn và trạng thái trước khi cập nhật.

Endpoint phải phản hồi đúng, ghi log đủ truy vết và chịu được retry. Không cho frontend giữ secret. Không tin dữ liệu khách gửi lên chỉ vì nó có order ID hợp lệ.

Query dự phòng ngăn đơn treo vô thời hạn

Mạng có thể làm callback không tới. Hệ thống nên có lịch query các đơn chờ theo giới hạn hợp lý, hoặc nút an toàn cho nhân viên kiểm lại.

Không query dồn dập; theo tài liệu rate/khuyến nghị và lưu kết quả. Khi trạng thái vẫn chưa rõ, đừng tự chuyển thành thất bại rồi yêu cầu khách trả lần nữa.

Hoàn tiền phải được test trước ngày có khách bực

MoMo có Refund API và query trạng thái; tài liệu ZaloPay mô tả hoàn bất đồng bộ và query kết quả. Cả hai cần test điều kiện, toàn phần/một phần, mã refund duy nhất và cách kết quả quay về hệ đơn.

Đo thời gian từ lúc shop bấm hoàn tới lúc khách nhận, ai theo dõi khoản pending và kế toán lấy phí/đối soát ở đâu. Đừng hứa “hoàn ngay” nếu luồng thực tế chưa được kiểm.

Portal, báo cáo và hỗ trợ mới lộ ra sau ngày khai trương

Cho vận hành và kế toán xem portal merchant: tìm giao dịch, lọc trạng thái, xuất file, phân quyền và lần refund. Hỏi SLA hỗ trợ lúc tiền đã trừ nhưng đơn chưa xác nhận.

Một API tốt nhưng portal khó dùng có thể đẩy mọi ticket cho dev. Một portal dễ dùng nhưng webhook thiếu quan sát lại làm đội kỹ thuật mệt. Chấm cả hai phía.

Bộ test chung

• Thanh toán thành công bình thường.
• Khách đóng tab trước return URL.
• Callback tới trễ và tới lặp.
• Sai số tiền hoặc order ID không tồn tại.
• Giao dịch hết hạn/chưa rõ trạng thái.
• Hoàn toàn phần và hoàn một phần.
• Xuất báo cáo đối soát cùng ngày.
• Thu hồi quyền một tài khoản vận hành.

Chọn bằng dữ liệu của shop

Nghiêng bên cho tỷ lệ hoàn tất tốt hơn trên tệp khách, trạng thái ít treo hơn, hoàn/đối soát rõ hơn và hỗ trợ vừa năng lực team. Nếu hai bên cùng có giá trị, bật cả hai nhưng giữ một model trạng thái chung.

Khách chỉ cần trả được lẹ. Shop cần biết tiền nào của đơn nào, khi nào được giao và lúc hoàn thì ai theo tới cuối. Bên làm trọn vòng đó ít câu hỏi hơn là bên đáng giữ.

Những câu shop hay hỏi