Cho người mua thanh toán trước rồi mới mời tham gia
Đặt tùy chọn thanh toán khách vãng lai (guest checkout) làm mặc định rõ ràng khi tài khoản không cần thiết để giao hàng. Hướng dẫn về biểu mẫu của Google khuyến nghị cách tiếp cận này. Giữ đăng nhập là đường dẫn phụ hiển thị rõ cho khách hàng quay lại, sau đó đề xuất tạo tài khoản sau khi xác nhận với lợi ích cụ thể như lịch sử đơn hàng. Nếu là sản phẩm bị điều tiết, yêu cầu thành viên hoặc chính sách chống gian lận bắt buộc phải đăng nhập, giải thích yêu cầu đó trước khi biểu mẫu bắt đầu.
Người mua mới có thể đến trang thanh toán mà không cần tạo mật khẩu khi chính sách cho phép.
Mời tạo tài khoản sau khi đặt hàng, không đặt làm rào cản trước khi thanh toán.
Giảm số trường nhưng không làm mơ hồ thông tin giao hàng
Yêu cầu thông tin chỉ khi nó thay đổi việc thực hiện đơn hàng, thanh toán, thuế hoặc liên lạc bắt buộc. Sử dụng điều khiển chuẩn, nhãn hiển thị, giá trị name và id ổn định, và các token autocomplete phù hợp. Cho phép địa chỉ thanh toán trùng với địa chỉ giao hàng theo mặc định khi đúng, đồng thời làm cho lựa chọn địa chỉ khác dễ chọn. W3C nói rằng thông tin đã nhập trong cùng một quy trình nên được tự động điền hoặc có thể lựa chọn, trừ một số trường hợp hạn chế như bảo mật hoặc dữ liệu không hợp lệ.
Mỗi trường nhập phải có mục đích vận hành; loại bỏ hoặc hoãn nếu không cần thiết.
Không dùng văn bản gợi ý biến mất làm nhãn duy nhất; giữ nhãn hiển thị trong khi nhập.
Biến lỗi thành các đường phục hồi
Xác thực các vấn đề cục bộ đơn giản khi nhập hoặc khi rời trường, mà không can thiệp vào mọi phím nhập. Dùng hướng dẫn sửa lỗi rõ ràng và giữ lại các mục không nhạy cảm an toàn sau khi có lỗi. Sau khi gửi không thành công, hiển thị tóm tắt lỗi có liên kết trước biểu mẫu và thông báo tương ứng tại từng trường. W3C khuyến nghị mỗi mục trong tóm tắt nên nêu rõ điều khiển, mô tả vấn đề và giải thích cách sửa. Giữ dữ liệu thanh toán ngoài URL, nhật ký và văn bản lỗi.
Nêu điều gì sai và cách sửa, thay vì chỉ dùng ‘Dữ liệu không hợp lệ.’
Di chuyển tiêu điểm đến điểm phục hồi và thông báo phản hồi động cho công nghệ hỗ trợ.
Cung cấp lựa chọn thanh toán mà không làm suy yếu kiểm soát trang thanh toán
Hiển thị các phương thức thanh toán mà doanh nghiệp có thể ủy quyền, hoàn tiền, đối soát và hỗ trợ. Gọi tên từng phương thức một cách rõ ràng và tiết lộ các điều kiện quan trọng trước khi cam kết. Kiểm tra một giao dịch thành công, một thanh toán bị từ chối và quy trình hoàn tiền hoặc hủy. Hướng dẫn của PCI SSC về e-skimming tập trung vào script được ủy quyền trên trang thanh toán, kiểm tra tính toàn vẹn và phát hiện thao túng. Trước khi thêm thẻ, widget, thử nghiệm, iframe hoặc điều khiển thẻ, tham vấn nhà cung cấp và người đánh giá bảo mật hoặc PCI có trình độ; bài viết này không phải là kết luận về tuân thủ.
Giữ danh mục tài sản và chủ sở hữu được phê duyệt cho các trang có thể ảnh hưởng đến thanh toán.
Một thay đổi nhỏ về giao diện có thể làm đổi mã thực thi trong trình duyệt trên trang thanh toán.
Làm cho luồng di động và truy cập được trở thành luồng chuẩn
Kiểm tra với bàn phím ảo mở trên khung nhìn hẹp. Sử dụng kiểu nhập phù hợp và, khi hữu ích, inputmode để gợi ý bàn phím ảo phù hợp; MDN lưu ý rằng inputmode không tự xác thực đầu vào. Với số thẻ, Google khuyến nghị dùng input kiểu text kết hợp inputmode numeric thay vì điều khiển number. Cung cấp nhãn liên kết hiển thị, thứ tự tiêu điểm bàn phím hợp lý, và dùng văn bản cùng màu sắc cho lỗi và lựa chọn. Các quét tự động một mình không thể xác nhận rằng thanh toán hoạt động với mọi công nghệ hỗ trợ.
Hoàn tất luồng bằng Tab, Shift+Tab, Enter, Space và Escape khi phù hợp.
Kiểm tra dữ liệu địa chỉ và thẻ lưu trong trình duyệt, bao gồm địa chỉ thanh toán khác biệt.
Giữ chi phí, giao hàng và cam kết luôn hiển thị
Giữ các mục, điều khiển số lượng, giảm giá, lựa chọn giao hàng, các khoản phí đã biết và tổng tiền hiển thị ở trang thanh toán. Khi phí vận chuyển, thuế hoặc khoản phí định kỳ phụ thuộc vào thông tin sau này, nói rõ phần nào là ước tính và cập nhật tóm tắt ngay khi biết chính xác. Khớp hành động đặt hàng với cam kết tài chính, ví dụ ‘Thanh toán và đặt hàng’. Cho phép người mua sửa mục, địa chỉ hoặc lựa chọn giao hàng mà không phải thoát khỏi quá trình thanh toán.
Giữ tóm tắt dễ đọc và có thể cập nhật ở mọi bước thanh toán.
Nêu rõ khi nào phí giao hàng, thuế, giảm giá hoặc khoản phí định kỳ trở nên cố định.
Thử nghiệm như một thay đổi độ tin cậy được kiểm soát
Thay đổi một điều có ý nghĩa theo giả thuyết đã viết, ví dụ chuyển việc tạo tài khoản sang sau khi xác nhận. Xác định đối tượng, phép đo hoàn thành và rào cản trước khi phát hành. Rào cản có thể bao gồm lỗi thanh toán, gửi không thành công, liên hệ hỗ trợ, hoàn tiền, suy giảm khả năng truy cập và vấn đề hiệu năng. Dùng SIU để kiểm thử đường dẫn mua hàng và các phụ thuộc, ghi lại kế hoạch quay lui và khôi phục phiên bản đã biết là tốt gần nhất nếu một rào cản bị vi phạm. Kết quả chuyển đổi không chứng minh được an ninh, khả năng truy cập, tuân thủ pháp lý hay phù hợp cho mọi đối tượng.
Ghi lại tỷ lệ hoàn thành từng bước hiện tại, các loại lỗi và hành vi kỹ thuật trước.
Quyết định mẫu thất bại nào sẽ tạm dừng hoặc đảo ngược phát hành.
