Kiểm tra số thẻ tín dụng là đoạn xử lý ngắn nhất trong toàn bộ luồng thanh toán, và cũng là đoạn bị viết lại nhiều lần nhất. Vấn đề hiếm khi nằm ở thuật toán, mà nằm ở thứ tự các bước và ở cách hệ thống phản hồi khi người dùng gõ sai. Bài này đi vào ba câu hỏi thực tế: phép kiểm tra đang chặn cái gì, nên báo lỗi thế nào cho người dùng hiểu, và làm sao để không tự lừa mình bằng một lớp kiểm tra chỉ chạy trên trình duyệt.
Phép kiểm tra này thực chất đang chặn điều gì?
Có một hiểu nhầm phổ biến rằng kiểm tra số thẻ là để phát hiện gian lận. Thực tế không phải vậy và cũng không thể như vậy. Mục tiêu duy nhất của nó là chặn lỗi gõ và những dãy số vô nghĩa, để người dùng nhận được phản hồi ngay lập tức thay vì phải chờ một vòng gửi yêu cầu đi và về.
Hãy hình dung luồng thanh toán như một hàng rào nhiều lớp. Lớp ngoài cùng là những kiểm tra rẻ tiền, chạy ngay trên thiết bị của người dùng: dữ liệu có phải toàn chữ số, độ dài có hợp lý, tiền tố có ứng với một mạng thẻ đã biết, và chữ số kiểm tra có khớp. Lớp trong cùng mới là những kiểm tra đắt tiền do hệ thống thanh toán và ngân hàng phát hành thực hiện.
Lớp ngoài cùng không có giá trị bảo mật, vì bất kỳ ai cũng có thể vượt qua nó bằng cách tính đúng chữ số kiểm tra. Nhưng nó có giá trị trải nghiệm rất lớn, và đó là lý do nó tồn tại.
Nên báo lỗi cho người dùng như thế nào?
Đây là phần bị xem nhẹ nhất, nhưng lại là phần mà người dùng thật sự cảm nhận được. Một thông báo lỗi tốt giúp người dùng sửa đúng chỗ trong một lần; một thông báo lỗi chung chung khiến họ thử lại nhiều lần rồi bỏ đi.
Nguyên tắc đơn giản là mỗi bước kiểm tra nên có một thông báo riêng, mô tả đúng vấn đề mà bước đó phát hiện.
- Nếu ô nhập còn ký tự không phải chữ số, hãy nói rằng số thẻ chỉ gồm chữ số, thay vì nói chung là số thẻ không hợp lệ.
- Nếu số thẻ quá ngắn hoặc quá dài, hãy nói rằng số chữ số chưa đúng, vì đây là lỗi người dùng có thể tự đếm và sửa.
- Nếu tiền tố không ứng với mạng thẻ nào đã biết, hãy nói rằng chưa nhận diện được mạng thẻ, vì trong trường hợp này người dùng rất có thể đã gõ sai chữ số đầu.
- Nếu chữ số kiểm tra không khớp, hãy nói rằng số thẻ có vẻ bị gõ nhầm và đề nghị kiểm tra lại, chứ đừng khẳng định số thẻ là giả.
Cách viết cuối cùng này đặc biệt quan trọng về mặt thái độ. Một người dùng đang gõ đúng số thẻ của mình mà bị hệ thống nói rằng số thẻ không hợp lệ sẽ cảm thấy bị buộc tội. Trong khi đó, trên thực tế, gần như mọi trường hợp chữ số kiểm tra không khớp đều là lỗi gõ.
Có nên kiểm tra ngay khi người dùng đang gõ không?
Kiểm tra ngay khi người dùng đang gõ có thể gây khó chịu nếu làm sai cách. Nếu bạn hiển thị thông báo lỗi đỏ khi người dùng mới gõ được bốn chữ số đầu, bạn đang mắng họ vì một việc họ chưa làm xong.
Một cách xử lý cân bằng hơn là phân biệt giữa giai đoạn đang nhập và giai đoạn đã nhập xong. Trong lúc người dùng còn đang gõ, chỉ nên kiểm tra những thứ có thể xác nhận dương tính, chẳng hạn nhận diện mạng thẻ để hiển thị logo. Đến khi ô nhập mất tiêu điểm hoặc người dùng bấm gửi, mới thực hiện toàn bộ chuỗi kiểm tra và hiển thị thông báo lỗi.
Một chi tiết nhỏ nhưng đáng làm là hiển thị số chữ số đã nhập khi con số đó chưa đủ. Phản hồi dạng này mang tính thông tin chứ không mang tính phán xét, và người dùng sẽ tự biết mình còn thiếu bao nhiêu.
Kiểm tra ở phía máy khách có đủ không?
Không, và đây là sai lầm nguy hiểm nhất trong chủ đề này.
Mọi thứ chạy trên trình duyệt đều có thể bị bỏ qua. Một người dùng có hiểu biết chỉ cần tắt JavaScript, sửa yêu cầu gửi đi, hoặc gọi thẳng vào điểm cuối của hệ thống. Vì vậy, toàn bộ chuỗi kiểm tra ở phía máy khách phải được lặp lại ở phía máy chủ, và lớp ở phía máy chủ mới là lớp có hiệu lực.
Cách nghĩ đúng là coi lớp kiểm tra phía máy khách như một tiện ích cho người dùng, còn lớp phía máy chủ như một yêu cầu bắt buộc của hệ thống. Hai lớp này nên được viết độc lập với nhau, vì nếu bạn chia sẻ cùng một đoạn xử lý cho cả hai phía, một lỗi ở đó sẽ vô hiệu hóa cả hai lớp cùng lúc.
Dùng công cụ để tạo dữ liệu cho các ca kiểm thử
Muốn thử một phép kiểm tra số thẻ, bạn cần dữ liệu ở cả hai loại: những dãy số phải được chấp nhận và những dãy số phải bị từ chối. Trình tạo số thẻ tín dụng giả của trang này giúp bạn có ngay nhóm thứ nhất, đúng định dạng và hợp lệ theo phép kiểm tra chữ số; còn nhóm thứ hai thì bạn tự tạo bằng cách sửa đúng một chữ số trong một số đã có, hoặc cắt bớt một chữ số, hoặc đổi tiền tố sang một dải không tồn tại.
Mọi số thẻ do công cụ tạo ra đều đúng cấu trúc nhưng chưa từng được phát hành, không gắn với tài khoản thật nào và không thể hoàn tất một giao dịch thanh toán. Chúng chỉ dùng cho kiểm thử phần mềm và trình diễn biểu mẫu.
Nếu bạn cần thử luồng thanh toán đầy đủ chứ không chỉ riêng phần kiểm tra số thẻ, hãy xem danh sách kiểm tra biểu mẫu thanh toán để biết những trường hợp nào cần phủ.
Phần dành cho nhà phát triển
Trình tự các bước quan trọng hơn bạn tưởng, vì mỗi bước loại bỏ một loại dữ liệu sai và cho phép bước sau giả định dữ liệu đã sạch.
Thứ tự hợp lý thường là:
- Loại bỏ khoảng trắng, dấu gạch nối và các ký tự phân cách khác.
- Kiểm tra rằng chuỗi còn lại chỉ gồm chữ số.
- Kiểm tra độ dài nằm trong khoảng hợp lệ của ngành.
- Kiểm tra tiền tố có ứng với một mạng thẻ đã biết.
- Tính chữ số kiểm tra và so khớp.
Nếu bạn đảo bước hai và bước năm, hàm tính chữ số kiểm tra sẽ phải xử lý những chuỗi chứa chữ cái và dấu câu, và bạn sẽ mất nhiều thời gian hơn để tìm ra nguyên nhân của những kết quả lạ.
Vài cạm bẫy khác đáng rà trước khi phát hành:
- Xử lý số thẻ như số nguyên. Nếu dữ liệu đi qua JSON, XML hoặc một bảng tính, số không ở đầu có thể bị cắt mất và dãy số lệch đi một vị trí. Luôn giữ số thẻ ở dạng chuỗi.
- Giới hạn độ dài quá chặt ở ô nhập liệu. Nếu ô nhập chỉ cho phép mười sáu ký tự, thẻ mười chín chữ số sẽ không thể gõ vào.
- Dùng chung một hàm cho cả nhận diện mạng thẻ và kiểm tra tính hợp lệ. Hai việc này có mục đích khác nhau, và khi gộp lại, bạn không thể trả về thông báo lỗi chính xác cho từng trường hợp.
- Không kiểm thử chính phép kiểm tra. Hãy viết ca khẳng định rằng số sai chữ số kiểm tra phải bị từ chối, số quá ngắn phải bị từ chối, và số chứa chữ cái phải bị từ chối. Một bộ kiểm tra chưa từng bị thử thách thì chưa thể tin được.
- Để lọt dữ liệu thử vào môi trường thật. Hãy đặt một hàng rào chặn theo tiền tố dành riêng cho thử nghiệm, để ngay cả khi cấu hình sai, không có yêu cầu thử nào đi tới hệ thống thật.
- Ghi nhật ký toàn bộ số thẻ. Nhật ký thường được đọc bởi nhiều người hơn bạn tưởng. Hãy che phần giữa của số thẻ trước khi ghi.
Cuối cùng, hãy nhớ rằng phép kiểm tra này chỉ phát hiện lỗi gõ. Nếu có ai đó trong nhóm hiểu nó là một cơ chế bảo vệ, hãy sửa lại hiểu nhầm đó trước khi nó dẫn tới một quyết định thiết kế sai.
Tiếp theo
Nếu bạn muốn hiểu vì sao chữ số kiểm tra được tính như vậy và nó bắt được những loại lỗi nào, hãy đọc bài về thuật toán Luhn. Còn nếu câu hỏi của bạn là nên dùng dữ liệu thử lấy từ đâu cho đúng quy định, bài dữ liệu thử theo chuẩn PCI DSS sẽ giải thích những ràng buộc áp dụng cho môi trường phát triển và kiểm thử.