オンライン決済には、カードの限度額チェック、3Dセキュア（3DS）による本人確認、サブスクリプションや予約注文のためのオフセッション決済の処理など、さまざまなプロセスが裏で進行します。その結果、多くの開発者はバグの修正、顧客からの問い合わせ対応、ビジネス要求の処理に多くの時間を費やしています。

この記事では、Stripeの開発者向けツール「ワークベンチ」を使って3DS認証などのフローを追跡し、デバッグする方法を紹介します。

なぜ決済フローをデバッグする必要があるのか？

クレジットカード情報が送信されてから店舗に支払いが届くまでの間に、さまざまなプロセスやサービスがバックグラウンドで実行されます。これには、Radarによる不正リスク評価、3Dセキュアなどの追加認証、カード発行者による限度額の確保、および通貨交換プロセスが含まれます。

通常、開発者がこれらの操作を気にする必要はありません。しかし、問題が発生した場合、決済フローで何がうまくいかなかったかを調査し、修正する方法を知る必要があります。

例えば、3DS認証プロセスの詳細を調査する必要があるシナリオを考えてみましょう。現在の3DS認証フローであるEMV 3DSでは、認証UIをユーザーに表示せずにリスク評価に基づいて認証が行われる可能性があります。このような場合、ユーザーはバックグラウンドで3DS認証が行われていることに気づかずに支払いを完了するため、デバッグ時には認証が行われたかどうか、リスクベースの評価によるものか、本人確認UIを使用したかを調査する必要があります。

こうした調査は、Stripeのダッシュボードで新たにリリースされたWorkbenchを使用して簡単に行うことができます。

3DSや不正利用なども、Stripeなら簡単にテストできる

Stripeでは、ダッシュボードにて開発者向けの支援ツール「ワークベンチ」を提供しています。この機能を利用することで、「APIエラーの履歴やサマリーの確認」「APIリクエストやWebhookのイベントログの確認」「APIリクエストのテストとSDKコードの生成」といった、開発・テスト・デバッグを１ブラウザでできるようになります。

https://docs.stripe.com/workbench

ワークベンチを利用するには、Stripeのダッシュボードの[開発者]リンクから[ワークベンチ]をクリックします。キーボードの~を入力することで、ブラウザの開発者ツールのように素早く起動することもできます。

ワークベンチの一部機能は、ダッシュボードで現在表示しているページと連動して利用できます。例えば[Inspector]タブは、今表示しているページのリソースがすぐに確認できるようになっています。そのため、CLIやAPIを使ってデータの中身を確認する作業を無くすことができます。

Workbenchを使った3DSの簡単なテスト方法

調査とデバッグの流れを体験するために、3DS認証が要求通りに実行されたかを調査してみましょう。3DS認証は2つの方法で完了します。認証UIがユーザーに表示される場合とされない場合です。ワークベンチを使って3DS認証が実行されたかと、認証UIがユーザーに表示されたかを調べましょう。

支払いフローを確認するには、ワークベンチの「Events」タブを開きます。以下のスクリーンショットは、Stripeのリダイレクト型の決済フローを使って完了した一回払いの履歴を示しています。

この履歴を確認すると、次のイベントが発生していることがわかります。

payment_intent.created
payment_intent.requires_action
charge.succeeded
payment_intent.succeeded
checkout.session.completed

発生した順番にイベントデータを確認すると、payment_intent.requires_actionで送信されていることがわかります。「このイベントが送信されていること」から「決済フローの中で、3DSを使った追加認証が要求・実行されたこと」が伺えます。また、データをみると、next_action.type = "use_stripe_sdk"が見つかりました。これはStripeのJSまたはモバイルSDK、そしてリダイレクト型決済フローのいずれかで顧客が決済を行ったことがわかります。

StripeのWebhookイベントは、送信される順序が入れ替わることもあります。そのため、Webhookイベントの送信順序に依存したステートフルな実装は避けるようにしてください。

たとえば「payment_intent.succeededイベントが実行された後のデータを、checkout.session.completedで利用したい場合」を考えてみましょう。

checkout.session.completedイベントを利用した処理の中では、『payment_intent.succeededイベントが送信されたかどうか』はわかりません。そのため、Payment Intent APIを利用して、最新のリソースを取得するようにしましょう。

イベントの「流れ」を追いかける

次に、 charge.succeeded イベントを詳しく調査すると、 three_d_secure キーを持つオブジェクトがあることに気づきます。このデータを見て、 authentication_flow の値が challenge であることとわかります。

チャレンジとは、ユーザーが認証UIアクションを表示され、それにオンセッションで応答する必要があることを意味します。さらに、 result: "authenticated" が表示され、顧客が認証チャレンジを正常に完了したことがわかります。詳細はChargeオブジェクトのAPIドキュメントを参照してください。

このように、Eventsタブを使用して支払いフローをクリアにすることで、顧客がどのような支払いフローを経ているかを確認できます。

まとめ

Stripeのワークベンチを使用することで、決済プロセスの裏側で何が起こったのかを数クリックで調査することができます。

顧客や内部の問い合わせに対して、できるだけ簡単に情報を集める
サブスクリプションの自動更新に関連するコードをテストするためのイベントデータを取得する
3DS認証結果やフローを処理する方法を学ぶ

このような場面で、今回紹介したワークベンチのEventやInspectタブが活躍します。調査のためのバッチ処理やCLIスクリプトなどを作る時間を減らして、開発のための時間を効率的に使える環境を手に入れましょう。

Stripeでの3Dセキュア義務化対応について知りたい方は、こちらもどうぞ

2025年3月より始まる3Dセキュア義務化に関する記事を複数用意しております。現在対応方法をお探し中の方は、ぜひこちらの記事もご覧ください。