Stripeのテスト用カード番号一覧

Stripeの「テスト用カード番号」とは

Stripeには「テスト環境」と「本番モード」が用意されており、開発中や動作確認の段階では実際のクレジットカードを使わずに決済処理を試せる仕組みがあります。その中心となるのが「テスト用カード番号」です。
テスト用カード番号とは、Stripeが公式に提供している架空のカード番号で、決済の成功・失敗・エラーなどを安全に再現できます。これらの番号は実際の決済ネットワークとは接続されていないため、課金が発生することはありません。
また、実カードを使ったテストは規約違反や情報漏えいのリスクがあります。特にクライアントワークやチーム開発では、テストカード番号を使うことが前提です。Stripe開発では「テストカードを使う＝正しい作法」と考えて問題ありません。

それとテストカードの決済ではStripeから決済完了などのメールは送信されません。　メール本文の確認は本番環境でしかできない仕様となっています。（ちょっと不便ですが）

Stripeで使えるテストカード番号一覧（クレジットカード）

以下は、Stripe公式が提供している代表的なテストカード番号です。
使い方はチェックアウトフォーム（決済時にクレジットカード情報を入力する画面）に入力するだけで、事前に「テスト環境」設定していれば利用できます。
実際の課金は一切発生しません。
Stripeを利用して、ノーコード、ローコードで運用されている方は、決済が成功するテストカード番号を使って決済が完了するかチェックしてください。
決済システムを開発している方は、エラー再現用のカードも役立ててください。

決済が成功するテストカード番号

ブランド	テストカード番号
Visa	4111 1111 1111 1111
Visa	4242 4242 4242 4242
Mastercard	5555 5555 5555 4444
American Express	3782 822463 10005
Discover	6011 1111 1111 1117
JCB	3530 1113 3330 0000
Diners Club	3056 9309 0259 04

入力ルール

チェックアウトフォームでクレジットカード情報を入力する際にテストカード番号のほかの情報を求められます。
テストカードを利用している場合は、これらは任意の数字で問題ありません。

• 有効期限：任意の将来日（例：12 / 34）
• CVC（セキュリティコード）：任意の数字（例：123、Amexは4桁でもOK）
• 郵便番号：任意（フォームがある場合）

決済が失敗するテストカード番号（エラー再現用）

テストカードにはわざとエラーを発生させるカード番号があります。
ここから下は、決済システムを開発する人向けの内容となっています。

カード拒否（card_declined）

• 4000 0000 0000 0002

決済が即失敗し、payment_intent.payment_failed が発火します。

残高不足（insufficient_funds）

• 4000 0000 0000 9995

「残高不足」エラーを再現できます。

処理エラー（processing_error）

• 4000 0000 0000 0119

一時的な決済処理エラーを再現。

3Dセキュア（本人認証）テスト用カード番号

3Dセキュア必須（認証成功）

• 4000 0025 0000 3155

認証フローが発生し、成功すると決済完了。

3Dセキュア失敗

• 4000 0000 0000 3220

認証に失敗し、最終的に決済失敗になります。

CVC・郵便番号エラーを再現するカード番号

CVCチェック失敗

• 4000 0000 0000 0127

郵便番号チェック失敗

• 4000 0000 0000 0101

開発時の実務メモ（重要）

• テストカードは 本番モードでは使用不可
• テストカードでも Webhookイベントは本番と同じ種類が発火する
• 決済失敗時は主に
• payment_intent.payment_failed
• last_payment_error.code
  を確認する

この一覧でStripeの決済テスト・エラー再現・Webhook検証を一通りカバーできます。

テストカード番号を使った開発・検証の実践ポイント

テストカード番号を使う際の実務的な注意点と運用のコツをまとめます。

Webhook・Checkoutと組み合わせたテストの考え方

テストカード番号は、Webhookテストと組み合わせて使うことで真価を発揮します。
たとえば「決済失敗時にどのイベントが飛ぶか」「成功時と失敗時で処理が分岐できているか」などは、実際にイベントを受け取って確認する必要があります。

Webhookを含めた検証方法については、CLIを使った具体的な手順をまとめた「Webhookテストの実践ガイド」が参考になります。

決済方法ごとのテスト時の注意点

本記事で紹介しているテストカード番号は、クレジットカード決済向けのものです。
Apple Pay やコンビニ決済など、他の決済方法ではテスト方法が異なる場合があります。

複数の決済手段を扱う場合は、それぞれの特性を理解したうえでテスト設計を行いましょう。

決済時の3Dセキュア認証には気を付けて

3Dセキュア認証とは、決済時にカード会社からカード利用者の連絡先にワンタイムパスワードを送信し、今の決済が正しいか確認する機能です。
決済時に3Dセキュア認証が入ると、一時的にpayment_intent.payment_failedイベントが発生します。
その際、payment_intent.requires_actionを確認することで、認証待ちなのがわかります。　つまり内部的には保留ってことだと思います。　

この段階では失敗が確定しているわけではないので、先走って「決済が失敗しました」という内容のメールを送信しないように気を付けてください。　私はやらかしました。
テストカードには3Dセキュア認証の成功・失敗のカードはあるものの、実際にワンタイムパスワードを送信する機能はないので、本番環境で実際のクレジットカードを使ったデバッグが必須です。