クレジットカードチェックサム検証

テスト用のカード番号がLuhn(ルン)チェックと対象桁数に適合するかを確認し,先頭数字から6ブランドの候補を推定します.実際のカードの発行・利用・決済可否は判定しません.

読み込み中...

ZeroToolsのブラウザ内処理とプライバシー

ZeroToolsは,入力内容を端末内で処理するツールを中心に提供しています.各ツールの対応範囲と制限を確認して利用してください.

データの取り扱い・プライバシー方針
第1章

このツールが確認できる範囲

このクレジットカードチェックサム検証ツールは,入力した数字列が特定の書式規則に適合するかを確認するためのユーティリティです.確認するのは,Luhn(ルン)チェックサム,実装上の対象桁数,先頭数字から推定するカードブランド候補の三項目です.

画面に「書式一致」や「Luhn適合」と表示されても,その番号が実際に発行されたカードであることや,現在利用できることを意味しません.名義,有効期限,セキュリティコード,利用可能枠,残高,不正利用,決済可否は確認しません.カード会社,決済代行事業者,金融機関のシステムへ照会する機能もありません.

実際の決済では,番号の書式以外にも複数の認証・承認処理が行われます.このツールはその代替ではなく,開発中の入力フォームやテストデータについて,明らかな桁数違い,チェックサム不一致,実装済みプレフィックスとの不一致を見つけるための補助として使用してください.

三つの表示は互いに別の条件です.Luhnへ適合しても対象桁数とは限らず,ブランド候補が表示されてもLuhnへ適合するとは限りません.総合的な「書式一致」はLuhnと桁数がともに適合した場合だけ表示されますが,ブランド候補の正確性やカードの状態を追加確認するものではありません.

第2章

Luhnアルゴリズムの計算手順

入力欄へ文字を入れると,最初に空白やハイフンなど数字以外の文字を除去し,最大19桁までを処理対象にします.画面上では読みやすいようにスペースを挿入しますが,Luhn計算には数字だけを使用します.12桁未満の入力は判定対象外として不適合になります.

Luhn計算では,数字列の右端から左へ一桁ずつ読み取ります.右端を1番目としたときの2番目,4番目,6番目という交互の位置にある数字を2倍します.2倍した結果が9を超えた場合は,その値から9を引きます.それ以外の位置の数字はそのまま使います.

例えば元の数字が8なら2倍後は16となり,9を引いて7として加算します.これは16の十の位と一の位を足す処理と同じ結果です.どの位置を2倍するかは数字列の右端から数えるため,先頭から固定の奇数・偶数位置を選ぶ方法ではありません.空白を含む表示文字列ではなく,数字以外を除去した後の列に対して位置を数えます.

変換後の全数字を加算し,総和が10で割り切れれば「Luhn適合」,割り切れなければ「Luhn不適合」と表示します.この方法は入力誤りの一部を見つけるチェックサムで,暗号化,電子署名,発行元への照会ではありません.規則を知っていれば適合する数字列を作れるため,適合結果だけから真正性を判断することはできません.

第3章

6ブランド候補と桁数の実装範囲

ブランド候補は,入力された数字列がツール内の正規表現へ一致するかを上から順番に確認して推定します.現在表示できる候補はVisa,Mastercard,American Express,JCB,Diners Club,Discoverの6種類です.

Visaは先頭が4で,13・16・19桁を対象とします.Mastercardは先頭が51〜55または2221〜2720に入る実装規則で,16桁を対象とします.American Expressは34または37で始まる15桁です.JCBは実装上3528〜3589に相当する先頭規則と16〜19桁を使用します.

Diners Clubは300〜305,3095,36,38,39で始まる候補について14・16桁を対象とします.Discoverは6011,実装済みの622帯,644〜649,65などで始まる候補について16〜19桁を対象とします.どの先頭規則にも一致しない場合は「未識別 / 不明」と表示し,桁数は13〜19桁の範囲かだけを参考表示します.

これらは現在のソースコードに静的に記録した限定的な規則です.全カードブランド,全IIN/BIN,今後追加・変更される番号帯を網羅しません.表示されるブランド名も候補であり,個別のカード発行会社や口座を特定するものではありません.

ブランド候補は入力の途中でも先頭規則に一致した時点で変化します.そのため,入力途中の短い数字列にブランド名が表示されても,必要な桁数を満たしたという意味ではありません.逆に,ブランド候補が「未識別 / 不明」でも13〜19桁なら桁数欄だけが対象範囲になる場合があります.各欄を分けて確認してください.

第4章

判定結果と番号表示の読み方

数字が12桁以上になると,画面に「Luhnチェックサム検証」「桁数検証」「検出ブランド」の三項目を表示します.Luhn欄は計算結果に応じて「Luhn適合」または「Luhn不適合」,桁数欄はブランド候補の対象桁数に一致するかに応じて「対象桁数」または「対象外」となります.

右側のバーチャルカードは判定結果を読みやすくする装飾的なプレビューです.American Express候補は4-6-5,14桁のDiners Club候補は4-6-4,それ以外は原則として4桁ごとにスペースを入れます.未入力部分の点や背景色,チップの図柄は表示用で,実カードの外観や発行状態を再現するものではありません.

総合バッジはLuhnと桁数の両方が適合した場合に「書式一致」,どちらかが適合しない場合に「書式不一致」と表示します.カード下部の「FORMAT ONLY」も,結果が書式チェックだけであることを示します.「書式一致」は決済システムの審査通過,カードの有効性,本人確認を表しません.

入力欄は最大19桁まで受け付け,数字以外を取り除いてから整形します.数字を消すとプレビューの残り部分は点で補われます.これは入力状況を示すための表示で,点を含む文字列を検証したり,カード番号を生成したりする処理ではありません.クリアボタンを押すと入力値と判定表示を初期状態へ戻します.

第5章

入力値の保持と通信・保存の範囲

入力値は数字以外を除去して最大19桁にし,ブラウザ内のReact stateへ保持します.文字が変わるたびに同じコンポーネント内でLuhn,桁数,ブランド候補を再計算し,結果を画面へ反映します.この検証コンポーネントには,入力番号を決済APIや独自サーバーへ送信する処理,データベースやLocalStorageへ保存する処理はありません.

ただし,計算が終わった直後に入力値が消えるわけではありません.「クリア」を押す,別ページへ移動する,またはページを再読み込みするまでReact stateに残ります.ブラウザのメモリ消去時点を指定したり,ガベージコレクションを強制したりする機能はありません.

また,これはページ内の検証コンポーネントの処理範囲を説明するもので,Webサイト全体の通信が存在しないという意味ではありません.このページはPCI DSSの監査・認証を示すものではなく,カード情報を安全に保管する仕組み,トークン化,暗号化,アクセス制御を提供しません.実際のカード番号を入力しないことが最も重要です.

第6章

テスト番号を使った確認方法

このツールで書式を試す場合は,自分や他人の実在するカード番号ではなく,カードブランドや決済事業者が開発者向けに公開しているテスト番号を使用してください.テスト番号を選ぶ際は,利用している決済サービスの公式開発者資料とテスト環境を確認し,本番環境の認証情報や実データと混ぜないようにします.

例えば入力フォームの開発では,Luhnに適合する対象桁数,チェックデジットを変えた不適合番号,対象より一桁短い番号,実装していない先頭規則を持つ番号などを用意すると,画面の分岐を確認できます.本ツールのブランド候補と,実際に開発している決済サービスの対応ブランド・番号帯が同じとは限らないため,最終的な受入条件は決済サービス側の資料とテスト結果を基準にしてください.

テストでは一つの「書式一致」だけを見るのではなく,Luhnだけが不適合,桁数だけが対象外,ブランド候補が未識別,入力途中,数字以外を含む貼り付け,19桁を超える入力といった分岐も分けて確認します.この画面は判定ロジックを学ぶ補助にはなりますが,利用中の決済SDKやバックエンドの検証結果を再現するテスト環境ではありません.

フロントエンドでLuhnや桁数を確認すると,入力ミスを早めに案内できます.しかし,正規の決済オーソリゼーション,3-Dセキュア等の本人認証,不正利用判定を置き換えるものではありません.ここでの結果はテストデータの書式確認に限定し,実運用の可否判断には使用しないでください.

よくある質問(FAQ)

A.
いいえ.Luhn適合は入力文字列がチェックサム規則を満たすことだけを示します.発行済みか,現在利用可能か,名義・期限・残高・セキュリティコード,決済可否は確認しません.
A.
Visa,Mastercard,American Express,JCB,Diners Club,Discoverの6候補を,実装済みの先頭数字と桁数規則から推定します.全ブランドや最新の識別番号範囲を網羅せず,発行会社も特定しません.
A.
実カード番号の入力は推奨しません.書式検証や開発時の確認には,カードブランドや決済事業者が開発者向けに公開しているテスト番号を使用してください.
A.
この検証コンポーネントには入力番号をAPIへ送信したり永続保存したりする処理はありません.値はクリア,移動,再読み込みまでブラウザのReact stateに残ります.ページ全体の通信ゼロやPCI DSS準拠を保証するものではありません.