Trình tạo số thẻ tín dụng là công cụ sinh ra những dãy số có hình dạng của một số thẻ hợp lệ về mặt cấu trúc, để bạn thử biểu mẫu thanh toán, thử các phép kiểm tra nhập liệu và thử luồng xử lý đơn hàng mà không phải dùng tới bất kỳ con số nào thuộc về một thẻ thật. Giá trị của công cụ này nằm ở ba chỗ: số sinh ra phải đúng độ dài của tổ chức phát hành tương ứng, tiền tố phải thuộc một dải được cấp thật, và chữ số cuối phải qua được phép kiểm tra mà hệ thống của bạn áp dụng. Đọc hết bài này, bạn sẽ hiểu tiền tố định danh nói lên điều gì, chữ số kiểm tra được tính để làm gì, vì sao mã bảo mật và ngày hết hạn phải đi cùng số thẻ, và ranh giới pháp lý nào khiến ngay cả môi trường thử cũng không được chứa số thẻ thật.
Số thẻ dùng cho kiểm thử khác gì số thẻ thật?
Sự khác biệt không nằm ở hình dạng mà ở nguồn gốc. Một số thẻ thật do một tổ chức tài chính cấp cho một khách hàng cụ thể, gắn với một tài khoản, một hạn mức và một chủ sở hữu. Một số thẻ dùng cho kiểm thử chỉ được dựng theo đúng quy tắc cấu trúc, không do tổ chức nào cấp, không gắn với tài khoản nào, và không có ai đứng sau nó.
Vì hình dạng giống nhau, cả hai loại đều đi qua được biểu mẫu thanh toán ở tầng kiểm tra định dạng. Điều đó không có nghĩa chúng tương đương. Một số thẻ dùng cho kiểm thử sẽ bị hệ thống thanh toán thật từ chối ở tầng xác thực với ngân hàng phát hành, và đúng như vậy, bởi mục đích của nó chỉ là cho bạn một đầu vào hợp lệ về hình thức.
Điểm cần nhớ là đừng bao giờ dùng số thẻ thật trong môi trường thử, kể cả khi bạn có quyền truy cập vào nó. Môi trường thử thường được sao chép, xuất ra tệp, chia sẻ cho đối tác và chụp màn hình trong báo cáo lỗi. Một dãy số thẻ thật một khi đã nằm trong đó sẽ lan ra ngoài tầm kiểm soát, và hậu quả không chỉ là vấn đề kỹ thuật. Bài dữ liệu thử và PCI DSS trình bày những ràng buộc cụ thể của bối cảnh này.
Tiền tố định danh nói lên điều gì về tổ chức phát hành?
Những chữ số đầu tiên của một số thẻ tạo thành tiền tố định danh, thường được gọi là mã định danh tổ chức phát hành. Tiền tố này xác định mạng lưới thanh toán mà thẻ thuộc về, và trong một số dải còn xác định cả loại sản phẩm, chẳng hạn thẻ ghi nợ hay thẻ tín dụng, thẻ cá nhân hay thẻ doanh nghiệp. Phần còn lại của số thẻ do tổ chức phát hành tự phân bổ cho từng khách hàng.
Độ dài số thẻ không giống nhau giữa các mạng lưới và giữa các sản phẩm. Có dãy dài mười lăm chữ số, có dãy dài mười sáu chữ số, và một số ít sản phẩm dùng độ dài khác. Vì vậy, đừng viết một phép kiểm tra cho rằng mọi số thẻ đều dài đúng mười sáu chữ số, và cũng đừng giả định rằng độ dài là cố định trong cùng một mạng lưới. Bài cấu trúc số thẻ đi qua từng phần của dãy số và những biến thể độ dài cần chấp nhận.
Kiến thức về tiền tố cũng hữu ích khi bạn muốn kiểm tra giao diện hiển thị. Rất nhiều biểu mẫu hiện biểu tượng của mạng lưới thanh toán ngay khi người dùng gõ những chữ số đầu, và biểu tượng đó phải đổi đúng lúc. Hãy chuẩn bị ca gõ từng chữ số một và ca dán cả dãy số, vì hai đường nhập này có thể kích hoạt hai đường xử lý khác nhau trong mã nguồn của bạn.
Chữ số kiểm tra Luhn có ý nghĩa gì?
Chữ số cuối của phần lớn số thẻ được tính bằng một thuật toán kiểm tra, thường được gọi là Luhn. Thuật toán này không bảo mật và không chứng minh rằng thẻ tồn tại. Nó chỉ dùng để phát hiện lỗi gõ, ví dụ khi người dùng nhập nhầm một chữ số hoặc đảo hai chữ số liền nhau. Một dãy số bị gõ sai sẽ không qua được phép kiểm tra này, và biểu mẫu có thể báo lỗi trước khi gửi yêu cầu tới cổng thanh toán.
Cách thuật toán hoạt động có thể mô tả bằng lời. Nó duyệt các chữ số từ phải sang trái, nhân đôi mỗi chữ số ở vị trí lẻ, nếu kết quả lớn hơn chín thì trừ đi chín, rồi cộng tất cả lại. Dãy số hợp lệ khi tổng thu được chia hết cho mười. Chữ số kiểm tra chính là chữ số được chọn để tổng đó tròn. Bài thuật toán Luhn có phần giải thích chi tiết hơn cùng những ví dụ không chứa số thẻ thật.
Điểm quan trọng với người viết kiểm thử là chữ số kiểm tra phải được tính theo đúng thuật toán mà hệ thống của bạn dùng ở tầng máy khách và ở tầng máy chủ. Nếu chỉ một trong hai tầng kiểm tra chữ số này, bạn sẽ có một lớp trạng thái trung gian rất dễ sinh lỗi: giao diện báo lỗi nhưng yêu cầu vẫn được gửi đi, hoặc ngược lại. Hãy thử cả hai đường và xác nhận rằng hai tầng cho cùng kết quả. Bài tổng quan về thuật toán chữ số kiểm tra đặt Luhn cạnh các thuật toán kiểm tra khác để bạn thấy điểm chung của họ thuật toán loại này.
Vì sao mã bảo mật và ngày hết hạn phải khớp với số thẻ?
Trong một bản ghi dùng cho kiểm thử, số thẻ không đứng một mình. Nó đi kèm mã bảo mật gồm ba hoặc bốn chữ số, ngày hết hạn gồm tháng và năm, và thường thêm tên chủ thẻ cùng địa chỉ thanh toán. Bốn nhóm này tạo thành một khối, và hệ thống của bạn cần được thử với khối đó chứ không chỉ với từng trường riêng lẻ.
Mã bảo mật là trường có quy tắc độ dài khác nhau giữa các mạng lưới. Một số mạng lưới dùng ba chữ số, một số dùng bốn chữ số, và biểu mẫu tốt phải chấp nhận cả hai tùy theo mạng lưới đã được suy ra từ tiền tố. Nếu biểu mẫu của bạn cố định ba chữ số, người dùng có thẻ bốn chữ số sẽ không thể nhập đúng. Bài mã bảo mật được giải thích bàn về chi tiết này và về việc vì sao mã bảo mật tuyệt đối không được lưu lại sau khi xử lý.
Ngày hết hạn là trường mà các ca biên quan trọng hơn ca thường. Hãy thử tháng mười hai sang tháng một để kiểm tra phép chuyển năm, thử thẻ hết hạn trong tháng hiện tại, thử thẻ hết hạn vào tháng sau, và thử định dạng nhập tháng và năm bị đảo. Bài ngày hết hạn của thẻ mở rộng danh sách này, trong đó điểm đáng chú ý là cách xử lý múi giờ có thể làm lệch kết quả khi tháng chuyển giao.
Các cổng thanh toán cung cấp bộ thẻ thử nào?
Phần lớn cổng thanh toán lớn đều công bố một bộ số thẻ dùng riêng cho môi trường thử, mỗi số tương ứng với một tình huống cụ thể như giao dịch thành công, giao dịch bị từ chối, yêu cầu xác thực thêm, hoặc lỗi ở tầng xử lý. Bộ này là công cụ chính thức của nhà cung cấp, nên khi bạn cần thử một hành vi cụ thể của cổng thanh toán, hãy dùng đúng con số mà họ chỉ định thay vì tự sinh.
Lý do rất thực tế: cổng thanh toán quan tâm tới giá trị đặc biệt của từng số thử, chứ không chỉ quan tâm tới việc dãy số có qua được phép kiểm tra hay không. Một số dùng cho kiểm thử sinh ngẫu nhiên có thể hợp lệ về cấu trúc nhưng lại không kích hoạt được hành vi mà bạn muốn thử. Bài bộ thẻ thử theo mạng lưới và bài thẻ thử của Stripe tổng hợp cách phân loại này.
Với một số thẻ do công cụ sinh ra, giá trị nằm ở chỗ khác: chúng dùng để thử biểu mẫu, thử phép kiểm tra định dạng, thử luồng lưu trữ và hiển thị, và thử số lượng lớn. Hãy phân biệt hai mục đích này trong bộ kiểm thử của bạn, vì trộn chúng vào nhau sẽ khiến bạn kết luận sai về nguyên nhân thất bại.
PCI DSS đặt ra ranh giới gì cho môi trường thử?
Chuẩn bảo mật dữ liệu ngành thẻ thanh toán đặt ra những yêu cầu áp dụng cho mọi nơi dữ liệu thẻ được lưu, xử lý hoặc truyền đi, và môi trường thử không được miễn trừ chỉ vì nó không phục vụ khách hàng thật. Nếu môi trường thử của bạn chứa số thẻ thật, nó nằm trong phạm vi áp dụng, và bạn phải đáp ứng các yêu cầu về lưu trữ, mã hóa, kiểm soát truy cập và ghi nhật ký.
Nói cách khác, ranh giới an toàn và cũng là ranh giới đơn giản nhất là không để số thẻ thật đi vào môi trường thử ngay từ đầu. Hãy dùng số do công cụ sinh ra hoặc số thử do cổng thanh toán cấp, và biến điều đó thành một quy tắc có thể kiểm tra tự động, chẳng hạn một phép kiểm tra trong đường ống phát hành chặn mọi dãy số có hình dạng số thẻ trong mã nguồn và trong tệp cấu hình.
Một điểm nữa là mã bảo mật. Kể cả trong môi trường thử, mã bảo mật không nên được lưu lại sau khi xử lý xong, và nhật ký không nên ghi lại toàn bộ dãy số. Nếu bạn cần ghi lại để truy nguyên, hãy ghi bốn chữ số cuối cùng và một mã định danh giao dịch, đủ để đối chiếu mà không tạo ra thêm một bản sao của dữ liệu nhạy cảm.
Cần kiểm thử những gì trên biểu mẫu thanh toán?
Hãy bắt đầu với định dạng nhập. Người dùng có thể gõ số liền một mạch, gõ theo nhóm có dấu cách, dán kèm dấu gạch nối, hoặc dán kèm cả ký tự thừa ở đầu và cuối. Biểu mẫu nên chuẩn hóa những dạng này về cùng một giá trị trước khi kiểm tra, và không nên từ chối chỉ vì người dùng có dấu cách. Đây là trường hợp mà việc chuẩn hóa khác với việc xác thực, chủ đề được bàn trong bài chuẩn hóa và xác thực dữ liệu số.
Tiếp theo là các ca biên về độ dài và giá trị. Hãy thử dãy ngắn hơn độ dài tối thiểu, dãy dài hơn độ dài tối đa, dãy có chữ số kiểm tra sai, dãy có chữ cái lẫn vào, và trường để trống. Với mỗi ca, hãy xác nhận thông báo lỗi xuất hiện ở đúng trường và bằng ngôn ngữ mà người dùng hiểu, thay vì một thông báo chung chung.
Sau đó là các ca về trạng thái giao diện. Hãy thử nhập số của mạng lưới này rồi sửa thành số của mạng lưới khác để xem biểu tượng và quy tắc độ dài mã bảo mật có cập nhật đúng hay không. Hãy thử gửi biểu mẫu hai lần thật nhanh để xem nút gửi có bị khóa trong lúc chờ hay không, vì đây là lỗi tạo ra giao dịch trùng.
Cuối cùng là các ca về lưu trữ và hiển thị. Hãy xác nhận rằng giao diện chỉ hiển thị bốn chữ số cuối, rằng nhật ký không chứa dãy số đầy đủ, và rằng môi trường thử không lưu mã bảo mật sau khi xử lý. Bài danh sách kiểm tra biểu mẫu thanh toán gom tất cả những mục này thành một quy trình có thứ tự.
Bước tiếp theo
Hãy mở trình tạo số thẻ, sinh vài dãy số cho những mạng lưới khác nhau, rồi kiểm tra xem chúng có đúng độ dài và qua được phép kiểm tra chữ số của hệ thống bạn hay không. Sau đó dùng chính những ca biên ở trên để thử biểu mẫu thanh toán trên môi trường thử, và ghi lại kỳ vọng của bạn cho từng ca trước khi viết phép kiểm tra tự động.
Toàn bộ dữ liệu do trang này sinh ra là dữ liệu kiểm thử tổng hợp: các dãy số đúng cấu trúc và đúng chữ số kiểm tra, nhưng không thuộc về thẻ nào, tài khoản nào hay người nào có thật, không dùng được trong giao dịch thật, và chỉ nên dùng cho việc thử phần mềm, thử biểu mẫu và trình diễn giao diện.