1 回の API 呼び出しで Luhn チェックを使用してクレジット カードを検証する
カード番号のタイプミスや偽造品が決済処理業者に届く前に捕らえます。 1 つの POST で、Luhn の有効性、ブランド (Visa、Mastercard、Amex)、クレジットまたはデビットが返されます。 無料枠、SDKなし。
カード番号の入力を間違えると、ユーザーには紛らわしい拒否メッセージが表示され、プロセッサーには 2 つのコストがかかります。 失敗した認証に対して料金を請求します。 彼らのほとんどは出発する前に捕まえることができます ブラウザ。 Luhn アルゴリズムは、すべての実際のカード番号が満たすチェックサムであるため、 失敗した場合は無効であることが保証され、Stripe または Adyen に到達する必要はありません。
このエンドポイントは Luhn チェックを実行し、1 つの POST でカード ブランドを検出します。 これが通話の全文です。
リクエスト
数値を文字列として送信します。 スペースとダッシュは自動的に削除されるため、
4111 1111 1111 1111 そして 4111-1111-1111-1111 どちらも機能します。 応答
次の 3 つのことを伝えます。
valid: Luhn チェックサムに合格するかどうか。brand: Visa、Mastercard、Amex、Discover、JCB、Diners Club、または UnionPay。type: 発行者識別番号からのクレジットまたはデビット。
Node.js でチェックアウト時に検証する
プロセッサに何かを送信する前に、エンドポイントを呼び出します。 Luhn チェックが失敗するとクリアが返されます エラーをユーザーに表示すれば、偽の番号にかかる認証手数料をスキップできます。
React フォームで不正な入力をブロックする
React Hook Form は送信前に非同期バリデータを実行するため、無効な数値によって
注文。 通話を直接ワイヤーで接続します register:
PCI スコープを小さくしてください。 最もリスクの低い設計では、ブラウザ内でカードをトークン化します。 プロセッサに依存し、ブランド ロゴの先頭の数字のみが検証されます。 フルで実行する キーストロークごとではなく、本当に必要なときにサーバー側の検証を行い、ログに記録することはありません。 完全な数字。
それが何をするのか、そして何を教えてくれないのか
Luhn の検証はフィルターであり、保証ではありません。 通過番号は整形式です。 それは証明されません カードが存在するか、資金が存在します。 プロセッサーを介した承認のみがそれを確認します。 使用する このエンドポイントは、明らかなガベージを安価に拒否し、カード ブランドの UI を駆動するために、 プロセッサが実際の充電を処理します。
クレジット カード バリデーターは、botoi 上の約 200 の単一目的エンドポイントの 1 つです。 IBAN と VAT 検証 残りの請求フローについては、 それらはすべて 5 つの API キーの背後にあります 要求/分は無料です。 で通話を試してください。 インタラクティブな遊び場 または接続します MCPサーバー クロードからのカードを検証します。
FAQ
- Luhn チェックは実際に何を証明するのでしょうか?
- Luhn アルゴリズムは、タイプミスやランダムに生成された偽物を検出するチェックサムです。 Luhn に不合格となった番号は無効であることが保証されているため、支払い処理業者に届く前に番号を拒否できます。 Luhn を通過する数字は整形式ですが、それはカードが存在する、または資金があることを意味するものではありません。 プロセッサーを介した承認のみがそれを確認します。 Luhn を使用して明らかなゴミを安価にフィルタリングし、実際の請求は Stripe または Adyen に任せます。
- API は送信したカード番号を保存または記録しますか?
- いいえ。番号はサーバー側で検証され、保存または記録されることはありません。 そうは言っても、賢明なパターンは、完全な PAN をネットワーク経由でまったく送信しないことです。 クライアント側で UI の最初の 6 ~ 8 桁でブランド検出を実行し、PCI スコープから離れたサーバー側で本当に必要な場合に完全な検証呼び出しを予約します。
- どのカード ブランドが検出されますか?
- 発行者識別番号 (先頭の数字) に基づく、Visa、Mastercard、American Express、Discover、JCB、Diners Club、および UnionPay。 応答では、その番号がクレジット商品であるかデビット商品であるかどうかもわかります。これは、その区別が重要な場合のルーティングまたは追加料金ロジックに役立ちます。
- ユーザーが入力するときにカードのブランド ロゴを表示できますか?
- はい、これが最も価値の高い使用法です。 最初の数桁からブランドを検出し、ユーザーが入力を完了する前に一致するロゴを置き換えます。 これにより、ユーザーはフォームが機能していることを安心させ、「私のカードは受け入れられますか?」という質問を減らすことができます。 サポートチケット。 通話をデバウンスするか、プレフィックスに対してブランド検出をローカルで実行し、送信用に完全な検証を予約します。
- PCI 準拠には Luhn チェックを実行するだけで十分ですか?
- いいえ。Luhn チェックは入力検証であり、コンプライアンス管理ではありません。 サーバーが完全なカード番号に触れると、検証に関係なく PCI スコープ内になります。 最小範囲の設計は、ブラウザーのプロセッサを通じてトークン化し、UI のプレフィックスのみを検証することです。 この API は検証層に役立ちます。 範囲の義務は変わりません。
botoiで開発を始めよう
150以上のAPIエンドポイント。検索、テキスト処理、画像生成、開発者ユーティリティに対応。無料プラン、クレジットカード不要。