Stripe テストカード一覧

Stripe のテストカードを使う手順

3 ステップです。テストカードはテスト用の API キーでしか受け付けられないので、ここにある番号が本物のカードや本物の顧客に触れることはありません。

1. テスト用のキーに切り替えます。 テスト用の公開可能キーとシークレットキー、またはサンドボックスを使います。実際の決済手段の情報を使って本番環境でテストすることは Stripe の利用規約で禁止されていて、テスト用の番号は本番のキーに送っても拒否されるだけです。
2. 欲しい結果のカードを選びます。 単純な成功なら 4242 4242 4242 4242。エラー処理を試すなら、見たい決済拒否コードが書かれた行のカードを選び、セキュリティコードは任意の 3 桁、有効期限は将来の日付にします。日本発行のカードなら国別グループの先頭の 2 枚です。
3. サーバー側のコードでは PaymentMethod を使います。 Stripe は、テスト環境でも API コールやサーバー側のコードでカード番号を直接使わず、pm_card_visa のような PaymentMethod を渡すよう勧めています。カード番号を使うと、本番へ移るときにコードが PCI に準拠しなくなるおそれがあるからです。PaymentMethod の列には、それがあるカードすべての値を載せています。

どのカードでどの失敗が起き、Webhook には何が届くか

決済の失敗をきちんと扱うには、3 つのものを同時に頭に置いておく必要があります。API コールが返す error.code、カード発行会社が付けた decline_code、そして後から Webhook のエンドポイントに届くイベントです。Stripe はこの 3 つを別々のページに書いているので、多くの実装はどれか 1 つだけを見て書かれ、残りの 2 つに驚かされます。同じ情報を、結果ごとに 1 行でまとめたのが次の表です。

1 枚の表として読むと、2 つの習慣が身に付きます。1 つ目。card_declined は理由ではなく分類です。理由は decline_code の側にあり、上の表で card_declined を返す決済拒否の 5 行は、すべて理由を decline_code にしか書いていません。error.code だけで分岐するエラー処理から見ると、資金不足も盗難カードも同じに見え、残高が足りなかっただけの顧客に的外れなメッセージを出すことになります。なお Stripe は、紛失や盗難のような理由は顧客に具体的に伝えず、generic_decline と同じように見せるよう勧めています。

2 つ目。レスポンスにまったく現れない結果があります。審査に回った請求、3 週間後に届く不審請求の申し立て、成功から失敗に変わる非同期の返金——どれも API コールの時点では見えません。イベントとして届くか、エンドポイントを作っていなければ何も届きません。わざとテストする価値があるのは、この失敗のしかたです。カードでブロックを起こし、そのイベントをシステムがどう扱ったかを確かめてください。

表に入りきらない注記を 2 つ。セキュリティコードと郵便番号を送らなければ、Stripe はそのチェック自体を省くので、チェックの失敗をシミュレーションするカードも、フォームがその欄を集めていない限り黙って成功します。また Radar にブロックされた決済の generic_decline は、Stripe の決済拒否コードの一覧で「Stripe Radar または Adaptive Acceptance が決済をブロックした」場合も含むコードとして説明されています。これは意図された作りで、顧客に不正利用を疑われたと伝えないためです。

日本向けの行：JP の 2 枚とコンビニ決済

このページは日本市場向けなので、2 つの表で日本の行を先頭に置き、「日本」のタグを付けています。

カードの 2 枚は、Stripe の国別の表の「日本 (JP)」の行そのままです。変わるのはカードの発行国で、Stripe は国際手数料をカード発行会社の国で判定し、テスト環境でも対象になる場合があると書いています。手数料やカードの国を読む処理を試すなら、発行国がはっきりしているこの 2 枚が向いています。JCB の行の PaymentMethod は pm_card_jcb で、ブランド別グループの JCB（3566 0020 2036 0505）と同じものです。

コンビニ決済は、カードとは結果の決まり方が違います。確定すると PaymentIntent は requires_action で止まり、顧客が店頭で支払うか期限が切れるまで待ちます。Webhook は payment_intent.requires_action のあと payment_intent.succeeded か payment_intent.payment_failed です。テストでどの結果にするかは、請求先のメールアドレスの形か特殊な確認番号で決まり、両方を指定したときは確認番号のほうが優先されます。確認番号には顧客の電話番号を使えるようになっていて、Stripe は 00000000000 を検証エラーとして扱います（表には入れていない値です）。

コンビニ決済の返金は、顧客の銀行口座への振込です。テスト環境では、顧客宛てのメールにある口座情報の入力ページで、金融番号 1100000・口座 0001234 を入れると返金が成功します。なお分割払いを受け付ける場合、対象は日本の Stripe アカウントで、日本で発行されたクレジットカード（デビットカードとプリペイドカードは対象外）による JPY の決済に限られます。Stripe はテスト環境では、本番でボーナス払いが使えない時期にもボーナス払いのプランを返し続けます。

3D セキュアのテスト——日本の EC では避けて通れない分岐

日本では、割賦販売法がクレジットカードを扱う加盟店に不正利用対策を義務付けていて、その実務上の指針が「クレジットカード・セキュリティガイドライン」です。2025 年 3 月 4 日の改訂（6.0 版）で、EC 加盟店の対策として EMV 3-D セキュアの導入が加わりました（日本クレジット協会）。つまり日本の EC サイトでは、認証を挟む決済フローが例外ではなく前提です。そして、正常系のテストでは決して通らないのもこの分岐です。認証が必要な決済は失敗も成功もせず、PaymentIntent が requires_action で返ってきて、フロントエンドが Stripe.js に処理を渡し、顧客にチャレンジを完了してもらう必要があります。

表の 3D セキュアのグループには 9 枚があり、いちばん時間を節約してくれるのは「必須」と「対応」の区別です。

• 4000 0000 0000 3220——認証が必須で、認証は成功します。組み込みはこのカードで作ります。これを使えば、クライアントが本当に確認のステップを呼んでいるのか、requires_action を黙って失敗扱いにしているのかが分かります。
• 4000 0000 0000 3055——3D セキュアに対応していますが、デフォルトでは要求されません。うっかり認証を必須にしていないかの確認に使えます。
• 4000 0084 0000 1629 と 4000 0084 0000 1280——フローが悪い結果で終わる 2 通り。顧客は認証したのに発行会社が拒否する場合と、検索自体がエラーになる場合です。どちらも card_declined で返るので、「チャレンジが終わった＝決済が終わった」と考えるエラー処理は、存在しない決済に完了画面を出してしまいます。
• 4000 0025 0000 3155 と 4000 0027 6000 3184——保存したカードのケース。前者は将来の決済に備えて設定するまでオフセッションの請求で認証が必要、後者は常に必要です。顧客がいない場面で後から請求するなら、この 2 枚が動く継続課金と止まる継続課金の分かれ目です。

見落としやすい点が 2 つ。3D セキュアを本当にテストできるのは、このグループのカードだけです。ほかのテストカードでも 3D セキュアが起動することはありますが、Stripe は attempt_acknowledged を返して追加のステップを飛ばすので、チャレンジの画面は表示されず、動いていると誤解することになります。また、日本発行の 2 枚を含む国別のカードは、発行国ごとの決済成功をシミュレーションするためのもので、認証の分岐を試すものではありません。さらに、Stripe ダッシュボードで直接作成した決済ではリダイレクトが行われないので、自分のフロントエンドか API コールから動かしてください。

Stripe の国別テストカード

Stripe には国別のテストカードの一覧が別にあります。58 か国の 64 枚で、それぞれその国で発行されたカードでの決済成功をシミュレーションします。上の表では最後のグループで、このページでは日本の 2 枚をグループの先頭に置いています。PaymentMethod は国コードに従います（pm_card_de、pm_card_jp、pm_card_br）。例外は 3 つで、メキシコの Carnet とサウジアラビアのカードには PaymentMethod がなく、日本の JCB は pm_card_jcb です。アメリカの行は 4242 4242 4242 4242 そのもので、pm_card_us が付いています。

これらのカードが変えるのは発行国で、用途もそこにあります。手数料やカードの国を読む処理は、これらのカードで流してください。一方、認証はテストしません。ヨーロッパと中東の行のカードについて、Stripe は認証なしで成功する決済をシミュレーションすると明記しています。ドイツやフランスのカードを使っても、チャレンジのフローは動きません。それを試すのは 3D セキュアのグループです。

カードの発行国ではなく顧客の所在地をシミュレーションしたいなら、Stripe は Checkout Sessions、Payment Links、料金表向けに所在地形式のメールアドレスを用意しています。メールアドレスのローカル部分に +location_XX を付け（test+location_JP@example.com のように）、Checkout Session の customer_email か Payment Link の prefilled_email として渡すと、その国の顧客に表示されるのと同じ通貨と決済手段が Checkout のページに出ます。

カードの表の下には、Stripe が 3 つのローカル決済手段について公開しているテスト値があります。日本のコンビニ決済、ドイツ・フランス・スペインの SEPA ダイレクトデビットの IBAN、ブラジルの Boleto です。結果の決まり方はカードと違います。SEPA の引き落としは processing で待ってから成功か失敗が決まり、コンビニ決済と Boleto は支払われるか期限が切れるまで requires_action で待ちます。そのため各行には、単独のイベントではなく Webhook に届く一連の流れを載せています。

返金、不審請求の申し立て、そして遅れて届くもの

本番環境の返金は、即時でも確実でもありません。成功と報告された返金が何時間も後に失敗することも、pending のまま止まって後で確定することもあります。普通のテストカードでは返金がすぐに確定して二度と状態が変わらないので、ほとんどのテストがこれを見逃します。本番の挙動を再現するのが 2 枚で、4000 0000 0000 7726 は返金を pending で始めて後で成功させ、4000 0000 0000 5126 は成功と報告した後で失敗させます。どちらも後からイベントを送ってくるので、戻ってこないお金について顧客から電話が来る前に、そのコードを書いておけます。

不審請求の申し立ても、同じことがゆっくり起きます。請求は普通に成功し、数日後にチャージバックが現れ、通知は charge.dispute.created だけです。4000 0000 0000 0259 は不正利用の申し立て、4000 0000 0000 2685 は「商品未受領」、4000 0000 0000 1976 は完全なチャージバックではなく照会を起こします。照会はエスカレーションせずに閉じられることが多く、チャージバックはそうはいかないので、分けて扱う価値があります。4000 0000 0000 5423 は代わりに不正利用の早期警告を出します。申し立てが来そうだと知らせてくれる合図で、まだ自主的に返金する時間がある段階です。

イベントだけでなく結果もシミュレーションしたいなら、Stripe がテスト用に予約している反証資料の文字列で応答します。winning_evidence は勝訴、losing_evidence は敗訴として閉じ、escalate_inquiry_evidence は照会を本当のチャージバックに変えます。API で応答するなら、この値を uncategorized_text として渡します。

遅れて届くグループの最後は 4000 0000 0000 0077 です。売上を保留中の残高ではなく、利用可能残高に直接入れます。決済のテストではなく経理のテストで、入金を照合する処理があるなら、決済の反映期間を待たずに動くかどうかを確かめられます。

JSON と CSV でテストデータをダウンロード

手で写す表は、いつか写し間違えます。ページ上部の 2 つのダウンロードボタンは、同じ 119 枚を機械で読めるファイルにして渡します。このページを描いているのと同じデータからブラウザの中で作るので、読んだ内容とダウンロードした内容がずれることはありません。

JSON は source、checked、count と cards の配列を持つオブジェクトです。各カードには、テスト名から参照できる固定の id、番号、ブランド、グループ、1 行の説明、セキュリティコードと有効期限の決まり、4 つの対応フィールド（payment_method、error_code、decline_code、webhook_event）、そして国別グループのカードの発行国を表す country があります。当てはまらない項目はキーを省かず null にしているので、パーサーでキーの有無を確かめる必要はありません。

CSV は同じ 12 列で、RFC 4180 の引用規則に従っています。表計算ソフトでそのまま開け、pandas でも変換の引数なしで読み込めます。シードスクリプトや、いずれ誰かに頼まれる QA 用の表にも使えます。表の下のローカル決済手段の値はコピーするためのもので、どちらのファイルにも入っていません。また、ファイルはこの日本語のページから落としても英語のままです。どの言語のページから落としても同じファイルなので、テストの期待値がページの言語で変わることはありません。

どちらのダウンロードも、かけている絞り込みに従います。表を決済拒否に絞って JSON をダウンロードすると、119 枚ではなく 10 行が手に入ります。パラメータ化したテストに欲しいのは、たいていそれです。

test.each(fixtures.cards.filter(c => c.group === 'decline'))(
  '$id surfaces $decline_code',
  async ({ payment_method, error_code, decline_code }) => { /* … */ },
);

ファイルには出典の URL と照合した日付が入っています。日付のないカードの一覧は、半年後には信用できない一覧だからです。Stripe が番号を変えたときの正しい直し方は、古いコピーをリポジトリに置き続けることではなく、出典を確かめ直すことです。

本当に作っているもの

テストカードを楽しみで調べる人はいません。ここに来たのは決済を組んでいるからで、決済はもっと大きなものの一部です。カタログ、顧客が書き換えられない価格、秘密鍵を持つどこかで作られるセッション、注文を支払い済みとみなすかを決める Webhook、そしてお金が届いた後に起きることすべて。

いちばんよく壊れるのはカードではありません。価格です。価格を HTML に持ち、金額を決済のエンドポイントに送る静的サイトは、その数字をブラウザに預けていて、ブラウザは信用できません。テストカードでは決して見つからない種類のバグです。改ざんされた支払いは、見事に成功するからです。

Clize がまさにこの理由で Stripe Checkout の上に作り、価格をサーバー側に置いているのはそのためです。ホスト型のストアは、サイトと一緒にデプロイされた _catalog.json に照らしてすべてのカートの価格を計算し、クライアントが主張する金額は無視します。問題の形がそれなら、カタログファイルの生成と検証のツール（英語）があります。1 人の顧客に 1 つの金額を払ってもらうだけなら、clize pay link --amount 5000 で、自分の Stripe アカウントなしに本番の Stripe Checkout の URL が返ってきます。そちらは本物のお金が動く決済なので、このページの番号からは十分に離しておいてください。

$ npm i -g @clize/clize && clize login
$ clize pay link --amount 5000 --for "請求書 1042"