Mở được checkout và mô phỏng một đơn thành công mới chứng minh đường đi cơ bản. Những lỗi gây mất công nhất thường xuất hiện khi khách đóng trang, IPN gửi lại, request timeout hoặc tác vụ sau thanh toán tạm dừng. Bộ thử cần đi đến dữ liệu và tác động cuối, thay vì chỉ chụp ảnh màn hình trả tiền.
Hướng dẫn trên hoadontudong.com.vn xây một kế hoạch test có thể dùng khi nghiệm thu với đội phát triển. Bắt đầu từ phạm vi API Pay2S, sau đó chọn đúng tài khoản, ngân hàng và cấu hình demo. Các điều kiện chi tiết được đối chiếu với tài liệu mô phỏng hiện hành.
Test cổng thanh toán tự động Pay2S bắt đầu từ đâu?
Trước hết, tách môi trường thử khỏi Production và ghi rõ mục tiêu: kiểm tra contract, kiểm tra nghiệp vụ hay nghiệm thu tích hợp. Một bài thử có thể đạt ở lớp request nhưng chưa chứng minh quyền sử dụng được cấp đúng. Mỗi mục tiêu cần dữ liệu đầu vào cùng bằng chứng kết thúc riêng.
Nên đọc cách hiểu môi trường sandbox Pay2S trước khi chuẩn bị. Đặt tên đơn để người trực nhận ra dữ liệu thử, dùng thông tin người mua giả và giữ một danh sách mã đơn theo từng kịch bản. Không dùng lại mã của hồ sơ thật cho tiện đối chiếu.
Với mỗi kịch bản, ghi cấu hình, bước thực hiện, kết quả mong đợi và kết quả quan sát. Chỉ dùng nhãn đạt khi kiểm tra đúng tầng cần nghiệm thu. Ví dụ, HTTP thành công ở create khác đơn đã được thanh toán; response mô phỏng thành công khác callback đã tới merchant.
Cũng cần biết điểm nào đang được giả lập. Nếu test dùng transport mô phỏng tại máy phát triển, nó không kiểm tra DNS hoặc endpoint công khai. Nếu test tạo đơn demo thật qua API, nó vẫn không phải giao dịch chuyển tiền thật giữa khách và tài khoản ngân hàng.
Test create và payUrl
Bộ thử create bắt đầu từ đơn đã lưu ở server: sản phẩm, số tiền và tham chiếu phải có nguồn. Xem luồng request và response để xác định dữ liệu cần giữ. Kiểm tra kết quả nghiệp vụ, lưu payUrl cùng thông tin trả về rồi mới chuyển khách.
Secret Key nằm tại backend và được lấy từ bộ khóa thử đúng phạm vi. Trong biên bản, ghi tên cấu hình hoặc phạm vi, không ghi giá trị bí mật. Những ảnh chụp hoặc log gửi cho người nghiệm thu phải được kiểm tra trước khi chia sẻ.
Test dữ liệu không hợp lệ bên cạnh đơn đúng: số tiền sai, trường thiếu, tài khoản nhận chưa phù hợp hoặc chữ ký bị sửa. Điều kiện đạt là lỗi được phân loại và không dẫn đến một đơn nội bộ tự đánh dấu đã trả. Không coi tất cả lỗi đều là mạng để thử lại vô hạn.
Thử khách mở lại link và thử ứng dụng chưa lưu được response. Dữ liệu phải cho biết lần gọi nào đã có kết quả và lần nào chưa xác định. Việc người dùng nhấn lại nút không được làm mất dấu yêu cầu trước đó.
Test simulate-payment và resendIpn
Theo API mô phỏng thanh toán demo, create phải trả environment là demo và đơn đáp ứng điều kiện tài khoản, ngân hàng. Request mô phỏng dùng Secret Key demo làm Bearer token, nhận orderId và cờ resendIpn; không chuyển tiền thật hoặc cho phép thay amount của đơn.
Luồng đầu tiên là tạo đơn demo rồi mô phỏng thanh toán với resendIpn=false. Tiếp theo đợi thông báo và kiểm tra merchant đã lưu kết quả. IPN gửi bất đồng bộ, nên test cần thời gian chờ phù hợp và bước kết thúc rõ; không đọc response mô phỏng rồi kết luận tác vụ nội bộ đã xong.
Sau khi lượt đầu hoàn tất, dùng resendIpn=true để kiểm tra nhận lại kết quả. Số đơn và tác vụ không được tăng thêm. Cờ này phục vụ thử callback, không phải cách retry thanh toán thông thường. Thời gian hoặc chữ ký của lượt gửi lại có thể khác, nên chống trùng phải dựa vào nghiệp vụ và định danh phù hợp.
Kiểm tra riêng các trường hợp không được phép mô phỏng: đơn không thuộc phạm vi, đơn đã hủy hoặc môi trường không đúng. Backend phải giữ lỗi rõ và không tạo một giao dịch độc lập để thay cho đơn không tìm thấy.
Test redirect và IPN
Thử IPN trước redirect, redirect trước IPN, chỉ có IPN và người dùng mở trang kết quả nhiều lần. Trạng thái cuối cần nhất quán trong database; trang kết quả không tự tạo giao hàng. Đây là cách kiểm tra ứng dụng có thực sự tách nguồn xác nhận khỏi trải nghiệm trình duyệt.
Đối chiếu thông báo hợp lệ theo contract IPN. Sau đó sửa một trường mà không tính lại chữ ký để kiểm tra từ chối. Với một chữ ký đúng nhưng số tiền không khớp, hệ thống phải giữ hồ sơ kiểm tra thay vì nới điều kiện nhận thanh toán.
Kiểm tra ACK từ phía ngoài, bao gồm HTTP status và body, sau khi database đã lưu. Một framework có thể trả trang lỗi HTML mà controller không dự kiến. Bài thử cần bắt được sự khác biệt này thay vì chỉ xác nhận endpoint có phản hồi.
Test cancel, timeout và duplicate
Không sử dụng Production để thử mô phỏng demo. Với cancel, chuẩn bị đơn pending riêng và kiểm tra kết quả hủy trực tiếp; không lấy một đơn đã trả rồi kỳ vọng endpoint hủy sẽ hoàn tiền. Test lại thao tác hủy để kiểm tra ứng dụng không chạy điều chỉnh nội bộ lần hai.
Với timeout create, giữ kết quả chưa xác định và mã đơn gốc. Test phải chứng minh ứng dụng có đường kiểm tra, không tự tạo mã mới hoặc báo thất bại vĩnh viễn chỉ vì chưa nhận response. Cho người hỗ trợ tra một hồ sơ này để xem dữ liệu có đủ dùng hay không.
Nếu tích hợp qua SDK, chạy fixture của gói và bài thử của ứng dụng theo hai nhóm riêng. Fixture kiểm tra thư viện không thay bộ thử transaction, quyền truy cập và tác vụ nghiệp vụ. Hướng dẫn vận hành chống trùng bổ sung các điểm kiểm tra ở backend.
Đưa hai thông báo hợp lệ tới gần cùng lúc và kiểm tra số lượng tác vụ. Test gửi lại tuần tự chưa chắc phát hiện được lỗi cạnh tranh giữa các worker. Kết quả cần nằm ở dữ liệu cuối, không chỉ ở hai status thành công.
Tiêu chí nghiệm thu Production
Ứng dụng dùng SDK vẫn cần điều kiện nghiệm thu nghiệp vụ: thanh toán đúng đơn, tác động một lần, dữ liệu sai không được chấp nhận và tác vụ lỗi có thể phục hồi. Cấu hình Production phải được xác nhận riêng, không suy từ việc môi trường demo đã chạy.
Nên có bảng điều kiện bắt buộc và mục cải tiến. Lỗi có thể làm giao hàng trùng hoặc xác nhận nhầm tiền cần được sửa trước triển khai. Những tiện ích chưa ảnh hưởng tính đúng có thể được lên kế hoạch sau, nhưng phải ghi rõ người chịu trách nhiệm và thời hạn.
Kế toán, vận hành và hỗ trợ khách hàng nên ký nhận những phần họ sử dụng. Đội kỹ thuật chứng minh contract và khả năng phục hồi; người nghiệp vụ kiểm tra số tiền, hồ sơ và cách xử lý ngoại lệ. Một biên bản chỉ có ảnh checkout sẽ thiếu phần này.
Ví dụ kỹ thuật an toàn cho Cổng thanh toán tự động Pay2S
Sơ đồ dưới là kế hoạch thử, không phải cú pháp gọi API đầy đủ. Secret Key được giữ trong cấu hình backend; mỗi lời gọi cần theo contract xác thực tương ứng.
Create demo → simulate-payment(false) → wait IPN
Create demo → simulate-payment(true) → verify idempotency
Cancel pending → verify cancelledHai dòng mô phỏng nên dùng dữ liệu đủ để đối chiếu lượt đầu và lượt gửi lại. Nhánh cancel dùng đơn pending riêng để không trộn mục tiêu test. Lưu bảng mã đơn cùng kết quả sẽ giúp chạy lại khi thay cấu hình hoặc phiên bản tích hợp.
Quy trình triển khai Cổng thanh toán tự động Pay2S
Chuẩn bị môi trường và bộ dữ liệu, test contract từng endpoint, rồi test hành trình nghiệp vụ. Giai đoạn UAT nên có người dùng thực hiện thao tác hỗ trợ và chốt kết quả. Họ cần tìm được đơn, hiểu trạng thái và biết bước tiếp theo mà không đọc log kỹ thuật.
Sau mỗi lỗi, xác định nguyên nhân thuộc dữ liệu, contract, cấu hình hay ứng dụng. Sửa đúng lớp rồi chạy lại phần liên quan, kèm bộ hồi quy cho tác động chéo. Không cần lặp toàn bộ bài thử đã ổn định khi thay đổi không ảnh hưởng chúng.
Câu hỏi thường gặp về Cổng thanh toán tự động Pay2S
Sandbox test được giao dịch thật không?
Mô phỏng demo không chuyển tiền thật. Nó phục vụ kiểm tra đơn và thông báo trong điều kiện demo; giao dịch thật cần kế hoạch kiểm tra phù hợp riêng.
Test resendIpn để làm gì?
Để chứng minh hệ thống nhận lại kết quả mà không tạo thêm giao hàng, quyền hoặc hóa đơn. Cần kiểm tra database và tác vụ, không chỉ việc endpoint trả thành công.
Có cần test browser đóng không?
Cần. Thanh toán và xử lý backend không được phụ thuộc khách giữ tab mở. Test này phát hiện việc xác nhận đang bị gắn nhầm vào redirect.
Khi nào được Production?
Khi điều kiện contract, nghiệp vụ, khả năng phục hồi và cấu hình triển khai đã được xác nhận. Demo thành công một lượt chưa đủ thay biên bản nghiệm thu.
Có thể test bằng Postman?
Có thể dùng công cụ để thử request, response và thông báo. Ở UAT, vẫn cần kiểm tra trong ứng dụng và tại database; một collection chạy được không chứng minh workflow đã đúng.
Kết luận
Bộ test có giá trị khi chỉ ra một khoản thanh toán đi đến đâu và có thể tiếp tục thế nào sau gián đoạn. Hãy giữ dữ liệu đối chứng, thử bản trùng và kiểm tra tác động cuối. Khi cần sửa tích hợp, chính bộ bằng chứng này giúp phân biệt cải tiến thật với việc chỉ làm màn hình thành công trở lại.
Đọc tiếp theo nhu cầu trong cụm Pay2S
- Pay2S là gì? Tổng quan giải pháp thanh toán trực tuyến tự động
- Pay2S là gì? API Pay2S hoạt động như thế nào trong hệ thống thanh toán
- Pay2S là gì? Pay2S có phải là cổng thanh toán không?
- Pay2S là gì? Luồng thanh toán từ lúc tạo đơn đến khi xác nhận
- Pay2S là gì? Pay2S hỗ trợ thanh toán QR và ngân hàng như thế nào?
Bộ tiêu chí nghiệm thu Cổng thanh toán tự động Pay2S
Trước khi ký nghiệm thu, chọn lại một đơn ở mỗi nhóm: thành công, chưa xác định, lỗi xác minh và đã hủy. Kiểm tra trạng thái, log đã che dữ liệu và đầu mối xử lý. Mỗi hồ sơ cần có kết quả hoặc một bước tiếp theo rõ ràng.
Thử làm lỗi một tác vụ sau thanh toán rồi phục hồi. Tiền đã xác nhận phải giữ nguyên; chỉ phần việc còn thiếu được chạy lại. Nếu phải đổi đơn về chưa trả để khởi động lại workflow, thiết kế cần được xem xét trước khi sử dụng rộng.
Bảng kiểm trước khi mở rộng Cổng thanh toán tự động Pay2S
Khi đưa vào Production, xác nhận lại tài khoản, bộ khóa, URL thông báo, quyền truy cập và cảnh báo. Lưu cấu hình đã kiểm tra để lần thay đổi sau có cơ sở so sánh. Bàn giao cách dừng tự động, kiểm tra khoản đang chờ và chuyển cấp khi chưa rõ kết quả.
Mở rộng theo nhóm đơn hoặc cửa hàng đã được thử, đồng thời theo dõi ngoại lệ trong giai đoạn đầu. Một bộ thử ngắn nhưng đại diện cho dữ liệu thật sẽ hữu ích hơn danh sách dài chỉ đi qua đường thành công.
