Danh sách kiểm tra QA

Thực hiện danh sách kiểm tra này trên môi trường sandbox, sau đó hoàn tất các bước kiểm tra production trước khi nhận thanh toán thật. Danh sách bao gồm kết quả thanh toán, xác minh, thử lại, cấu hình và bảo mật. Đánh dấu từng mục khi bạn đã xác minh.

1. Kết quả thanh toán

Thanh toán thành côngPO-1Thanh toán bằng 4242 4242 4242 4242. Phiên được truy xuất có paymentStatus: successful và đơn hàng được hoàn tất đúng một lần. Thẻ bị từ chốiPO-2Thanh toán bằng 4916 0184 7581 4056. Đơn hàng vẫn chưa được thanh toán, và việc thử lại bằng thẻ thành công vẫn hoạt động khi phiên còn mở. 3-D SecurePO-3Thanh toán bằng 4012 0018 0000 0016 và hoàn tất bước xác thực (challenge). Việc hoàn tất đơn hàng chờ trạng thái được truy xuất. Lỗi xử lýPO-4Dùng một thẻ thử nghiệm gây lỗi xử lý dành cho cổng thanh toán thử nghiệm. Đơn hàng vẫn chưa được thanh toán dù biểu mẫu thẻ đã chấp nhận thẻ. Trạng thái chưa xử lýPO-5Mã của bạn coi unpaid, failed, action_needed, cancelled và các giá trị không xác định là chưa thanh toán. Xem Trạng thái thanh toán.

2. Xác minh và hoàn tất đơn hàng

Kiểm tra phía máy chủVF-1Việc hoàn tất đơn hàng so sánh mã tham chiếu đơn hàng, số tiền, loại tiền tệ và paymentStatus với đơn hàng đã lưu, chứ không dựa vào dữ liệu từ lần chuyển hướng. URL thành công khi chưa thanh toánVF-2Truy cập trực tiếp URL thành công mà không thanh toán. Đơn hàng vẫn chưa được thanh toán. Liên kết hủyVF-3Mở liên kết hủy của Checkout. Đơn hàng vẫn chưa được thanh toán, và mã của bạn không mặc định trạng thái cancelled chỉ dựa vào việc điều hướng. Quay lại nhiều lầnVF-4Sau một lần thanh toán thành công, tải lại trang trả về hai lần. Đơn hàng được hoàn tất đúng một lần.

3. Thử lại và gián đoạn

Dùng một đơn hàng và phiên thử nghiệm mới cho mỗi tình huống độc lập. Với các bài kiểm thử thử lại, hãy dùng lại đơn hàng, phần thân yêu cầu và idempotency key ban đầu.

Mất phản hồi tạo phiênRI-1Bỏ qua phản hồi tạo phiên trong môi trường kiểm thử của bạn và lặp lại với cùng Idempotency-Key và phần thân. Phiên ban đầu được trả về lại và không có phiên thứ hai nào được tạo. Phần thân thay đổiRI-2Dùng lại một key với phần thân khác. API trả về HTTP 409 và mã của bạn không coi đó là một phiên mới. Khách hàng không quay lạiRI-3Thanh toán, sau đó đóng tab trước khi nó quay lại. Tác vụ đối soát của bạn truy xuất phiên đã lưu và ghi nhận khoản thanh toán đúng một lần. Hết thời gian chờ khi lấy trạng tháiRI-4Làm cho việc truy xuất bị hết thời gian chờ. Ứng dụng của bạn giữ ID phiên, để kết quả ở trạng thái chưa xác định và không tạo phiên thay thế. Phiên bị thay thếRI-6Tạo phiên thứ hai cho cùng một đơn hàng chưa thanh toán. URL đầu tiên báo expired và không thể nhận thanh toán. Sau khi đơn hàng đã được thanh toán, việc tạo thêm một phiên sẽ trả về HTTP 409. Phiên hết hạnRI-5Chờ quá expiresAt (30 phút) rồi mở lại URL. Không thể bắt đầu khoản thanh toán mới nào và đơn hàng vẫn chưa được thanh toán.

4. Cài đặt Checkout

Merchant đã được phê duyệtCS-1Mỗi merchant mà bạn nhận thanh toán thay đều có trong bảng Checkout merchants với trạng thái Ready. Đích trả vềCS-2URL thành công và URL hủy mặc định được đặt cho thông tin xác thực bạn dùng (mặc định của tổ chức cho Secret key, cài đặt của merchant cho key của merchant), dùng HTTPS, và origin chính xác của chúng nằm trong Allowed websites của thông tin xác thực đó. Ghi đè theo từng phiênCS-3Mọi successUrl hoặc cancelUrl bạn gửi đều khớp với một origin đã cấu hình. VíCS-4Apple Pay và Google Pay được bật hoặc tắt đúng như dự định. Google Pay ở chế độ chính thức đã được cấu hình Google Pay merchant ID. Ví trong thanh toán nhúngCS-6Tổng tiền trong ví khớp với đơn hàng trên máy chủ. Việc thay đổi giao hàng hoặc giảm giá sẽ cập nhật tổng tiền này. Việc hủy trong ví vẫn giữ checkout khả dụng, và các khoản thanh toán đang chờ xử lý sẽ chặn một lần trừ tiền khác. Thương hiệuCS-5Màu sắc và logo hiển thị đúng trong Checkout preview trên cả bố cục máy tính và di động.

5. Bảo mật

Key trên máy chủSE-1Checkout key của merchant hoặc Secret key của tổ chức chỉ nằm trong cấu hình máy chủ, không bao giờ nằm trong mã trình duyệt, gói ứng dụng hoặc hệ thống quản lý mã nguồn. Tổng tiền do máy chủ quản lýSE-2Số tiền, loại tiền tệ và ID đơn hàng lấy từ đơn hàng đã lưu của bạn, không bao giờ lấy từ trình duyệt. Endpoint thanh toán nhúngSE-3Nếu bạn dùng thanh toán nhúng, prepare và submit được gắn với một phiên checkout yêu cầu đăng nhập hoặc cookie HTTP-only có chữ ký, và origin của các yêu cầu làm thay đổi dữ liệu được kiểm tra. Chính sách bảo mật nội dung (CSP)SE-4Nếu bạn dùng thanh toán nhúng, CSP của bạn cho phép các origin script và frame của Tapaya, và các bước xác thực 3-D Secure vẫn hoạt động theo CSP đó.

6. Cấu hình sandbox

API sandboxPR-1TAPAYA_CHECKOUT_API_URL trỏ đến https://api.sandbox.tapaya.com. Key sandboxPR-2Tích hợp dùng checkout key sandbox của merchant hoặc Secret key của tổ chức, được tải từ cấu hình máy chủ. Tác vụ đối soátPR-3Tác vụ truy xuất các phiên chưa xác định kết quả đã được lên lịch trong môi trường kiểm thử của bạn.

7. Sẵn sàng cho production

Merchant sẵn sàngLV-1Merchant ở chế độ chính thức đã hoàn tất onboarding với thanh toán trực tuyến, được đơn vị xử lý thanh toán phê duyệt và có cổng thanh toán đã được cấu hình. Merchant ở trạng thái Ready trong Cài đặt Checkout. Thông tin xác thực chính thứcLV-2Máy chủ dùng thông tin xác thực production và https://api.tapaya.com. Các tích hợp SDK đặt TAPAYA_ENVIRONMENT=production. Key sandbox và thẻ thử nghiệm không được dùng cho thanh toán thật. Ví ở chế độ chính thứcLV-3Các tên miền cửa hàng cho Apple Pay đang ở trạng thái hoạt động. Google Pay ở chế độ chính thức đã được cấu hình merchant ID. Các ví được hỗ trợ hoàn tất được một khoản thanh toán và hoạt động trở lại sau khi bị hủy. Đối soát ở chế độ chính thứcLV-4URL trả về production, việc xác minh trên máy chủ, việc hoàn tất đơn hàng và tác vụ đối soát đều dùng cấu hình production. Trang này còn thiếu điều gì?Đề xuất tính năng. Chúng tôi sẽ đính kèm trang này để đội ngũ nắm được bối cảnh.