クレジットカード番号の検証と聞くと、不正なカードを弾く仕組みを想像するかもしれませんが、実際の役目はもっと地味です。打ち間違いを早い段階で見つけ、利用者にその場で知らせること。これが検証の中心的な仕事です。この記事では、検証が防げるものと防げないものを整理し、実装の順序と、利用者に見える文言の作り方を説明します。
検証が防いでいるもの
決済の入力欄に数字が打ち込まれるとき、誤りの種類はおおよそ決まっています。桁を 1 つ打ち忘れる。隣り合う数字を入れ替える。似た数字を取り違える。あるいは、まったく別の番号を打ち込む。検証が対象にするのは、このうち機械的に判定できる範囲です。
桁数と文字種の確認は、明らかに形が崩れた入力を弾きます。チェックディジットの計算は、桁数が合っていても数字が 1 つずれている場合を多く検出します。ここまでで、単純な打ち間違いの相当な部分が手前で止まります。決済事業者に問い合わせるまでもなく誤りが返るため、利用者は待たされず、事業者側の無駄な試行も減ります。
検証で防げないもの
一方で、検証を通過したことが、その番号が実在することや、正当な持ち主のものであることを意味しません。チェックディジットの計算方法は公開されているので、条件を満たす番号は誰でも作れます。
残高が足りるかどうか、利用が停止されていないか、その番号が本当に顧客のものか。これらはすべて発行会社への照会でしか分かりません。検証は「入力の形」を扱う仕組みであり、「取引の可否」を扱う仕組みではないと理解しておくことが重要です。この境界を曖昧にしたまま設計すると、検証を通った入力に対して誤った信用を与えることになります。
検証はどの順序で行うべきですか？
順序には理由があります。もっとも安く、もっとも確実に判定できるものから始めます。
- 値の正規化 — 前後の空白を取り除き、数字以外の文字を除去します。
- 空かどうかの確認 — 未入力は他のどの検査よりも先に返すべき状態です。
- 文字種の確認 — 数字だけで構成されているかを確かめます。
- 桁数の範囲の確認 — 許容される最短と最長の間に収まるかを見ます。
- 接頭辞の確認 — 対応するブランドが判別できるかを調べます。
- チェックディジットの計算 — 最後に検算を行います。
この順序を守ると、無駄な計算が減るだけでなく、返すべきエラーの種類が安定します。逆に計算を最初に行うと、空文字や記号に対して例外が起き、利用者には無関係な文言が出ます。
よくある実装の落とし穴
現場で繰り返し見られる問題を挙げます。
- 16 桁だけを正解として扱い、13 桁や 15 桁の番号を拒否する。桁数は範囲で判定してください。
- 空白やハイフンを除去せずに桁を数え、貼り付け入力を誤って拒否する。
- 全角の数字を変換せずに弾く。日本語環境では実際に起こります。
- ブランドの判定を桁数より先に行い、短すぎる入力で誤ったブランド名を表示する。
- チェックディジットの計算で 2 倍した結果を 1 桁に畳み忘れ、正しい番号を拒否する。
- 検証エラーの文言に内部の用語をそのまま出し、利用者に意味が伝わらない。
いずれも、正常系のテストだけでは見つかりません。壊れた入力を意図的に用意する作業が欠かせません。
利用者にはどう伝えるべきか？
エラーの伝え方は、検証の実装と同じくらい重要です。まず、問題のある欄の近くに表示します。画面上部にまとめて出すと、どの欄を直せばよいか分かりません。次に、何が問題なのかを具体的に伝えます。「無効な入力です」ではなく、桁数が足りないのか、対応していないブランドなのかを書き分けます。
ただし、すべてを正直に伝えればよいわけではありません。どの接頭辞が対応範囲かに触れると、攻撃の手がかりを与える場面があります。表示の方針は、使いやすさと守りの強さの両方を見て決めてください。原則として、利用者が自分で直せる情報は伝え、直せない情報は伝えない、という線引きが分かりやすい基準になります。
| 入力の状態 | 伝えるべき内容 |
|---|---|
| 未入力 | 入力が必要であること |
| 桁数が足りない | 何桁必要なのか |
| 数字以外を含む | 数字のみを受け付けること |
| チェックディジット不一致 | 番号を見直すよう促す |
| 未対応の接頭辞 | 対応していない旨を一般的に伝える |
開発者向け: フロントだけに頼らない検証の組み立て
もっとも多い誤解は、ブラウザ側の検証をそのまま信頼してしまうことです。画面の検証は、利用者の待ち時間を短くするためのものであり、回避は容易です。必ずサーバー側でも同じ検査を行い、最終的な判断はサーバーが下す構成にしてください。
テストの組み立てでは、各段階に対応する入力を 1 件ずつ用意します。空、数字以外を含む、桁数不足、桁数超過、未対応の接頭辞、チェックディジット不一致、そして正しい番号。これだけ揃えば、順序の誤りや判定漏れのほとんどを検出できます。加えて、区切り記号を含む入力と、前後に空白がある入力も加えておきましょう。
もう一点、検証の結果を 1 つの真偽値で返さないことを勧めます。どこで失敗したかが分かる形で返しておけば、利用者向けの文言を出し分けられ、テストの期待値も書きやすくなります。検証を通る番号を自分で作ることもできますが、それは構造として妥当なだけで、実際には発行されていない値です。実在のカードと取り違えないよう、テスト専用の置き場所で管理してください。手元で検証用の番号が必要なときは テスト用クレジットカード番号生成 を、検算の仕組みそのものは Luhn アルゴリズム を参照してください。桁数の扱いについては カード番号の構成 で詳しく説明しています。
次のステップ
自社のフォームに、上に挙げた 9 種類の入力を順に流し込み、それぞれで表示される文言を書き出してみてください。文言が同じ場所に留まっているか、原因が具体的に伝わるかを確認できれば、検証の実装と案内の両方が整っていると判断できます。あわせて、サーバー側だけを直接呼び出したときに同じ検査が働くかを確かめておきましょう。