Stripeテストカード：米国向けチェックアウト決済と3Dセキュアをテストする

決済ページが開き、商品と価格が正しく表示されている。次に確認すべきことは、支払いボタンがクリックできるかどうかだけではありません。

カードが拒否されたとき、ページには何が表示されるでしょうか？購入者は別のカードに切り替えて続行できるでしょうか？本人確認が途中でキャンセルされた場合、注文が誤って支払い済みとしてマークされることはないでしょうか？

3枚のStripeテストカードを使い、成功・失敗・本人確認をそれぞれ確認します。各送信後は、チェックアウトとバックエンドの記録の両方を確認してください。

この記事では、米国の請求先住所が必要なチェックアウトを例にします。ブラウザで操作し、コードを書く必要はありません。

1. テスト環境で決済ページを開く

Stripeダッシュボードに移動し、アカウントセレクターを使ってテスト環境であるSandboxに切り替えます。今回のすべての決済操作はこの環境で完了し、実際の資金は動きません。Stripeテスト環境のドキュメント

すでにテスト用の決済リンクがある場合は、それを直接開きます。

まだ作成していない場合は、テスト環境の決済リンクで新しいリンクを作成し、テスト用の商品と価格を選択して、生成された決済ページを開きます。決済リンクは、ウェブサイトを構築しなくてもダッシュボードから作成できます。決済リンクを作成する

まず次の3点を確認します。

商品が正しいか。
金額と通貨が正しいか。
ページが、先ほど選択したテスト環境のものか。

この段階で急いでカード番号を入力しないでください。誤った価格を選択したり、誤ったリンクを開いたりすると、以降のテストを完了しても、公開予定のフローを確認したことにはなりません。

2. 米国の請求先住所を入力する

請求先の国でUnited Statesを選択します。

住所ジェネレーターを開き、United Statesを選択し、生成数に1を設定して、生成をクリックします。番地、都市、州、ZIPコードをコピーして、決済フォームに入力します。

各フィールドは次のように入力します。

チェックアウトのフィールド	入力する内容	例
Address line 1	番地	5322 N Union Street
Address line 2	アパートや部屋番号。なければ空欄	空欄のまま
City	都市	North Walpole
State	対応する州	New Hampshire
ZIP code	ZIPコード	03609
Country	国	United States

州のフィールドがドロップダウンメニューの場合はNew Hampshireを選択し、2文字の略称が必要な場合はNHを入力します。

ZIPコード03609の先頭のゼロは必ず保持してください。数値として扱って3609と書かないでください。

後で通知を確認できるよう、アクセス可能なテスト用メールアドレスを使用してください。住所を入力したら、このサンプルを保持し、3回のテストすべてで同じ住所を使用します。

こうすることで、決済結果が変わったときに、最初に比較するのはカード番号と確認操作になります。都市、州、ZIPコードが同時に誤って変更されていないかも調べる必要はありません。

3. 成功カードで完全な決済フローを確認する

まずこの情報を使用します。

カード番号: 4242 4242 4242 4242
有効期限: 12/34
CVC: 123

有効期限は将来の日付である必要があります。ここでの月/年とCVCはこのテスト用であり、カード番号はStripeの成功決済シナリオに対応します。テストカードのドキュメント

支払いをクリックし、ページが期待どおりの完了状態になるか観察します。

その後、同じテスト環境に戻り、決済記録を開き、先ほど行った取引を見つけます。金額、通貨、支払いステータスを確認します。決済リンクからの支払いは、ダッシュボードの支払い概要で確認できます。決済記録を表示する

このラウンドでは、次の2点を別々に確認します。

支払いステータスが正しいか、そしてページの後続アクションが正しいか。

たとえば、バックエンドでは支払い成功と表示されているのに完了ページが開かない場合、トラブルシューティングの焦点は支払い後のページ設定とリダイレクトパスに置くべきです。ブラウザがエラーを報告したからといって、カード番号と住所全体を再入力しないでください。

逆に、ブラウザに「ご購入ありがとうございます」と表示されても、バックエンドの支払いステータスの代わりにはなりません。確認ページと支払い記録は互いに対応している必要があります。

決済リンクが注文、メール、ダウンロードのフローに接続されている場合は、これらの手順も確認します。

注文が支払い済みとして表示されるか。
金額がチェックアウトと一致するか。
設定された通知が送信されたか。
設定されたダウンロードまたはアクセス用の入口が利用可能か。

接続されていない機能を確認する必要はなく、Stripeの支払い成功をこれらの機能が完成している証拠として扱ってはいけません。

4. 失敗カードでエラーメッセージとカード再試行を確認する

決済リンクを再度開き、新しいテストを開始します。

住所、メール、その他の条件は変更せず、カード番号だけを次のように変更します。

4000 0000 0000 0002

このカードは一般的な支払い拒否をシミュレートします。拒否されるテストカード

支払いをクリックした後、次を確認します。

ページに明確な失敗メッセージが表示されるか。
カード番号入力フィールドがまだ編集可能か。
ページが誤って支払い完了状態になるか。
関連する注文が誤って支払い済みとしてマークされるか。

失敗メッセージは「エラーが発生しました」だけではいけません。購入者は少なくとも、支払いが完了しなかったことと、まだ続行できることを知る必要があります。

次に、現在のチェックアウトでカード番号を次のように戻します。

4242 4242 4242 4242

もう一度送信します。

この手順では、失敗後の回復パスを確認します。最初に支払いが成功したからといって、一度失敗した後にボタン、フォーム、注文ステータスがまだ正しいとは限りません。

最初の失敗後に回転し続ける場合は、どこで止まっているかを記録します。まず再試行操作を確認し、住所を変更したり、商品を変更したり、すべてのページを同時に更新したりしないでください。複数の条件を一度に変更すると、最も価値のある比較が失われます。

5. 完了した本人確認とキャンセルした本人確認の両方のパスを確認する

3回目のラウンドでは、米国発行の3Dセキュアテストカードを使用します。

4000 0084 0000 0027

StripeのデフォルトのRadarルールは、このカードに対して3Dセキュア認証を要求します。3Dセキュアテストのドキュメント

テストは、購入者が開いた決済ページで実行する必要があります。Stripeダッシュボードで直接支払いを作成しても、ブラウザでの認証フローを置き換えることはできません。

まず1回認証を完了し、次を確認します。

認証インターフェースが開けるか。
認証完了後に決済フローに戻れるか。
チェックアウトとバックエンドが一致した結果を示すか。

次に新しいテストを開始し、認証インターフェースでキャンセルします。

キャンセル後、ページが支払いを続行するための入口をまだ保持しているか、注文がまだ未払い状態であるかを確認します。本人確認の完了と支払いの完了は2つのチェックポイントです。認証ウィンドウが閉じたかどうかだけを見てはいけません。

認証インターフェースが表示されない場合は、まず対応するテストカードを使用したか、購入者の決済ページを開いたかを確認し、Radarルールが変更されていないか確認します。米国の住所に変更することを認証をトリガーする方法として扱わないでください。

6. ある手順で行き詰まったら、まずどの層かを判断する

チェックアウトのエラーは必ずしもカード番号の問題ではありません。発生場所によってトラブルシューティングを分解します。

症状	最初に確認すること	次の比較
住所フィールドのエラーで送信できない	国、州、ZIPコード、必須フィールド	カード番号は変更せず、エラーのあるフィールドだけを修正する
失敗カードが拒否される	失敗シナリオのカード番号を使用したか	成功カードに切り替えて、支払いが回復できるか確認する
成功カードも失敗する	テスト環境、ページ設定、バックエンドのエラー詳細	同じ条件で新しい決済ページを繰り返す
バックエンドは成功、完了ページはエラー	支払い後のリダイレクトまたはページ設定	支払い記録と対象ページを別々に確認する
認証キャンセル後も支払い済みと表示される	チェックアウトと関連注文のステータス処理	認証完了と認証キャンセルの2つのテストを比較する
最初の支払いは機能するが、失敗後の再試行が機能しない	フォームとボタンの回復状態	「失敗カード→成功カード」の順序を繰り返す

この表は次の確認を判断するために使用するものであり、単一の症状だけから原因を特定できるという意味ではありません。

元のエラーメッセージ、テスト時刻、支払い記録を記録します。スクリーンショットに「問題が発生しました」とだけ書かれていると、後で問題が住所検証、カード拒否、支払い後ページのどれだったかを判断するのが難しくなります。

7. 後で見直せるテスト記録を残す

長いレポートを書く必要はありません。表が1つあれば十分です。

テストシナリオ	ページの結果	バックエンドの結果	関連注文または配信結果
支払い成功	実際に表示された内容を記録	支払いステータスを記録	接続された後続フローを確認
支払い失敗	エラーメッセージを記録	失敗の詳細を確認	支払い済みとしてマークされていないことを確認
失敗後のカード切り替え	再度送信できるか確認	新しい支払いを確認	ステータスが正しく回復するか確認
本人確認を完了	戻りページを確認	最終ステータスを確認	接続された後続フローを確認
本人確認をキャンセル	支払いを続行する入口を確認	実際のステータスを確認	誤って支払い済みと判断されていないことを確認

チェックアウト、支払い後のリダイレクト、注文処理を変更するたびに、この表を使って見直します。

本当にエンドツーエンドで機能する必要があるのは、情報を入力し、支払いを送信し、失敗または認証を処理し、支払い結果を確認し、その後対応する注文操作を完了するというチェーン全体です。1つの「支払い成功」を見ただけでは、チェックアウトの準備ができていることを示すには不十分です。