Stripe テストカードは、決済事業者が自社のテスト環境向けに公開している合成の番号です。入力すると成功するもの、必ず拒否されるもの、追加認証を求めるものなど、用途ごとに用意されています。この記事では、なぜ事業者がテストカードを配るのか、何を再現できるのか、そして本番環境と取り違えないための区別のしかたを説明します。
事業者がテストカードを公開する理由
決済の連携を組む以上、成功する取引だけでなく失敗する取引も試さなければなりません。ところが失敗は自分で作り出せません。残高不足や利用停止を故意に起こすことはできないからです。
そこで事業者は、自社のサンドボックスの中でだけ意味を持つ番号を公開し、開発者が任意の結果を再現できるようにしています。実在のカードを使わずに検証できるため、開発者の手元に機密情報を持つ必要がなくなり、事故の危険も下がります。事業者にとっては連携の質が上がり、開発者にとっては試行錯誤がしやすくなる、双方に利点のある仕組みです。
公開されているテストカードの分類
公開される番号は、おおよそ次のように分類できます。具体的な番号は事業者のドキュメントで確認してください。ここでは種類と使い分けだけを示します。
| 分類 | 何を試せるか |
|---|---|
| 成功するカード | 承認から完了までの正常系 |
| 拒否されるカード | 残高不足や利用停止などの異常系 |
| 追加認証を求めるカード | 3D セキュアの分岐とリダイレクト |
| 通貨や決済手段ごとのカード | 通貨別の挙動や対応範囲の確認 |
| 特殊な用途のカード | 返金や分割など、機能固有の挙動 |
もっとも広く引用されているのは、4 で始まり同じ数字を 16 桁まで並べた汎用の成功カードです。有効期限は将来の任意の年月、セキュリティコードは任意の 3 桁で通過します。まずはこの 1 枚で正常系を通し、そこから異常系を足していく流れが効率的です。
成功と失敗をどう使い分けるか？
テストの設計としては、正常系を先に固め、そのうえで異常系を加えます。順序を逆にすると、失敗の原因が自分の実装にあるのか、入力の意図どおりの失敗なのかを切り分けられなくなります。
失敗を再現するときは、画面上で利用者にどう見えるかまで確認してください。拒否の応答を受け取ったアプリが、その内容をそのまま表示していると、利用者には意味不明な英語の文字列が出ます。エラーコードから利用者向けの文言へ変換する処理が動いているかは、拒否を再現して初めて分かります。
3D セキュアの検証では、認証を通過する場合と、利用者が認証を放棄した場合の両方を試します。放棄したときに注文が中途半端な状態で残らないか、在庫の引き当てが解放されるかまで確認しておくと、後工程での問い合わせを減らせます。
テストカードは本番で使えますか？
使えません。テストカードはサンドボックス用の鍵と組み合わせて初めて意味を持ちます。本番の鍵で同じ番号を送ると、取引は拒否され、無駄な試行として記録されます。番号の見た目は普通のカードと同じですが、実際に発行された番号ではないためです。
環境の取り違えは、もっとも起こりやすく、もっとも見つけにくい事故です。鍵の切り替えが設定ファイルの 1 行で済む構成では、とくに注意が必要です。決済の画面やログに、どちらの環境につながっているかを常に表示しておくと、気づかないまま本番へ送る事態を防げます。
リストを丸写しにしない
事業者が公開するテストカードの一覧は、機能の追加や再編に合わせて更新されます。結果として、古い記事や社内メモに残った一覧が、いずれ動かない番号になることがあります。
安全な運用は、一覧を写すのではなく、必要な番号だけを選んで自分のテストデータとして固定し、出典と確認日を記録しておく方法です。定期的に見直す前提で管理すれば、いつの間にか壊れているという事態を避けられます。とくに、失敗の理由ごとに番号を割り当てている場合は、どの番号がどの理由に対応するのかを一覧にしておかないと、テストの意味が失われます。この考え方は他の場面でも同じで、カードブランド別のテスト番号の選び方 でも扱っています。番号そのものを大量に用意したい場合は、テスト用クレジットカード番号生成 で桁数とブランドを指定して生成できます。
開発者向け: シナリオと追加認証の整理
自動テストに組み込むときは、番号を直接書くのではなく、シナリオ名を付けた定数としてまとめます。「残高不足を返す」「追加認証を求める」といった名前で参照できれば、テストを読む人が番号の意味を調べ直す必要がありません。
3D セキュアのテストは、認証画面の分岐を網羅する必要があります。認証成功、認証失敗、利用者による中断、認証画面が応答しない場合の扱い。これらの分岐ごとに、注文の状態と在庫の状態がどうなるかを期待値として書いておきます。決済の状態を表す値は、事業者が定義する語彙に従うため、こちらの都合で作った状態名に置き換えないほうが安全です。
もう一点、テストの実行順序に依存しないようにしてください。成功カードで作った取引が、拒否のテストの前提になっているような構成は、並列実行で壊れます。各テストが自分の取引を新しく作る形にしておけば、実行順を気にせずに済みます。テスト全体の観点は 決済フォームのテスト項目 にまとめています。最新の一覧は必ず事業者の公式ドキュメントで確認してください。
次のステップ
まず、いま使っているテスト番号の出典と確認日を一覧にしてください。次に、成功・拒否・追加認証の 3 つの分岐を、それぞれ自動テストから再現できる状態にします。この 3 つが再現できていれば、決済まわりの変更を入れても壊れた箇所をすぐに特定できます。