テストのユースケース
実装をテストする方法について説明します。
テスト環境やサンドボックスなど、Stripe のテスト環境では、実際の請求や支払いを行うことなく、構築したシステムをテストできます。これらの環境は、実際の取引に影響を与えたり、実際の資金を移動させたりせずに、実際のオブジェクトの作成をシミュレートします。Stripe が用意した品質保証 (QA) テストのユースケースを使用して、テストプロセスを支援する Postman コレクションをインポートすることをお勧めします。
テスト環境
In a testing environment, you can charge test credit cards and create test products and prices. These environments let you simulate transactions to make sure that your integration works correctly. This feature helps to identify any bugs or errors in your Stripe implementation before you go live with actual payments. Learn how to decide between using test mode and Sandboxes.
Stripe アカウントを作成すると、Stripe ダッシュボードでテスト API キーのセットを確認できます。これらの API キーを使用して、Stripe API にリクエストを行うことで、シミュレートされたデータを作成・取得できます。実際の支払いの受け付けを開始するには、本番環境利用を申請し、アカウント選択ツールを使用してテスト環境を終了してから、構築したシステムで本番環境の API キーを使用する必要があります。Stripe は実装状態をテストするためのリソースをいくつか用意しています。
テスト環境使用時の本番環境への影響
テスト環境の使用中にダッシュボードで設定を変更した場合、本番環境でもその設定を変更できる場合があります。多くのダッシュボードページには白い通知ボックスがあり、テスト環境では本番環境の設定が無効になります。その状態でもまだ有効になっている設定は、すべて安全に使用できます。白い吹き出しが表示されない場合は、テスト環境で変更すると本番環境の設定に影響すると考えてください (オレンジ色または青色のテストデータバナーが表示されている場合を除く)。
Compare testing environments 
テスト環境とサンドボックスは、実際の取引に影響を与えたり、実際の資金を動かしたりすることなく、実際のオブジェクトの作成をシミュレートできる環境です。それぞれの利用場面がいつなのかを理解することは、テスト戦略を構築する上で有用です。
We recommend using Sandboxes for your testing needs because they offer additional functionality and greater flexibility compared to test mode. By transitioning to Sandboxes, you can enhance your testing capabilities with multiple environments, granular access control, and isolated settings, allowing you to build a more robust and comprehensive testing strategy.
Transition from test mode to Sandboxes
To transition from test mode to Sandboxes in the Dashboard:
- Create a sandbox, then invite the users who need access to it.
- When you grant a team member the Sandbox User role, you’re giving them access to create sandboxes associated with your live business account and delete sandboxes they’ve created. Unlike test mode, where all users had automatic access, only those with the Sandbox User role, Admin roles, Developer role, or Sandbox Admin role can access sandboxes.
- Obtain new test API keys and your account ID for your sandbox.
- Set up relevant testing data such as test products, customers, subscriptions, and payment methods.
- (Optional) Set up test clocks, which help you test your Billing integration to make sure it behaves as expected. When you use test clocks, you simulate the forward movement of time in the sandbox, causing Billing resources such as Subscriptions to change state and trigger webhook events. This allows you to see how your integration handles scenarios, such as a payment failure for a quarterly or annual renewal, without waiting extended periods.
- Update any part of your testing processes that depends on specific test object IDs. This changes when you create new objects in a sandbox.
Differences in functionality between test mode and Sandboxes
以下の表を参照して違いを理解し、ニーズに最も適した環境を選択してください。
テスト環境 | サンドボックス | |
---|---|---|
環境の数 | 1 つの環境を使用可能 | 最大 5 つの環境を使用可能 |
アクセス制御 | 役割を持つすべてのユーザーに同じ役割とアクセス権を付与します。 | アクセスを細かく制御します。これにより、管理者のみが自動的にアクセスできるようになります。ユーザーはサンドボックスにのみ招待され、本番環境にはアクセスできません。 |
設定 | 本番環境とテスト環境の間で設定を共有します。複数の設定を個別にテストすることはできません。 | サンドボックスごとに設定を完全に分離します。作成時に本番環境から設定をコピーし、本番システムとは切り離してテストします。 |
製品の制限事項 | You can’t test IC+ pricing in test mode. | You can’t test IC+ pricing or Issuing, use Sigma, or install Stripe Apps in a sandbox. |
バージョンサポート | V1 のみサポート | V1 と V2 (従量課金やイベントの送信先など) をサポートします。 |
レート制限 | Maintain consistent rate limits. | Maintain consistent rate limits. |
テストカード番号 | Use the same test card numbers. | Use the same test card numbers. |
テスト環境と本番環境の比較
すべての Stripe API リクエストは、テスト環境または本番環境のいずれかで行われます。一方の環境の API オブジェクトには、もう一方の環境からはアクセスできません。たとえば、テスト用の Product オブジェクトを本番環境の支払いに含めることはできません。
タイプ | 使用するタイミング | オブジェクト | 使用方法 | 考慮事項 |
---|---|---|---|---|
sandboxes | Use a sandbox, and its associated test API keys, as you build your integration. In a sandbox, card networks and payment providers don’t process payments. | API コールは、シミュレーションされたオブジェクトを返します。たとえば、テストの account 、payment 、customer 、charge 、refund 、transfer 、balance 、subscription オブジェクトを取得して使用することができます。 | テスト用のクレジットカードとアカウントを使用します。実際の支払い方法を受け付けることも、実際のアカウントを処理することもできません。 | Identity による検証チェックは行われません。また、Connect account (アカウント) オブジェクトは機密フィールドを返しません。 |
本番環境 | 実装を立ち上げて実際の支払いを受け付ける準備ができたら、本番環境と関連する本番 API キーを使用します。本番環境では、カードネットワークとペイメントプロバイダーは決済を処理します。 | API コールは、実際のオブジェクトを返します。たとえば、実際の account 、payment 、customer 、charge 、refund 、transfer 、balance 、subscription オブジェクトを取得して使用することができます。 | 実際のクレジットカードを受け付けて、顧客のアカウントを処理します。クレジットカードとアカウントの実際の支払いのオーソリ、支払い、キャプチャーを受け付けることができます。 | 不審請求の申請のフローはより細かく、テストプロセスはよりシンプルです。また、一部の支払い方法ではフローがさらに細かく、ステップ数が多くなります。 |
ダッシュボードのテスト環境を使用しても、実装コードには影響しません。テスト環境と本番環境の API キーは、コードの動作に影響します。テスト環境と本番環境の API キーは、コードの動作に影響します。
テストカード番号
Stripe は、さまざまな支払いシナリオのシミュレーションに使用できる一連のテストカード番号を提供しています。これらのテストカード番号を使用して、実際の支払いや請求を処理することなく、テスト環境でシミュレートした支払いを作成できます。
テストカード番号を使用すると、任意の将来の有効期限と 3 桁のセキュリティコードを入力して、決済の成功をシミュレーションできます。決済の失敗をシミュレーションする場合は、Stripe が提供する特定のテストカード番号とセキュリティコードを使用できます。
テストカード番号は、テスト環境でのみ有効です。実際の支払いには使用しないでください。
テストデータを削除する
すべてのテストデータを Stripe アカウントから削除するには、次の手順を実行してください。
- 既存の Stripe アカウントを使用してダッシュボードにログインします。
- テスト環境で、開発者 > 概要をクリックします。
- テストデータで、テストデータをレビューをクリックします。ここのダイアログに、既存のすべてのテストデータオブジェクトのリストが表示されます。
- テストデータを削除をクリックして、削除プロセスを開始します。テストデータの削除を取り消すことはできません。
削除プロセスが行われている間、テスト環境は一時的に使用できなくなります。
注
Meters (従量課金) オブジェクトは、自動化されたテストデータの削除プロセスでサポートされていないため、手動で削除する必要があります。
テストメール
デフォルトでは、テスト環境の場合は Stripe から顧客にメールを送信しません。たとえば、サンドボックスで請求書を支払っても、顧客に領収書メールは送信されません。テスト環境で API を使用して請求書を確定した場合も、顧客に領収書メールは送信されません。
テスト環境で Stripe から顧客にメールを送信するように設定する場合は、ダッシュボードで次の操作を実行してください。
- 請求書を作成して特定の顧客に手動で送信します。
- 支払い済みの請求書の領収書を手動で送信します。
メールで請求書や領収書を確認する場合は、Customer
オブジェクトにチームのメールアドレスを設定するか、PaymentIntent に receipt_
属性を設定してください。
ユースケースをテストする
次の表には、品質保証 (QA) テストのユースケースが含まれています。
ユースケース | アクション |
---|---|
支払いの成功 (ただちにキャプチャーする場合) |
|
PaymentIntent オーソリ成功 (売上を後でキャプチャーする) |
|
PaymentIntent キャプチャー成功 (売上をただちにキャプチャーする場合、または後で売上をキャプチャーする場合) |
|
支払いの失敗 | この支払いは、ダッシュボードの支払いに失敗として表示されます。
|
Radar によるブロック | 使用する Radar のバージョンに関係なく、リスクが高いため、またはルールにより、支払いがブロックされる場合があります。レスポンスは、支払いの失敗の場合と同じです。 |
不審請求が申請された支払い |
|
未解決の支払い照会 | 照会は不審請求の申請と似ていますが、主な相違点は、照会が不審請求の申請に発展しない限り、売上が引き落とされないこと、不審請求が申請されるまで返金可能なままであること、およびステータスが異なることです。この場合、 Stripeは、
|
不審請求の申請に対する主張が認められた |
|
不審請求の申請に対する主張が認められなかった | 顧客が不審請求の申請で主張が認められなかった場合、Stripe は、既存の
|
照会に対する主張が認められた | 照会の主張が認められた場合、照会を最初に開始した際に売上が削除されなかったため、残高は変わりません。Stripe は、既存の
|
照会に対する主張が認められなかった |
|
返金済みの支払い | この支払いは、ダッシュボードの支払いに返金済みとして表示されます。
|
一部返金済みの支払い |
|
アカウント残高がマイナスになる | 必ず Stripe でマイナス残高をテストして、銀行口座が Stripe からの引き落としを受け付けられることを確認してください。 |
成功した入金 | 成功した入金 (推奨) に対して Webhook を有効にしている場合は、イベントの処理をテストします。 |
失敗した入金 | 失敗した入金 (推奨) に対して Webhook を有効にしている場合は、イベントの処理をテストします。 |
Stripe の Postman コレクション
Postman は、広く利用されている API 開発ツールです。Stripe の導入をよりシンプルにするために、構築済みシステムのサーバー側コンポーネントをテストする際に必要なツールとともに支払い専用の Postman コレクションをご用意しております。
コレクションをインポートする
まず、Postman アプリにアクセスする必要があります。ブラウザーバージョンまたはデスクトップバージョンを使用できます。アプリを起動したら、コレクションをインポートします。
ウェブでこのプロセスを開始するには、左上隅にあるインポートボタンをクリックしてから、Link オプションをクリックします。Payments コレクションのリンクを貼り付けます。Postman のデスクトップアプリを使用している場合は、File (ファイル) > Import (インポート) をクリックします。正常にインポートされると、Collections (コレクション) の下にコレクションが表示されます。

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

Postman コレクションにシークレットキーを追加する