新機能を構築してテストする

Stripe 開発者ツールを使用して、業務を中断したり、顧客データを危険にさらしたりすることなく、新しい機能を導入できます。このガイドでは、次の方法について説明します。

• サンドボックスを使用して、本番システムに影響を与えずに変更をテストする
• Workbench との連携機能を構築して管理する
• イベントの送信先を使用して Stripe アカウントの主要なアクティビティをリッスンし、ビジネスプロセスを自動化する

あなたは Kavholm という家具会社で働く開発者で、その会社では新しい決済手段の導入を予定しているとします。Kavholm はこの決済手段を導入することで、マーケットリーダーとしての地位を獲得し、顧客満足度を向上させることを目指しています。

サンドボックスを使用したテスト

Kavholm の新しい決済手段のリリースを準備するにあたり、徹底的なテストと監視を行うためにサンドボックスを設定します。この分離された環境を使用することで、本番システムに影響を与えることなく、Stripe の機能を使用して機能をテストできます。アカウントの他のユーザーに影響を与えることなく複数のサンドボックスを作成できるため、開発や継続的インテグレーションのテスト用に分離された環境を管理できます。さらに、次のことができます。

• 支払いシナリオをシミュレーションする: 実際の取引を行わずに、新しい決済手段に関連する支払いプロセスを試します。サンドボックスで構成する設定はテスト環境に分離されたままであるため、本番アカウントには影響しません。
• サンドボックスの構成を選択する: 現実に則したテストを行うために、本番環境のアカウントの設定を反映した事前設定済みのサンドボックスをセットアップするか、または空欄の設定を選択して新しい設定を検討します。詳細はサンドボックスの設定を参照してください。

サンドボックスでの開発

サンドボックスで開発するには、ユースケースに役立つと思われる利用可能な他のオプションの中から、次の機能を使用することを検討してください。

• チーム別のサンドボックス: 開発チームが作業を妨げられることなく決済手段連携の部分に集中できるように、専用のサンドボックスを割り当てます。
• API と Webhook のテスト: payment_intent.succeeded などの決済手段イベントに関連する API コールと Webhook レスポンスをテストして、実装ロジックを検証します。

外部パートナーとの共同作業

ベンダーなどの外部パートナーと共同で作業するには、外部パートナーにサンドボックスユーザーの役割を割り当てて、テスト用に制御されたアクセス権を提供し、本番環境のデータのセキュリティが損なわれないようにします。この役割は、開発会社などの外部パートナーやベンダーに最適です。

デバッグと検証

構築したシステムのデバッグと検証を行うには、次の機能を使用します。

• バグのトラブルシューティングと修正: サンドボックスで API コールまたは実装ロジックの変更をテストして、決済手段ワークフローの問題をデバッグします。
• API キー管理: サンドボックスで安全にリクエストするための API キーを設定し、キー関連のエラーを回避します。

専用サンドボックス

テストシナリオごとに専用のサンドボックスを用意することで、本番環境の運用にリスクを及ぼすことなく、実際の状況をシミュレーションして、機能を監視し、システムの問題をデバッグできます。

たとえば、本番稼働前にすべての決済手段の機能をテストしたり、構築したシステムのパフォーマンスを継続的に監視したり、同等のテスト環境で精査した変更点を実装したりすることができます。

始めるには、Stripe ダッシュボードのアカウントピッカーメニューに移動し、作成ボタンを選択してサンドボックスを作成します。各サンドボックスには名前が必要で、実際の状況を反映するために本番環境のアカウントから設定をコピーできます。

専用のサンドボックスを使用すると、開発、統合テスト、ユーザー受け入れテスト (UAT) などのさまざまな段階を経て、新しい決済手段などの新機能をテストできます。そうすることで、本番環境に影響を与えることなく、各段階で徹底的にチェックできます。

Workbench を使用してシステムを構築して管理する

ダッシュボードで直接 Workbench を使用して、構築した Stripe システムのデバッグや管理をブラウザーから行うことができます。

次のビューを使用して、決済手段の機能を管理します。

• 概要：

  • 新しい決済手段が最新かつ最も堅牢な API バージョンを使用していることを確認します。
  • 決済手段の手数料計算に関する API リクエストを監視して、期待どおりに機能することを確認します。
  • 決済手段に関連する実装エラーを特定します。

• エラー：

  • 決済手段の計算または決済処理におけるエラーを特定して分類します。
  • エラーの頻度を追跡して、影響と緊急性を把握します。

• Inspector：

  • API オブジェクトの構成を分析し、リアルタイムで問題をトラブルシューティングします。

• ログ：

  • API リクエストをフィルターで絞り込んで、インタラクションが期待どおりであることを確認します。

• イベント：

  • イベントをフィルターで絞り込んで、ロジスティックトリガーを確認します。
  • イベントペイロードを確認して、バックエンド処理が正しいことを確認します。

• Webhook:

  • Webhook エンドポイントまたは Amazon EventBridge などの他の送信先タイプを設定して、決済手段のステータスと支払いの確認をリアルタイムで更新します。

• シェルと API Explorer:

  • API リクエストをシミュレーションし、コマンドラインインターフェイスを使用して管理します。

イベントの送信先を使用してリアルタイムの更新をリッスンする

Kavholm では、イベントの送信先を使用して、本番システムに影響を与えることなく、すべての決済手段の機能が意図したとおりに機能することを確認します。イベントの送信先を使用して、Stripe アカウントのリアルタイムのアクティビティを追跡し、支払いの確認やサブスクリプションの更新などの重要なイベントに対応します。以下の操作が可能です。

• Amazon EventBridge を介して AWS にイベントを送信するか、Webhook を介して HTTPS エンドポイントにイベントを送信します。
• thin イベントまたはスナップショットイベントを使用してリアルタイムデータにアクセスします。

テスト

実際の状況をシミュレーションし、決済手段のパフォーマンスを本番稼働前に評価するには、次のようにします。

• Stripe が生成するイベントをシミュレーションして、サンドボックスで決済手段機能をテストします。
• テスト Webhook を設定して、実際の顧客に影響を与えることなくイベント処理を監視します。

リアルタイムの更新に対応する

主要なイベントを追跡し、決済手段機能が継続的に機能していることを常時監視するには、次のようにします。

• payment_intent.succeeded などのイベントを集計してアラートを送信するようにイベントの送信先を設定します。イベントの送信先は、Webhook エンドポイントまたは Amazon EventBridge でのアラートの受信をサポートしています。
• 支払いイベント履歴を表示して、決済手段のプロセスのトラブルシューティングを行い、イベント配信を追跡します。ログを使用してデバッグします。特に、API リクエストログではなくイベントログに重点を置く場合はこの方法で行ってください。

デバッグ

リアルタイムのイベント分析を通じて問題を特定して解決し、Kavholm の顧客にサービスを中断することなく提供できるようにします。

• 請求や決済手段の問題を素早く特定して、特定のイベント通知で顧客に警告します。
• 決済手段処理のリアルタイム分析に thin イベントを使用します。

Kavholm はイベントの送信先を使用して、中断を最小限に抑えながら新しい決済手段のテスト、監視、デバッグを行います。