Stripe Billing のテスト

Billing の組み込みのテスト方法をご紹介します。

システムを顧客に表示したり、本番環境のアクティビティーに使用する前に、システム全体をテストする必要があります。組織のガイドライン (ランブック、品質ゲート、または開発チェックリスト) に加えてこのページのリソースを使用すると、システムが本番環境に対応しているかどうかを判断しやすくなります。

本番環境への移行の原則

組み込みを本番環境に移行する前に、次の Stripe チェックリストを確認してください。

一般的な組み込みフローを次に示します。

サブスクリプションと経常収益の組み込みでは、少なくとも次のコンポーネントが想定通りに動作することを確認してください。

次の表は、コンポーネントごとのイベント通知をリストしたものです。Webhook でこれらのイベントをリッスンするように組み込みを設定できます。このガイドでイベント通知とテストの詳細をご確認ください。

コンポーネント	説明	イベント
顧客の登録	Stripe で顧客レコードを作成するために必要な情報をシステムが正常に収集できることを確認します。顧客は、Payment Links、Checkout、Elements、または Stripe API で構築されたフルカスタムの決済フォームを使用して、その情報を入力できます。どのフォームを使用する場合でも、必ず Stripe に保存されている Customer オブジェクトを確認するようにしてください。ダッシュボードまたは API を使用して、Customer の表示と管理を行うことができます。	`customer.created` `customer.subscription.created`
請求書作成	サブスクリプションによって、各請求サイクルの終了時に請求書が作成されます。支払いの回収方法に応じて、後払いでの支払い回収や自動請求の確定のために請求書を送信できます。構築済みのシステムで想定どおりに請求書が作成され送信されることを確認してください。サブスクリプションの請求書の作成と管理について、詳細はガイドをご覧ください。テストクロックを使用して、請求書の作成と送付を含む、請求サイクルのシミュレーションを実行できます。テストクロックのガイドで、特定のユースケースのテストについてご確認ください。	`invoice.created` `invoice.finalized` `invoice.finalization_failed` `invoice.paid` `invoice.payment_action_required` `invoice.payment_failed` `invoice.upcoming` `invoice.updated`
サブスクリプションの管理	カスタマーポータルを設定することで、顧客はサブスクリプションと請求情報を管理できるようになります。これをテストするには、まずサンドボックスでサブスクリプションを作成します。次に、テストユーザーとしてポータルにログインし、サブスクリプションを更新します。ダッシュボードまたは API をチェックして、サブスクリプションに顧客の変更が反映されているかどうかを確認します。カスタマーポータルの設定方法については、実装ガイドをご確認ください。	`customer.subscription.deleted` `customer.subscription.paused` `customer.subscription.resumed` `customer.subscription.updated`
トライアル	顧客にサービスのトライアルを提供します。トライアルが正しく設定されていることを確認するには、テストクロックを作成できます。サブスクリプションはトライアル期間へのゼロ値の請求書を生成します。テストクロックでトライアルをテストする方法をご覧ください。トライアルの仕組みの詳細については、サブスクリプションのトライアルガイドをご確認ください。	`customer.subscription.trial_will_end` `customer.subscription.updated`
支払いの失敗	顧客からの支払いは数多くの理由により失敗します。組み込みが、支払いのリトライなど、失敗に対処できることを確認します。支払いの失敗をテストする方法をご覧ください。	`invoice.finalization_failed` `invoice.payment_failed` `invoice.payment_action_required`

テストクロック

テストクロックを使用すると、サブスクリプションなどの Billing オブジェクトをサンドボックスで経時的にシミュレートできるため、年次更新による支払い失敗がシステムでどのように処理されるかを確認するために、1 年待つ必要はありません。テストクロックにコードの記述は必要なく、ダッシュボードでシミュレーションを作成できます。または、API でアクセスすることも可能です。テストクロックと一般的なユースケースについてご紹介します。

サブスクリプションのトライアル期間をテストする

まず、以下の手順でテストクロックの使用を開始します。

次に、テストクロックを使用してトライアルのテストを開始できます。たとえば、顧客に支払いを開始する前に 7 日間のトライアルで商品を無料で試してもらい、決済情報は事前に収集するとします。テストクロックを使用してこの状況をシミュレーションするには、以下のようにします。

新しいテストクロックを作成して frozen_time を 1 月 1 日に設定します。
顧客を追加して支払い方法を含めます。ここでは、のテストカードを使用します。
サブスクリプションを作成して、7 日間無料のトライアル期間を追加します。

ダッシュボードから既存のサブスクリプションにトライアル期間を追加するには、以下を行います。

変更するサブスクリプションを探します。

アクションをクリックします。
サブスクリプションを更新をクリックします。
無料トライアルを追加をクリックして、無料トライアルの日数フィールドに 7 を入力します。
サブスクリプションを更新をクリックします。

7 日間無料のトライアル期間を設けてサブスクリプションを作成すると、サブスクリプションが trialing 状態で作成されます。無料トライアルであるため、$0.00 の請求書が生成されます。
日付を 1 月 5 日に進めて、customer.subscription.trial_will_end のイベント通知を確認します。Stripe はトライアル終了の 3 日前に通知を送信します。この Webhook イベントを使用して、トライアルがまもなく終了することを顧客に通知できます。
日付を 1 月 8 日に進めて、サブスクリプションが paid になり、50 USD の請求書が作成されたことを確認します。
サイクルを 1 つ (月次サブスクリプションの場合は 2 月 8 日まで) 進めて、サブスクリプションが更新されることを確認します。

テストクロックなしでトライアル期間をテストする

サブスクリプションの Webhook 通知をテストする

サブスクリプションの組み込みは Webhook に強く依存しています。サーバーで Webhook エンドポイントを設定し、リッスンするイベント通知を指定します。Stripe は、サブスクリプションのアップグレードやキャンセルなどのイベントへの通知を送信します。

Webhook をテストするには、実際のテストサブスクリプションを作成するか、Stripe CLI またはダッシュボードを使用してイベント通知をトリガーします。

Stripe CLI を設定し、Stripe アカウントに関連付けてから、サブスクリプションのライフサイクルでイベントをトリガーして、Webhook の組み込みをテストできます。Stripe CLI を使用してイベントをトリガーする場合、サーバーでイベント通知の着信を確認できます。これにより、ネットワークトンネルやファイアウォールを介することなく、Webhook の組み込みを直接確認できます。

Stripe CLI またはダッシュボードを使用してイベントをトリガーすると、Webhook が受信するイベントには、サブスクリプション情報と関連がない架空のデータが格納されます。Webhook 通知をテストする最も信頼できる方法は、実際のテストサブスクリプションを作成し、対応するイベントを処理することです。

以下の表には、サブスクリプションに関連する最も一般的なイベントと、該当する場合は、それらのイベントを処理するための推奨アクションが示されています。



`customer.created`	Customer (顧客)の作成に成功すると送信されます。
`customer.subscription.created`	サブスクリプションが作成されると送信されます。支払いを完了するために顧客の認証が必要な場合、または `payment_behavior` を `default_incomplete` に設定した場合、サブスクリプションの `status` が `incomplete` になります。詳しくは、サブスクリプションの支払い処理をご覧ください。
`customer.subscription.deleted`	顧客のサブスクリプションが終了すると送信されます。
`customer.subscription.paused`	サブスクリプションの `status` が `paused` に変わると送信されます。たとえば、支払い方法が指定されないまま無料トライアルが終了した場合に一時停止するようサブスクリプションが設定されている場合に送信されます。サブスクリプションが再開されるまで請求書は作成されません。支払いの回収が一時停止されている場合、その期間中も請求書は引き続き作成されるため、このイベントは送信されません。
`customer.subscription.resumed`	以前に `paused` ステータスであったサブスクリプションが再開されると送信されます。支払いの回収の一時停止が解除された場合は、これに該当しません。
`customer.subscription.trial_will_end`	トライアル期間終了の 3 日前に送信されます。トライアル期間が 3 日未満の場合、このイベントがトリガーされます。
`customer.subscription.updated`	サブスクリプションが開始または変更された場合に送信されます。たとえば、サブスクリプションの更新、クーポンの追加、割引の適用、請求書アイテムの追加、プランの変更はすべて、このイベントのトリガーとなります。
`entitlements.active_entitlement_summary.updated`	顧客の有効なエンタイトルメントが更新されると送信されます。このイベントを受け取ると、商品の機能へのアクセスをプロビジョニングまたはデプロビジョニングすることができます。エンタイトルメントの導入の詳細をご覧ください。
`invoice.created`	新規または更新済みのサブスクリプションに対して請求書が作成されると送信されます。Stripe で `invoice.created` に対する成功レスポンスを受信できない場合、自動請求で指定されたすべての請求書の確定が最大 72 時間遅延します。詳しくは、請求書の確定をご覧ください。 Finalize an Invoice (請求書の確定) API にリクエストを送信することで通知に応答します。
`invoice.finalized`	請求書の確定に成功し、支払いの準備が整うと送信されます。顧客に請求書を送信できます。詳しくは、請求書の確定をご覧ください。設定に応じて、Stripe は自動的にデフォルトの支払い方法に請求するか、回収を試みます。詳しくは、確定後のメールをご覧ください。
`invoice.finalization_failed`	請求書を確定することができませんでした。ガイドを参照して、請求書の確定失敗を処理する方法をご確認ください。請求書の概要ガイドに記載されている請求書の確定を確認してください。 Invoice の last_finalization_error を調べて、エラーの原因を判別します。 Stripe Tax を使用している場合、Invoice オブジェクトの automatic_tax フィールドを確認します。 `automatic_tax[status]=requires_location_inputs` の場合、請求書を確定させることはできず、支払いを回収できません。顧客に通知し、必要な顧客の場所を収集します。 `automatic_tax[status]=failed` の場合、後でリクエストを再試行します。
`invoice.paid`	請求書の支払いに成功すると送信されます。このイベントを受け取り、サブスクリプションの `status` が `active` になると、商品へのアクセスを提供できます。
`invoice.payment_action_required`	請求書に顧客の認証を必要とする場合に送信されます。請求書でアクションが必要な場合にサブスクリプションを処理する方法をご紹介します。
`invoice.payment_failed`	請求書に対する支払いが失敗しました。PaymentIntent のステータスは `requires_action` に変わります。サブスクリプションのステータスは、サブスクリプションの最初の請求書に対して「のみ」`incomplete` のままになります。支払いが失敗した場合、以下のような処理を行います。顧客に通知します。サブスクリプションの設定を構成し、Smart Retries とその他の売上回収機能を有効にする方法をご紹介します。 PaymentIntent を使用している場合、新しい支払情報を収集し、PaymentIntent を確定します。サブスクリプションの default payment method (デフォルトの支払い方法) を更新します。
`invoice.upcoming`	サブスクリプションの更新の数日前に送信されます。何日前に送信されるかについては、ダッシュボードの次回の更新イベントに設定された数値を参照します。既存のサブスクリプションについては、日数の変更は次の請求期間から有効になります。必要に応じて、追加の請求書アイテムを加えることもできます。
`invoice.updated`	支払いが成功または失敗したときに送信されます。支払いが成功の場合には、`paid` 属性が `true` に、`status` が `paid` に設定されます。支払いが失敗の場合には、`paid` が `false` に、`status` は `open` のままになります。また、支払いの失敗は、`invoice.payment_failed` イベントもトリガーします。
`payment_intent.created`	PaymentIntent が作成されると送信されます。
`payment_intent.succeeded`	PaymentIntent が正常に支払いを完了すると送信されます。
`subscription_schedule.aborted`	サブスクリプションスケジュールが、支払いの滞納により関連するサブスクリプションが終了となったことが原因でキャンセルされた場合に送信されます。
`subscription_schedule.canceled`	サブスクリプションスケジュールがキャンセルされ、それに関連するアクティブなサブスクリプションもキャンセルされた場合に送信されます。
`subscription_schedule.completed`	サブスクリプションスケジュールのすべてのフェーズが完了した場合に送信されます。
`subscription_schedule.created`	新しいサブスクリプションスケジュールが作成された場合に送信されます。
`subscription_schedule.expiring`	サブスクリプションスケジュールが無効になる 7 日前に送信されます。
`subscription_schedule.released`	サブスクリプションスケジュールがサブスクリプションからリリースされたとき、または停止され関連付けが解除されたときに送信されます。サブスクリプションはその後も残ります。
`subscription_schedule.updated`	サブスクリプションスケジュールが更新された場合に送信されます。

支払いの失敗をテストする

特定のテストクレジットカード番号を使用して、サブスクリプションと請求書の支払いの失敗をトリガーします。

一部のサブスクリプションの更新により、Stripe はサブスクリプションの請求書を作り、すぐに支払いを行います (この同期支払いは、初回の請求書または特定の請求書の更新で発生する可能性があります)。この試行が失敗した場合、サブスクリプションは incomplete ステータスで作成されます。

有効なサブスクリプションに対して支払いの失敗が及ぼす影響をテストするには、顧客のデフォルトの支払い方法として 4000 0000 0000 0341 のカードを関連付け、支払いを延期するためにトライアル期間を使用します (数秒または数分のトライアルで十分です)。サブスクリプションは即座に有効になり、トライアルの終了時に draft 状態の請求書が作成されます。請求書のステータスは約 1 時間で open に変わり、この時点で支払いの回収が試行され、失敗します。

テストクロックを使用すると、サンドボックスで時間の早送りをシミュレートし、サブスクリプションなどの Billing リソースの状態を変化させて Webhook イベントをトリガーすることができます。これにより、1 年を待たずに、システムが四半期または年次の更新で支払い失敗をどのように処理するかを確認できます。

3D セキュアを必要とする支払いをテストする

4000 0027 6000 3184 カードを使用して、サブスクリプションと請求書の 3D Secure トリガーをシミュレーションします。

3D セキュア認証フローがトリガーされると、開いた 3DS ダイアログで支払いの認証または失敗をテストできます。支払いが正常に認証されると、請求書が支払われます。請求書が incomplete ステータスであるサブスクリプションに属する場合、そのサブスクリプションは有効になります。支払いの試行が失敗すると、認証が成功せず、請求書は open のままになります。

請求書に対する銀行振込による支払いをテストする

銀行振込による請求書の手動支払いをテストする手順は、以下のとおりです。

サンドボックスで請求書を作成し、回収方法を send_invoice に設定した後、payment_settings[payment_method_types] 配列を [customer_balance] に設定します。
ダッシュボードで請求書を見つけ、送信をクリックします。
お客様の顧客が固有の仮想銀行口座番号を割り当てられると、その番号は Funding Instructions API を使って取得できます。オンライン請求書ページや PDF でもこの仮想銀行口座番号の詳細を確認することができます。

インボイスとサブスクリプションのデフォルトの決済手段をテスト

特定のテストカード IDを使用して、サブスクリプションとインボイスに使用されるデフォルトの決済手段をシミュレーションします。

指定した支払い方法は、default_payment method として設定しているサブスクリプションまたはインボイスの顧客に関連付ける必要があります。たとえば、pm_card_visa を使用して Visa のテスト用の決済手段を作成する場合は、以下のようにします。

pm_card_visa と、サブスクリプションまたはインボイスの対象の顧客を指定して、PaymentMethod Attach エンドポイントを呼び出します
結果として得られた決済手段 ID を使用し、この ID を default_payment_method と指定してサブスクリプションまたはインボイスを作成します。

ここで、サブスクリプションまたはインボイスでこの決済手段に請求します。

サブスクリプションとインボイスにデフォルトの決済手段を使用する方法をご紹介します。

顧客の納税者番号確認をテストする

これらの Magic tax ID を使用して、テスト環境で特定の確認条件をトリガーします。納税者番号タイプは、EU VAT 番号またはオーストラリア事業者登録番号 (ABN) のいずれかである必要があります。

番号	タイプ
`000000000`	本人確認成功
`111111111`	本人確認に失敗
`222222222`	確認は無期限に保留中のままになります

自動化されたテスト

実装に自動化されたテストを設定できます。テストを最適化するには、以下のようにします。

サンドボックス内のサブスクリプション関連データについては、データ保持ポリシーが適用されることに注意してください。
テスト間でクーポンやプロモーションコードなどのリソースを再利用することは避けてください。
stripe-mock HTTP サーバーを使用します。これは、Stripe API を使用し API の動作をよく反映します。

注