ユースケースをテストする
導入をテストする方法をご紹介します。
Stripe のテスト環境、テストモード、サンドボックスを使用すると、実際の請求や決済を行わずに導入をテストできます。これらの環境では、実際の取引に影響を与えたり、実際の資金を移動したりすることなく、実際のオブジェクトの作成をシミュレーションできます。テストプロセスに役立つように、品質保証 (QA) テストのユースケースを使用し、Postman コレクションをインポートすることをお勧めします。
テスト環境
テスト環境では、テスト用のクレジットカードに請求し、テスト用の商品と価格を作成できます。これらの環境では、取引をシミュレーションして、導入が正しく機能することを確認できます。この機能は、本番環境へ移行する前に、Stripe 導入のバグやエラーを特定するのに役立ちます。テストモードとサンドボックスのどちらを使用するかを判断する方法についてご確認ください。
Stripe アカウントを作成すると、Stripe ダッシュボードに一連のテスト API キーが表示されます。これらの API キーを使用して、Stripe API に対するリクエストを行うことで、シミュレーションデータを作成して取得できます。実際の決済の受け付けを開始するには、アカウントを有効化し、アカウント選択機能を使用してテスト環境を終了し、導入で本番 API キーを使用する必要があります。Stripe は、導入をテストするためのリソースを多数提供しています。
テスト環境使用時の本番環境への影響
ダッシュボードでは、テスト環境で設定を変更すると、本番環境でも設定が変更される場合があります。ダッシュボードのページの多くに白色の通知ボックスがあり、テスト環境では本番環境の設定は無効になっています。この場合、有効になっている設定は安全に使用できます。白色のコールアウトがない場合は、オレンジ色または青色のテストデータバナーが表示されていない限り、テスト環境で変更を行うと、本番環境の設定に変更が反映されるものとご理解ください。
テスト環境の比較
テスト環境とサンドボックスは、実際の取引に影響を与えたり、実際の資金を移動したりすることなく、実際のオブジェクトの作成をシミュレーションするテスト環境です。それぞれを使用するタイミングを理解することで、テスト戦略の構築に役立ちます。
サンドボックスは、追加機能とテスト環境よりも優れた柔軟性を備えているため、テストのニーズに合わせて使用することをお勧めします。サンドボックスに移行すると、複数の環境、詳細なアクセス制御、分離された設定を使用してテスト機能を強化し、より堅牢で包括的なテスト戦略を構築できます。
テスト環境とサンドボックスの機能の違い
以下の表を参照して、違いを理解し、ニーズに最適な環境を選択してください。
テスト環境 | サンドボックス | |
---|---|---|
環境の数 | 1 つの環境を使用する | 最大 5 つの環境を使用 |
アクセス制御 | 役割を持つすべてのユーザーに同じ役割とアクセス権を付与します。 | アクセスの詳細な制御を実行します。管理者のみが自動的にアクセスできます。本番環境にはアクセスできないサンドボックスのみにユーザーを招待します。 |
設定 | 本番環境とテスト環境間で設定を共有します。多くの設定を個別にテストすることはできません。 | サンドボックスごとに設定を完全に分離します。作成時に本番環境から設定をコピーし、本番導入とは別にテストします。 |
製品の制限 | テスト環境で IC+ の料金体系をテストすることはできません。 | サンドボックスで IC+ の料金体系をテストすることはできません。 |
バージョンサポート | V1 のみをサポート | V1 および V2 をサポートします(従量課金、イベントの宛先などの製品を含む)。 |
レート制限 | 一貫したレート制限を維持します。 | 一貫したレート制限を維持します。 |
テストカード番号 | 同じテストカード番号を使用します。 | 同じテストカード番号を使用します。 |
テスト環境からサンドボックスへの移行
ダッシュボードでテスト環境からサンドボックスに移行するには、以下のようにします。
- サンドボックスを作成し、そのサンドボックスへのアクセスを必要とするユーザーを招待します。
- サンドボックスユーザー役割をチームメンバーに付与すると、本番ビジネスアカウントに関連付けられたサンドボックスを作成し、作成したサンドボックスを削除するためのアクセス権がチームメンバーに付与されます。テスト環境では、すべてのユーザーに自動的にアクセスできましたが、サンドボックスユーザー役割、管理者役割、開発者役割、サンドボックス管理者役割が付与されたユーザーのみがサンドボックスにアクセスできます。
- サンドボックスの新しいテスト API キーとアカウント ID を取得します。
- テスト製品、顧客、サブスクリプション、決済手段など、関連するテストデータを設定します。
- (オプション) テストクロックを設定します。これは、Billing の導入をテストして、想定どおりに動作することを確認するのに役立ちます。テストクロックを使用すると、サンドボックスで時間の進行をシミュレーションし、サブスクリプションなどの Billing リソースの状態が変化し、Webhook イベントがトリガーされます。これにより、四半期ごとまたは年次の更新の決済失敗などのシナリオを、長期間待つことなく導入がどのように処理するかを確認できます。
- テストプロセスのうち、特定のテストオブジェクト ID に依存する部分を更新します。これは、サンドボックスで新しいオブジェクトを作成するときに変更されます。
テスト環境と本番環境
Stripe API リクエストはすべて、テスト環境か、 本番環境 のいずれかで発生します。一方の環境の API オブジェクトには、もう一方の環境からアクセスできません。たとえば、テスト環境のProduct (商品) オブジェクトを本番環境の決済の一部にすることはできません。
タイプ | 使用するタイミング | オブジェクト | 使用方法 | 考慮事項 |
---|---|---|---|---|
サンドボックス | サンドボックスと関連するテスト API キーを使用してシステムを構築します。サンドボックスでは、カードネットワークとペイメントプロバイダーは決済を処理しません。 | API コールは、シミュレーションされたオブジェクトを返します。たとえば、テストの account 、payment 、customer 、charge 、refund 、transfer 、balance 、subscription オブジェクトを取得して使用することができます。 | テスト用のクレジットカードとアカウントを使用します。実際の支払い方法を受け付けることも、実際のアカウントを処理することもできません。 | Identity による検証チェックは行われません。また、Connect account (アカウント) オブジェクトは機密フィールドを返しません。 |
本番環境 | 実装を立ち上げて実際の支払いを受け付ける準備ができたら、本番環境と関連する本番 API キーを使用します。本番環境では、カードネットワークとペイメントプロバイダーは決済を処理します。 | API コールは、実際のオブジェクトを返します。たとえば、実際の account 、payment 、customer 、charge 、refund 、transfer 、balance 、subscription オブジェクトを取得して使用することができます。 | 実際のクレジットカードを受け付けて、顧客のアカウントを処理します。クレジットカードとアカウントの実際の支払いのオーソリ、支払い、キャプチャーを受け付けることができます。 | 不審請求の申請のフローはより細かく、テストプロセスはよりシンプルです。また、一部の支払い方法ではフローがさらに細かく、ステップ数が多くなります。 |
ダッシュボードのテスト環境が、導入のコードに影響を与えることはありません。コードの動作に影響を与えるのは、テスト環境と本番環境の API キーです。
テストカード番号
Stripe は、さまざまな決済シナリオのシミュレーションに使用できる一連のテストカード番号を提供しています。これらのテストカード番号を使用すると、実際の決済や請求を処理することなく、シミュレーション用の決済をテスト環境で作成できます。
テストカード番号を使用すると、任意の将来の有効期限と 3 桁のセキュリティコードを入力して、決済の成功をシミュレーションできます。決済の失敗をシミュレーションする場合は、Stripe が提供する特定のテストカード番号とセキュリティコードを使用できます。
テストカード番号はテスト環境でのみ有効です。実際の決済には使用しないでください。
テストデータを削除する
すべてのテストデータを Stripe アカウントから削除するには、次の手順を実行してください。
- 既存の Stripe アカウントを使用してダッシュボードにログインします。
- テスト環境で、開発者 > 概要をクリックします。
- テストデータセクションで、テストデータをレビューをクリックします。このダイアログに、既存のすべてのテストデータオブジェクトのリストが表示されます。
- テストデータを削除をクリックして、削除プロセスを開始します。テストデータの削除を取り消すことはできません。
削除プロセスの実行中は、テスト環境が一時的に使用できなくなります。
注
Meters オブジェクトは、自動化されたテストデータの削除プロセスでサポートされていないため、手動で削除する必要があります。
テストメール
デフォルトでは、Stripe はテスト環境で顧客にメールを送信しません。たとえば、サンドボックスで請求書への決済を行うと、顧客に領収書のメールは送信されません。また、テスト環境で API を使用して確定された請求書についても、顧客に領収書メールは送信されません。
テスト環境で Stripe から顧客にメールを送信したい場合は、ダッシュボードで以下を実行できます。
- 請求書を作成して特定の顧客に手動で送信します。
- 決済済みの請求書の領収書を手動で送信します。
メールで請求書や領収書を確認する場合は、顧客
オブジェクトにチームのメールアドレスを設定するか、PaymentIntent に receipt_
属性を設定してください。
ユースケースをテストする
次の表には、品質保証 (QA) テストのユースケースが含まれています。
ユースケース | アクション |
---|---|
請求の成功 (ただちにキャプチャーする場合) |
|
PaymentIntent オーソリ成功 (売上を後でキャプチャー) |
|
PaymentIntent キャプチャー成功 (売上の即時キャプチャーまたは売上のキャプチャー) |
|
請求の失敗 | 請求は、ダッシュボードの決済の下に失敗として表示されます。
|
Radar によるブロック | 使用する Radar のバージョンに関係なく、リスクが高いため、またはルールにより、請求がブロックされる場合があります。レスポンスは、請求の失敗の場合と同じです。 |
不審請求が申し立てられた請求 |
|
未解決の請求照会 | 照会は不審請求の申し立てと似ていますが、主な相違点は、照会が不審請求の申し立てに発展しない限り、売上が引き落とされないこと、不審請求が申し立てられるまで返金可能なままであること、およびステータスが異なることです。この場合、Stripe は、
|
不審請求の申し立てに対する主張が認められた |
|
不審請求の申し立てに対する主張が認められなかった | 顧客が不審請求の申し立てで主張が認められなかった場合、Stripe は、既存の
|
照会に対する主張が認められた | 照会で勝訴した場合、照会を最初に開始した際に売上が削除されなかったため、残高は変わりません。Stripe は、既存の
|
照会に対する主張が認められなかった |
|
返金済みの請求 | 請求は、ダッシュボードの決済の下に返金済みとして表示されます。
|
一部返金済みの請求 |
|
アカウント残高がマイナスになる | 必ず Stripe でマイナス残高をテストして、銀行口座が Stripe からの引き落としを受け付けられることを確認してください。 |
成功した入金 | 入金成功時に Webhook を有効にする場合は (推奨)、イベントの処理内容をテストします。 |
失敗した入金 | 入金失敗に対して Webhook を有効にする場合 (推奨)、イベントの処理内容をテストします。 |
Stripe の Postman コレクション
Postman は、広く利用されている API 開発ツールです。Stripe の導入をよりシンプルにするために、導入のサーバー側コンポーネントをテストする際に必要なツールとともに決済専用の Postman コレクションをご用意しております。
コレクションをインポートする
まず、Postman アプリにアクセスする必要があります。ブラウザバージョンまたはデスクトップバージョンを使用できます。アプリを起動したら、コレクションをインポートします。
Web でこのプロセスを開始するには、左上隅にあるインポートボタンをクリックしてから、Link オプションをクリックします。Payments コレクションの Link を挿入します。Postman のデスクトップアプリを使用している場合は、File (ファイル) > Import (インポート) をクリックします。正常にインポートされると、Collections の下にコレクションが表示されます。

インポートダイアログ
回収を使用する
コレクションを使用するには、先ほどインポートしたコレクションに移動して、Variables (変数) をクリックします。テスト環境の Stripe シークレットキーを Stripe ダッシュボードからコピーして、Initial Value (初期値) フィールドに貼り付けます。この手順が完了すると、リクエストの実行準備が整います。
他の変数は、回収の実行時にスクリプトによって入力されます。たとえば、顧客、価格、請求、PaymentIntent を作成する場合は、システムは、回収のスクリプトを使用してその ID を保存し、返金の発行などの後続のリクエストで使用できるようにします。

Postman 回収にシークレットキーを追加する