ワークフロー公開プレビュー

Stripe ダッシュボードには Workflows のビジュアルビルダーが用意されており、順番に実行される一連のアクションを定義することで、タスクやプロセスを自動化できます。Workflows は複数ステップのプロセスに最適で、複数の Stripe プロダクト間で互換性があるため、プロセスの合理化、ビジネスルールの適用、手作業の削減が可能になります。

各ワークフローは、トリガーと、順番に実行される一連のステップで構成されます。ステップは、アクションまたは条件のいずれかです。ワークフローは、次のコンポーネントで構成されています。

ワークフローは、トリガーと条件に基づいて一連のアクションを順番に実行することで、タスクを自動化します。複数のワークフローが同じトリガーイベントを共有する場合、各ワークフローは、独自に定義されたステップとビジネスロジックに従って独立して実行されます。

アクティブなワークフローと非アクティブなワークフロー

ワークフローをアクティブ化、非アクティブ化、または削除できます。ワークフローを非アクティブにすると、Stripe はワークフローを無効と見なし、トリガーに応答しなくなります。非アクティブなワークフローは、いつでも再度アクティブにできます。一度に最大 6 つのアクティブなワークフローを維持でき、アクティブなワークフローと非アクティブなワークフローの両方を含む合計 20 のワークフローを持つことができます。

ワークフローがすでに 20 個ある場合、別のワークフローを作成することはできません。アクティブなワークフローが 6 つあり、別のワークフローをアクティブにする場合は、まず既にアクティブなワークフローを非アクティブにする必要があります。

トリガー

ワークフローは、Stripe API イベントによって開始されます。各ワークフローには 1 つのトリガーがあり、常にワークフローの最初のステップです。トリガーは、イベントに関するデータを提供します。このデータはワークフローに渡され、後続のステップで使用できるようになります。トリガーが起動し、そのデータが提供されると、ワークフローはそのデータを使用してアクションを実行します。

顧客に関連するワークフローを発生させる場合は、次のトリガーを適用できます。

Stripe を使用して決済 (Stripe Checkout や CheckoutSessions API など) を受け付けている場合、次のトリガーを適用できます。

Stripe を使用して、銀行振込や BNPL (支払いの詳細を確認するためにさらに時間がかかる) などの非同期の決済手段を受け付けている場合、次のトリガーを適用できます。

資金移動の結果、または支払いの成否に基づいてワークフローをトリガーする場合は、次のトリガー条件を適用できます。ほとんどの Stripe システムでは、支払いイベントを直接リッスンする代わりに、Checkout イベントまたは PaymentIntent イベント (例: Checkout セッションが完了しました) が使用されます。

サポートされているトリガー

ワークフローは、Stripe v1 と v2 の両方のトリガーとしてほとんどのイベントをサポートします。サポートされていないイベントは、ダッシュボードでは使用できません。

Connect をトリガーと共に使用する

Stripe Connect プラットフォームおよびマーケットプレイスは、プラットフォームアカウントからのイベントを使用してワークフローをトリガーできますが、連結アカウントからのイベントはトリガーできません。つまり、支払いが成功したときなど、プラットフォームアカウント内の何かのワークフローをトリガーすることはできますが、連結アカウントで発生したイベントから直接ワークフローをトリガーすることはできません。

アクション

アクションは、トリガーまたは前のステップからのデータに基づいて、自動的に実行されるタスクです。すべてのワークフローには少なくとも 1 つのアクションが必要であり、ほとんどのワークフローに複数のアクションが順に含まれています。

一般的なアクションには、次のようなものがあります。

• 顧客を更新する: 追跡やレポート作成の目的でメタデータフィールドを使用してカスタムデータを追加するなど、既存の顧客の詳細を変更します。
• 請求書を取得する: ステータスなど、特定の請求書の最新の詳細を取得します。これは通常、請求書の更新や現在の状態に基づく意思決定など、後のステップで使用されるデータを収集するために使用されます。
• サブスクリプションを取得するを参照してください。プランや請求サイクルなど、顧客のサブスクリプションの最新の詳細を取得します。これは通常、サブスクリプションの更新や条件ロジックの適用など、後のステップで使用するサブスクリプションデータを収集するために使用されます。
• サブスクリプションを更新する: プランの変更、請求サイクルの更新、割引の適用など、アクティブなサブスクリプションを変更します。

ワークフローステップは、トリガーイベントの後に開始され、順番に実行されます。各ステップは、動的フィールドを使用して、トリガーおよび前のステップからの情報にアクセスできます。これらのフィールドはスマートプレースホルダーとして機能し、ワークフローの進行に合わせてリアルタイムのデータが自動的に入力されます。このシステムにより、各ステップがワークフローを流れるデータに適応し、柔軟で応答性の高いワークフローが可能になります。

アクションは、アクションが実行された時点でのオブジェクトの最新の状態に対して動作します。つまり、最初のトリガーと後続のアクションの間にオブジェクトが変更された場合、アクションはオブジェクトの最新バージョンに影響します。ただし、動的参照は、最後に取得された時点のオブジェクトの状態を使用します。

サポートされているアクション

Workflows は、Stripe v1 と v2 の両方でほとんどの API アクションをサポートしています。サポートされていないアクションは、ダッシュボードでは使用できません。現在、すべての Stripe リストアクションはアクションとしてサポートされていません (たとえば、不審請求の申し立てのリストアクションなど)。

Connect をアクションと共に使用する

Stripe Connect プラットフォームとマーケットプレスは、プラットフォームアカウントを介してワークフローでアクションを使用できますが、連結アカウントを介して使用することはできません。つまり、ワークフローでは、支払いの返金やプラットフォームアカウントの顧客の更新などのアクションを実行できますが、連結アカウントでは直接アクションを実行できません

ワークフローに固有のアクション

以下はワークフローに固有のアクションであり、ダッシュボードのビジュアルビルダーを使用してのみ使用でき、パブリック API の一部ではありません。

条件

条件を使用すると、ワークフローにロジックを追加して、ワークフローを続行するかどうか、およびどのように処理すべきかを制御するルールを定義できます。条件は、通常、トリガーまたはそれ以前のステップからのデータを評価するチェック機構です。使用方法に応じて、条件によって、ワークフローを実行するかどうか、続行するかどうか、またはどのパスをたどる必要があるかが決まります。使用できる条件は、ワークフローが参照する予定のデータによって異なります。

トリガー条件

トリガー条件は、ワークフローを開始するイベントを絞り込みます。ワークフローは、トリガー条件が true の場合にのみ実行されます。これらは、ワークフローを特定のユースケースに絞り込む場合 (たとえば、特定の金額を超える支払いが成功した場合にのみワークフローを実行する、など) に便利です。その主な目的は、ワークフローを実行する必要があるかどうかを判断することです。

ダッシュボードでのトリガー条件の設定

仕組みは以下のとおりです。

1. Stripe アカウントでイベントが発生します。
2. トリガー条件は、このイベントが特定の基準を満たしているかどうかをチェックします。
3. 条件が満たされると、ワークフローが開始されます。満たされない場合、何も起こりません。

1 つの条件を作成して、1 つのトリガーに適用できます。以下に例を挙げます。

また、複数の条件を作成してトリガーに適用することもできます。以下に例を挙げます。

条件は、ワークフローを特定の状況に絞り込むのに役立ち、ワークフローの精度を調整するのに役立ちます。

ステップとしての条件

トリガー条件に加えて、ワークフロー内に条件ステップを追加できます。これらの条件ステップにより、ワークフロー開始後の動作を制御できます。

たとえば、特定の条件が満たされているかどうかをチェックし、ワークフローを続行する必要があるかどうかを判断するための条件を、ステップとしてワークフローに追加できます。条件ステップを追加することで、値を評価し、続行するかどうかを決定できます。条件が true の場合、ワークフローは次のステップに進みます。ただし、false の場合、ワークフローは停止し、成功としてマークされます。このアプローチを使用して、アクション完了後に結果を確認します。

分岐条件

条件ステップの別の例は、条件を分岐として使用することです。これにより、ワークフロー内に決定ポイントを導入し、指定した条件に基づいて複数のパスに分岐させることができます。条件ステップから複数のパスを構築して、ワークフローがさまざまなパスをたどり、さまざまな条件に基づいてさまざまなアクションを実行するようにできます。このアプローチは、顧客の国や購入金額に基づいて異なるメールをアカウントチームごとに送信するなど、複数のシナリオを処理する場合に使用します。

2 つの分岐を作成する条件の例:

条件を追加して、2 つ以上の分岐を作成することもできます。これにより、ワークフローは 1 つの決定ポイントから複数のシナリオを処理できます。

3 つの分岐を作成する条件の例:

各条件は、ビジュアルビルダーで左から右の順に評価されます。ワークフローは、最初に一致したパスをたどり、他のパスはスキップします。トリガー条件は、ワークフローを実行する必要があるかどうかを決定します。条件ステップは、ワークフローの開始後の動作を制御し、続行するか、別のパスに分岐するかを決定します。

多くの場合、トリガーごとまたはステップごとに同じ条件ロジックが適用されます。条件を適用する場所は、制御する内容、ワークフローを開始する必要があるかどうか、開始後に続行する必要があるかどうか、または実行中にどのパスをたどる必要があるか、によって異なります。

追加の構築済み機能

再帰検出

意図しない無限ループやワークフローの暴走を防ぐために、ワークフローはそのような再帰を自動的に識別して停止します。たとえば、顧客情報を更新するアクションも含む、顧客イベントによってトリガーされる、ワークフローについて考えてみます。このアクションを実行すると、別の顧客更新イベントが発生し、同じワークフローが再トリガーされ、無限ループに陥る可能性があります。これを防ぐため、ワークフローで認められている再帰の発生は 1 回のみです。ただし、複数回発生した場合にはワークフローはエラーで終了します。

自動での再試行

信頼性を向上させるため、Workflows では、再試行可能なエラーが発生したアクションを自動的に再試行します。つまり、一時的な問題が原因でアクションが失敗した場合、ワークフローは手動による介入を必要とせずにアクションの再実行を試みます。これにより、一時的なエラーが原因でワークフローが失敗することがなくなり、スムーズで一貫性のあるワークフロー実行が促されます。

べき等

べき等性により、同じリクエストが複数回送信された場合でも、アクションは 1 回しか実行されません。ワークフローは重複するリクエストを自動的に処理し、意図しないアクションの繰り返しを防ぎます。このセーフガードは、ネットワークの問題やエラーがリクエストの再試行につながる可能性がある場合に、ワークフローの整合性を保つのに役立ちます。

オブザーバビリティ

オブザーバビリティは、ワークフロー内の問題をすばやく監視、トラブルシューティング、解決するのに役立ちます。ワークフローは、以下の機能でオブザーバビリティを補強しています。

• 実行ステータス: ワークフローのステータスは、「実行中」、「成功」、「失敗」の 3 つのいずれかになります。障害が発生した場合は、問題の診断と解決に役立つ詳細なエラーメッセージが表示されます。
• 実行の詳細: 個々のワークフロー実行を調査して、実行されたステップ、使用されたパラメーター、発生したエラーなど、正確な実行パスを表示できます。この視認によって、ワークフローのどのステップでエラーが起こったかをすばやく特定したり、実行でたどったパスを把握したりすることが可能になります。