Amazon EventBridge にイベントを送信する
AWS インフラで Stripe イベントを使用します。
ワークベンチを有効にする
Amazon EventBridge にイベントを送信するには、ダッシュボードの開発者向け設定でワークベンチを有効にします。
ワークベンチにイベントの送信先タブが表示されない場合は、プロダクトのプレビューの設定で有効にします。
Amazon EventBridge は、AWS が提供するサーバーレスの、イベント駆動型サービスです。イベントを取り込み、変換し、送信することでアプリケーションを統合できます。イベントの送信先を使用する EventBridge を導入することで、Stripe からのイベントデータを AWS アカウントで直接受け取ることができるようになります。ご自身でトラフィックの処理し、導入のコードロジックを管理する必要はありません。イベントを受信すると、EventBridge はイベントを 20 以上のサポートターゲットに振り分けて処理するか、ビジネスの自動化を開始できます。
Amazon EventBridge にイベントを送信する
以下のステップを実行して、EventBridge でイベントを受信します。手順には、ワークベンチでの新しいイベントの作成と、AWS 管理コンソールでの EventBridge の設定が含まれています。
警告
各ステップを完了するまでは、Amazon EventBridge でイベントデータを受信しません。
パートナーイベントソースを関連付けるAWS コンソール
イベントの送信先を設定すると、Stripe は設定時にお客様が指定した AWS アカウントとリージョンにパートナーイベントソースを作成します。イベントの受信を開始するには、イベントの送信先を作成してから 7 日以内にこのイベントソースをイベントバスに関連付ける必要があります。この期間内に関連付けなかった場合、Amazon は保留中のイベントソースを自動的に削除します。イベントソースが削除されると、Stripe のイベントの送信先は自動的に無効になり、イベントを受信するには新しい送信先を作成する必要があります。
- AWS コンソールの EventBridge の下で、左側のパネルの統合セクションに表示されているパートナーイベントソースページに移動します。
- コンソール上部にあるリージョンドロップダウンリストを使用して、ワークベンチでイベントの送信先を設定したときに選んだリージョンを選択します。
- ドロップダウンから、新しく作成されたパートナーイベントソースを選択します。ワークベンチのイベントソース ARN を検索するには、イベントの送信先を選択します。パートナーソースは
event-source/aws.
という ARN と部分的に一致しています。次に、イベントバスと関連付けるをクリックします。partner/stripe. com/{UNIQUE_ ID}
- 必要に応じて、このイベントバスに付与するアクセス許可を選択し、関連付けるをクリックします。
EventBridge ルールを作成するAWS コンソール
EventBridge では、お客様が定義するルールに基づきイベントがグループ化され、振り分けられます。イベントの送信先を作成し、そのパートナーイベントソースをイベントバスに関連付けた後で、イベントバスで受信したイベントの処理方法を EventBridge に確実に伝えるために、ルールを定義する必要があります。以下のステップを複数回繰り返して、複数のルールを定義できます。
- AWS マネジメントコンソールに移動して、ルールをクリックします。
- ルールを作成をクリックして、ルールの名前と説明を指定します。
- ドロップダウンからイベントバスを選択します。イベントバスを見つけるには、ワークベンチに移動してイベントの送信先タブで送信先を選択してから、イベントソース ARN フィールドを表示します。これはイベントソース ARN と同じ名前になります。次へをクリックします。
- Stripe イベントはパートナーイベントなので、イベントソースの下で AWS イベントまたは EventBridge パートナーイベントを選択します。
- 「(オプション)」サンプルの Stripe イベントを含めます。
- 作成のメソッドで、パターンフォームを使用するを選択して、事前定義されたパターンを使用します。あるいは、カスタムのイベントパターンを作成することもできます。
- イベントパターンの下で、イベントソースとして EventBridge パートナーを選択します。
- イベントパターンの下で、パートナーとして Stripe を選択します。
- ルールを作成する適切なイベントタイプを選択するか、すべてのイベントを選択して、このルールをすべてのイベントタイプに適用し、次へをクリックします。
- このルールでイベントを送信するターゲットを選択して、次へをクリックします。
推奨事項
Stripe は、各イベントバスで CloudWatch ログターゲットを作成して、イベントの送信先の監視を有効にすることをお勧めしています。その他の一般的なアーキテクチャーパターンを EventBridge および Stripe イベントとともに使用することを検討してください。
- オプションのタグを追加して、次へをクリックします。
- ルールを確認し、必要に応じて変更を加えたら、ルールを作成をクリックします。
これで、Stripe イベントは、EventBridge とルールで定義された対応するターゲットに正常に送信されます。
テストイベントをトリガーする
テストイベントを送信するには、Stripe ダッシュボードでオブジェクトを手動で作成し、Webhook が登録されているイベントタイプをトリガーします。あるいは、Stripe Shell または Stripe CLI で次のコマンドを使用できます。
この例では、payment_
イベントをトリガーします。
stripe trigger payment_intent.succeeded Running fixture for: payment_intent Trigger succeeded! Check dashboard for event details.
Stripe for VS Code を使用してイベントをトリガーする方法をご確認ください。
イベント送信の動作
このセクションは、Stripe が Amazon EventBridge にイベントを送信する際に想定されるさまざまな動作を理解するのに役立ちます。
自動での再試行
本番環境では、Stripe は指数バックオフを使用して最長 3 日間、送信先へのイベントの配信を試行します。イベント送信先のイベントの配信タブで、該当がある場合、次回の再試行のタイミングを確認します。Stripe はサンドボックスで作成されたイベントの配信を数時間のうちに 3 回再試行します。Stripe が再試行するときに、送信先が無効化または削除されていた場合、そのイベントの以降の再試行は行われません。ただし、Stripe が再試行できるようになる前にイベントの送信先を無効にして、再び有効にした場合は、以降の再試行が引き続き行われます。
手動での再試行
There are two ways to manually retry events:
- In the Stripe Dashboard, click Resend when looking at a specific event. This works for up to 15 days after the event creation.
- With the Stripe CLI, run the
stripe events resend <event_
command. This works for up to 30 days after the event creation.id> --webhook-endpoint=<endpoint_ id>
イベントの順序付け
Stripe は、イベントが生成された順序で配信されることを保証しません。たとえば、サブスクリプションを作成することで、次のイベントが生成されるとします。
customer.
subscription. created invoice.
created invoice.
paid charge.
(支払いが付随する場合)created
イベントの送信先が、特定の順序でのイベントの受信に左右されないようにしてください。配送を適切に管理できるように準備します。API を使用して不足しているオブジェクトを取得することもできます。たとえば、最初に受信したイベントが invoice.
であった場合は、それに含まれる情報を使用して請求書、支払い、サブスクリプションの各オブジェクトを取得できます。
API のバージョン管理
イベント発生時のアカウント設定内の API バージョンによって、API バージョンが指定され、それにより送信先に送られる Event (イベント) の構造が決定されます。たとえば、アカウントが 2015-02-16 のように以前の API バージョンに設定されている場合、特定のリクエストに対して versioning (バージョン管理) で API バージョンを変更しても、生成され送信先に送られる Event (イベント) オブジェクトは、引き続き 2015-02-16 API バージョンに基づきます。Event オブジェクトは、作成されると変更できません。たとえば、請求を更新しても、元の請求イベントは変更されません。そのため、アカウントの API バージョンを後で更新しても、既存の Event オブジェクトがさかのぼって変更されることはありません。新しい API バージョンを使用して /v1/events
を呼び出すことで以前の Event を取得しても、受信するイベントの構造には影響しません。テスト用のイベントの送信先を、デフォルトの API バージョンと最新の API バージョンのいずれかに設定できます。イベントの送信先に送られる Event は、イベントの送信先で指定されているバージョンに従って構造化されます。
イベントの送信先のステータス
Amazon EventBridge の送信先には、イベント受信への対応状況を示すいくつかのステータスがあります。
- 有効: イベントの送信先はイベントバスに正常に関連付けられています。EventBridge のルールを正しく設定すると、選択したイベントコンシューマーでイベントを受信します。
- 無効: Stripe は Amazon EventBridge にイベントを送信できていません。送信先を手動で無効化したか、あるいは AWS の設定ミスにより Stripe が自動で無効化するとこのステータスになります。
- 保留中: イベントの送信先で AWS のパートナーイベントソースが適切に作成された後で、そのイベントソースをイベントバスに関連付ける必要があります。この関連付けを行うまで、送信先は保留中のステータスで維持され、イベントを一切受信しません。関連付けした時点でステータスは有効に変わります。
イベントの構造
EventBridge は Stripe の event
JSON オブジェクトを最上位の detail
フィールド内にラップする独自のイベント構造を使用します。
この例は、EventBridge の customer.
イベントペイロードです。
{ "version":"0", "id":"17e8dff5-d6cd-3770-ace9-aeac02b6ac3f", "detail-type":"customer.created", "source":"aws.partner/stripe.com/ed_61PgtRTG5aTCIz98516PLsRGLISQK0Otk6FWKjBrcDia", "account":"506417113029", "time":"2024-03-07T18:27:56Z", "region":"us-west-2", "resources":[
Stripe が応答を待つイベントタイプをサポートする
Stripe はほとんどのイベントタイプを非同期で送信します。ただし、特定のイベントタイプに対しては、Stripe は応答を待ちます。イベントの送信先からの応答の有無は、これらの特定のイベントタイプに関する Stripe のアクションに直接影響を及ぼします。
Amazon EventBridge の送信先では、応答が必要なイベントタイプに対して制限付きのサポートが提供されます。
- Amazon EventBridge の送信先の
issuing_
イベントタイプに登録することはできません。代わりに、Webhook エンドポイントを設定してこのイベントタイプに登録します。authorization. request issuing_
を使用することで、購入リクエストをリアルタイムで承認できます。これには、送信先がイベントに応答してリクエストを承認または拒否する必要があります。EventBridge は、Stripe への応答をコンシューマーに送信する前に処理します。したがって、この送信先タイプは、このイベントタイプを使用して支払いを承認することはできません。authorization. request - Amazon EventBridge を使用する場合は、
checkout_
に登録できます。ただし、ウェブサイトに直接 Checkout を埋め込んだり、Stripe がホストする支払いページに顧客をリダイレクトする場合、これはリダイレクト動作を処理しません。Amazon EventBridge にsessions. completed checkout_
イベントを送信しても、リダイレクトの動作には影響しません。Checkout のリダイレクト動作に影響を与えるには、このイベントタイプを Webhook エンドポイントで処理します。sessions. completed
EventBridge と Stripe イベントで一般的なアーキテクチャーパターン
Stripe とともに Amazon EventBridge を使用する際は、次のアーキテクチャーパターンを検討してください。
- Lambda でサーバーレス機能を起動してビジネスの自動化を定義する: EventBridge から Lambda に Stripe イベントを送信して、支払い成功後の配送ラベルの作成など、サーバーレスのコンピューティング機能を起動します。
- CloudWatch によるイベント監視の有効化: イベントを EventBridge から CloudWatch Logs に送信し、イベントを対話形式で検索および分析できるログデータとして格納します。CloudWatch を使用して使用形態とエラーを監視します。エラー (EventBridge ルールに違反した場合など) へのアラートを設定することを検討してください。
- Step Functions によるローコードおよびノーコードのワークフローの起動: イベントを StepFunction ワークフローに送信し、そこから顧客にトライアルの終了日が近づいていることを通知するなどのビジネスシナリオを開始します。
- Simple Notification Service (SNS) または Simple Queue Service (SQS) による内部システムへのイベントのファンアウト: イベントを SNS または SQS に送信して、Stripe イベントデータを社内チームが所有および処理できるようにファンアウトします。