Stripeテストカード一覧と使い方：3Dセキュア・決済拒否・不審請求をテストする手順

Stripeのテストカードは、サンドボックスでお金を動かさずに決済の成功・拒否・3Dセキュア認証・不審請求・返金を再現するための番号群です。代表は「4242 4242 4242 4242」ですが、拒否理由や認証パターンごとに専用の番号があり、目的に合わない番号では狙った分岐を通せません。この記事では目的別の番号に加え、テストコードで使うpm_card_visaなどのPaymentMethod、Stripe CLIでのWebhook検証、E2Eテストで自動化する範囲を、公式ドキュメントをもとに解説します。

まとめ｜Stripeテストカードの番号・使い分け・テスト設計の要点

手入力で画面を確かめるときは4242 4242 4242 4242に将来の有効期限（12/34など）と任意の3桁を入れれば決済は成功します。拒否やエラー処理を確かめるときは、残高不足なら4000 0000 0000 9995のように理由別のカードを選び、返ってくるdecline_codeで分岐を検証します。

サーバー側の自動テストではカード番号を書かず、pm_card_visa_chargeDeclinedのようなテスト用PaymentMethodを指定するのが公式の推奨です。決済フォームのUIは自動操作に頼らず、APIとWebhookの層で分岐を固めます。

単発決済なら成功・拒否3種・3Dセキュア1種の確認で足り、内製で回せます。保存カード課金やサブスクまで扱うと、テストの組み合わせは一気に増えます。

Stripeテストカードを使う前の準備：サンドボックスとテスト用APIキー

テストカードは、サンドボックスとテスト用APIキーの組み合わせでだけ機能します。本番キーで使うと決済は通りません。

テストカードが動く条件：sk_test_キーとサンドボックスの関係

Stripeのテストは、すべてのAPI呼び出しをテスト用APIキーで行うことが前提です。StripeのAPIキーの解説によると、サンドボックスのキーは公開可能キーがpk_test_、シークレットキーがsk_test_、制限付きキーがrk_test_で始まります。

テストカードで決済が通らないときは、まずキーの取り違えを疑います。Stripe公式のテストカード一覧は、実在するカード情報を本番環境でテストに使うことを利用規約違反として禁じています。手元の個人カードで「少額だけ試す」運用は取りません。

テスト環境のサンドボックスと一般的なサンドボックスを選ぶ基準

Stripeのサンドボックスには、アカウントに最初からある「テスト環境のサンドボックス」と、追加で作る「一般的なサンドボックス」の2種類があります。ユースケースのテストに関する公式ページの比較表では、前者は本番と設定を共有し削除できない一方、後者は最大5つまで作れて設定が完全に分離され、削除もできます。

新規の実装なら一般的なサンドボックスを選びます。サンドボックスの公式解説も、ローカル開発とCIで別のサンドボックスを使うよう勧めています。テストカードの番号はどちらでも同じです。

決済成功を再現するテストカード番号：4242・日本発行カード・ブランド別

まずは決済が成功する番号です。ブランドや発行国を変えたい場合だけ、4242以外を選びます。

4242 4242 4242 4242の入力方法と有効期限・セキュリティコード

決済フォームやダッシュボードで手入力するときは、カード番号に4242 4242 4242 4242、有効期限に12/34のような将来の日付、セキュリティコードに任意の3桁を入れます。American Expressだけはセキュリティコードが4桁です。氏名や住所など他の欄は任意の値で構いません。

公式一覧によると、CVCを空欄にするとStripeはCVCチェック自体をスキップします。CVCエラーの画面は、後述の専用カードにCVCを入力して確かめます。

日本発行のVisa 4000 0039 2000 0003とJCBで国内決済を確認

国内向けサービスでは、発行国が日本のテストカードを使うと本番に近い条件で確認できます。公式一覧の国別表では、日本発行のVisaが4000 0039 2000 0003（pm_card_jp）、日本発行のJCBが3530 1113 3330 0000です。

公式一覧には、発行国がアメリカ以外のカードはテスト環境でも国際手数料の対象になる場合があるとの注記があります。手数料の表示まで確かめる画面では、自社アカウントの国と同じ発行国のカードを選ぶと誤差が出ません。ブランドごとの提供範囲はStripeの機能一覧と日本での提供可否で整理しています。

決済拒否とエラー処理を検証するテストカードとdecline_codeの対応

決済の失敗は、カード発行会社による拒否、入力値の誤り、Radarによるブロックの3系統に分かれます。ここでは前の2つを扱います。

残高不足・紛失・盗難など拒否理由別のカード番号とエラーコード

拒否系のカードは、決まったエラーコードと拒否コード（decline_code）を返します。画面に出す文言やリトライ可否を拒否コードで分けている実装なら、少なくとも次の5枚は通しておきます。

5枚ともエラーコードはcard_declinedで、違いは拒否コードだけです。推奨対応はStripeの支払い拒否コード一覧にあります。紛失・盗難の理由は利用者に見せない実装が多いので、表示文言の分岐まで確かめてください。

有効期限切れ・CVC誤り・番号誤りを再現する専用カードと入力値

入力系のエラーには、専用カードを使う方法と、無効な値をそのまま入れる方法の2通りがあります。有効期限切れは4000 0000 0000 0069（expired_card）、CVC誤りは4000 0000 0000 0127（incorrect_cvc）、処理エラーは4000 0000 0000 0119（processing_error）です。

専用カードが要らないケースもあります。月に13を入れればinvalid_expiry_month、CVCに2桁の99を入れればinvalid_cvc、Luhnチェックに通らない4242 4242 4242 4241ならincorrect_numberになります。フロント側の入力検証を確かめるときはこちらが手軽です。

保存済みカードへの請求失敗を再現する4000 0000 0000 0341

公式一覧によると、前述の拒否系カードはCustomerオブジェクトに関連付けること自体ができません。保存の段階で失敗するため、「保存は通ったが後日の請求で落ちた」という状況を作れないのです。

この状況には4000 0000 0000 0341を使います。Customerへの関連付けは成功し、その後の請求だけが失敗する1枚です。サブスクの更新失敗のテストはここが起点になります。継続課金側の設計はサブスクリプション課金のオフセッション決済と更新失敗対策で解説しています。

3Dセキュア認証を試すテストカードとオンセッション・オフセッション

3Dセキュアは、公式一覧で「3DSテスト用」とされたカードでしか狙った挙動を再現できません。他のテストカードでも認証が始まることはありますが、追加の手順は省略されます。

認証必須・認証後の拒否・処理エラーを返す3Dセキュア用カード

認証画面の表示と、その後の分岐を確かめるカードは次のとおりです。4枚とも3Dセキュア認証が要求されます。

4242 4242 4242 4242は「3Dセキュアに対応しているが登録されていない」扱いで、Radarルールが認証を求めても利用者には認証画面が出ません。認証のテストに4242を使って「画面が出ない」と悩むのは、このためです。任意のカードで認証を強制したいときは、3Dセキュア認証の公式ガイドにあるrequest_three_d_secureをanyまたはchallengeに設定します。

保存カードのオフセッション課金で認証要求を出す3155と3184

カードを保存して後から請求する実装では、利用者が画面にいない状態（オフセッション）で認証が求められるかどうかが分かれ目です。4000 0025 0000 3155は、将来の決済用に設定していないとオフセッション決済で認証を求め、設定後は認証なしで通ります。4000 0027 6000 3184は、設定の有無にかかわらず毎回認証を求めます。

2枚を並べて流せば、SetupIntentでの事前設定が効いているかが分かります。3184で失敗したとき利用者を画面へ呼び戻す導線の有無も、ここで確認しておきましょう。国内ECで3Dセキュアが求められる背景と認証フローはEMV 3-Dセキュアの仕組みと実装にまとめています。

ダッシュボードで作った決済では3Dセキュアのリダイレクトが起きない

公式一覧には、ダッシュボードで直接作成した決済では3Dセキュアのリダイレクトが行われないとの注記があります。管理画面から手動で決済を作って「3Dセキュア用カードなのに認証が出ない」と判断するのは誤りです。

認証の確認は、自社のフロントエンドかAPI呼び出しで行います。

不正利用・不審請求・返金をテストするカード番号と反証資料の値

決済が通った後に起きる事象も、テストカードで再現できます。本番では後日発生するため、事前に一度通しておきます。

Radarのブロックを再現する4100 0000 0000 0019ほか

4100 0000 0000 0019は、リスクレベル「極めて高い」としてRadarが常にブロックするカードです。ブロックされた決済はカードエラーとして返るため、発行会社の拒否と区別せずに処理していると、利用者に誤った文言を出します。

Stripeのエラー処理ガイドは、エラーに含まれるChargeを取得してoutcome.typeがblockedかどうかで判定する方法を示しています。

不審請求を起こすカードとwinning_evidenceで勝敗を決める手順

4000 0000 0000 0259で決済すると、決済は成功したうえで「不正利用」の不審請求（チャージバック）が自動で申し立てられます。4000 0000 0000 2685なら「商品未受領」、4000 0000 0000 1976なら「照会」です。

申し立てへの応答もテストできます。APIで反証資料を出すとき、uncategorized_textにwinning_evidenceを渡すと勝訴として資金が戻り、losing_evidenceなら敗訴で閉じます。通知から反証提出までの業務フローを事前に通せるのが利点です。

返金の非同期失敗を5126で再現しrefund.failedを受ける

本番の返金は非同期です。4000 0000 0000 5126で決済して返金すると、返金のステータスはsucceededで始まり、しばらくしてfailedに変わりrefund.failedイベントが届きます。4000 0000 0000 7726は逆にpendingからsucceededへ移ります。

ほかのカードでは返金が即座に成功するため、返金APIの戻り値だけで「返金完了」と記録する欠陥はこの2枚でしか見つかりません。返金状態はWebhookで確定させます。

テストコードでpm_card_*を使ってPaymentIntentを作る手順

ここからはコードで自動化する手順です。公式一覧は、テストコードにはカード番号ではなくテスト用PaymentMethodを使うよう明記しています。カード番号を直接APIへ送るコードは、本番移行時にPCI DSSへの準拠を崩すおそれがあるためです。

curlで日本円500円のPaymentIntentをpm_card_jpで確定する例

最小の確認はcurlで足ります。日本円は小数点以下のない通貨なので、Stripeの対応通貨ページのとおり500円はamount=500と書きます（100倍しません）。同ページによると日本円の最低請求額は50円です。

curl https://api.stripe.com/v1/payment_intents \
  -u "sk_test_xxxxxxxx:" \
  -d amount=500 \
  -d currency=jpy \
  -d "payment_method_types[]=card" \
  -d payment_method=pm_card_jp \
  -d confirm=true

payment_method_types[]=cardを明示しているのは、自動の決済手段設定のままだと確定時に戻り先URLを求められる場合があるためです。エラー処理ガイドの例も同じ指定をしています。応答のstatusがsucceededなら成功です。

Node.jsのテストで拒否系PaymentMethodのcard_errorを検証する

拒否時の分岐は、テストランナーから実際にサンドボックスへ投げて確かめられます。次の例はStripe公式のNode.jsライブラリとJestを使い、残高不足の拒否を検証します。

const Stripe = require('stripe');
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY); // sk_test_ で始まるキー

test('残高不足のカードは insufficient_funds で拒否される', async () => {
  await expect(
    stripe.paymentIntents.create({
      amount: 500,
      currency: 'jpy',
      payment_method_types: ['card'],
      payment_method: 'pm_card_visa_chargeDeclinedInsufficientFunds',
      confirm: true,
    })
  ).rejects.toMatchObject({
    type: 'StripeCardError',
    code: 'card_declined',
    decline_code: 'insufficient_funds',
  });
});

PaymentMethodの名前をpm_card_visa_chargeDeclinedLostCardやpm_card_chargeDeclinedExpiredCardに替えれば、拒否理由ごとのテストを並べられます。Radarのブロックはpm_card_radarBlock、3Dセキュア必須はpm_card_threeDSecure2Requiredです。本番コード側でエラー型ごとに処理を分ける書き方はStripe APIの使い方：PaymentIntentの作成・APIキー認証・冪等キーをNode.jsとcurlで実装にまとめています。

Stripe CLIのlistenとtriggerでWebhookを確かめる

決済結果を受け取るWebhookハンドラーは、Stripe CLIでローカルに転送して確かめます。stripe triggerはイベントを発生させるコマンドで、CLIリファレンスにある--overrideで金額や通貨を差し替えられます。

stripe login
stripe listen --forward-to localhost:3000/webhook

# 別のターミナルで実行する
stripe trigger payment_intent.payment_failed
stripe trigger payment_intent.succeeded --override payment_intent:amount=500 --override payment_intent:currency=jpy

stripe listenが表示する署名シークレットを、ローカルのハンドラーの検証用シークレットに設定します。署名検証と、同じイベントが2回届いても注文を二重に確定しない作りは決済Webhookの署名検証と冪等な注文確定で詳しく扱っています。Stripe CLIの導入からfixtures・logs tailでのデバッグまでの手順はStripe CLIの使い方：インストールからstripe listen・triggerでのWebhookローカル検証までにまとめています。

E2Eテストで自動化する範囲とモックに置き換える範囲の線引き

決済フォームの自動操作には、Stripe側の制約があります。

Payment ElementやCheckoutの入力をE2Eで自動操作しない理由

自動テストに関するStripe公式ガイドは、CheckoutやPayment Elementには自動テストを防ぐためのセキュリティ対策が講じられていると明記しています。PlaywrightやCypressでカード番号欄へ入力するテストは、成功しても次のリリースで突然落ちる不安定なテストになりがちです。

公式の推奨は、拒否用カードで一度手動で確定し、返ったエラーオブジェクトを記録して、自動テストではそれを返すモックに差し替える方法です。決済フォームの手動確認はリリースごとに1回とし、残りはAPI層とモックで自動化するのが現実的です。E2E全体の範囲の決め方はE2Eテストのベストプラクティスを参照してください。

サンドボックスのレート制限25件/秒とCIでの呼び出しの抑え方

Stripeのレート制限ページによると、全体の上限は本番が毎秒100リクエスト、サンドボックスは毎秒25リクエストです。CIでテストを並列実行すると、サンドボックス側の上限に先に当たって429エラーで落ちます。

サンドボックスへ実際に投げるテストは代表数本に絞り、残りはモックで回します。同ページは負荷テストへのサンドボックス利用も勧めていません。

カード単位の状態が次のテストに残る問題とシナリオ別のカード割当

公式一覧は、あるテストで生じたカード単位の状態が、同じカードを使う後続のテストに影響する可能性があると注意しています。たとえば同じカードで保存と請求を繰り返すテストを並べると、前のテストの結果で後のテストの前提が崩れます。

対策は、独立したシナリオごとに別のテストカードを割り当てることです。テストごとに新しいCustomerを作る運用も効きます。

Stripe決済のテストを内製で回すか外部に任せるかの判断基準

決済テストの大半は手元で再現できます。分かれ目は、維持するシナリオの本数です。

内製で十分な規模：Checkoutの単発決済で拒否3種と3DS1種を確かめる

Checkoutやペイメントリンクで単発決済を受けるだけなら、内製で足ります。確かめるのは、4242での成功、残高不足・一般拒否・有効期限切れの3種、4000 0000 0000 3220での3Dセキュア認証、決済成功Webhookの受信の6本程度です。画面の大半をStripeが持つため、自社で書くコードも少なく済みます。

実装方式ごとの作業量の違いは、親記事のStripeとは？仕組み・手数料・実装パターンで比べています。

外部に任せる方がよい規模：保存カード課金・サブスク・Connectの組み合わせ

カード保存後のオフセッション課金、サブスクの更新失敗と再試行、返金と不審請求の業務フロー、Connectでの売上分配が重なると、テストシナリオは数十本規模になります。Connectの資金フローと返金時の送金の差し戻しはStripe Connectとは：アカウント種別・3つの支払い方式と資金フローの実装手順で扱っています。0341・3155・3184・5126・0259をそれぞれの流れに当てはめ、Webhookの順序違いまで検証する必要があるためです。

決済テストの設計経験が社内に無いなら、決済開発の経験がある外部に頼むほうが、リリース後の障害対応より安く済むでしょう。一創では決済・サブスクリプションシステムの開発として、Stripeを使った決済実装とテスト設計を支援しています。カード情報の取り扱い範囲の整理はPCI DSSの要件と準拠レベルも参考になります。

Stripeテストカードのよくある質問｜本番利用・入力値・3Dセキュア

Stripeのテストカードについて、実装時によく出る質問をまとめました。

Stripeのテストカードは本番環境で使えますか？

使えません。テストカードはサンドボックスとテスト用APIキー（sk_test_で始まるキー）の組み合わせでだけ機能し、本番キーで送っても決済は成立しません。逆に、実在するカードでテストすることは利用規約で禁じられています。本番移行時は両方のキーを本番用に差し替えてください。

テストカードの有効期限やセキュリティコードは何を入れればよいですか？

有効期限は12/34のような将来の日付、セキュリティコードは任意の3桁（American Expressは4桁）を入れます。他の欄も任意の値で構いません。CVCを空欄にするとCVCチェックがスキップされるため、CVCエラーは4000 0000 0000 0127にCVCを入力して再現します。

4242のカードで3Dセキュアの認証画面が出ないのはなぜですか？

4242 4242 4242 4242は、3Dセキュアに対応しているものの登録されていないカードとして扱われるため、Radarルールが認証を求めても認証画面は表示されません。認証画面は4000 0000 0000 3220などの3Dセキュア用カードで確かめます。ダッシュボードで直接作った決済ではリダイレクトが起きないため、自社の決済画面かAPIから試してください。

テストコードでカード番号を直接使ってはいけないのですか？

Stripeは推奨していません。サーバー側でカード番号をAPIに送る作りにすると、本番移行時にPCI DSSへ準拠できなくなるおそれがあるためです。代わりにpm_card_visaやpm_card_visa_chargeDeclinedのようなテスト用PaymentMethodを指定すれば、拒否理由ごとのテストも書けます。

テストで作った決済や顧客のデータは削除できますか？

削除できます。サンドボックスのダッシュボードで開発者メニューの概要を開き、テストデータのセクションから一括削除を実行する手順です。削除は取り消せず、処理中はサンドボックスが一時的に使えなくなります。ローカル開発用とCI用でサンドボックスを分けておけば、片方だけを消せます。

関連記事

• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：テスト対象となる実装パターン3種と手数料の全体像。
• 3Dセキュアとは？EMV 3-Dセキュア2.0の仕組み・認証フローとEC決済への実装を開発視点で解説：3Dセキュア用テストカードで確かめる認証フローの仕組み。
• 決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説：stripe triggerで送るイベントの受け側の実装。
• サブスクリプション課金とは？継続課金の仕組み・オフセッション決済と更新失敗対策の実装を開発視点で解説：0341や3155で再現する更新失敗の対策。
• E2E（エンドツーエンド）テストのベストプラクティス｜結合テストとの違いとツール選定：決済フォームを含むE2Eの範囲の決め方。