決済フローや3Dセキュア認証を、Stripe ワークベンチで簡単に調査・デバッグする


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

![スクリーンショット 2024-07-29 14.48.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/1886371c-73cb-d12a-fe97-360f9a09ad0c.png)

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

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

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

![スクリーンショット 2024-07-29 15.09.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/149ece26-a84d-fc6e-b9ea-89977677f613.png)

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

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

![スクリーンショット 2024-07-29 15.23.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/4cf01aca-4ba6-d3b7-381c-ed97d6e5f88c.png)

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

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

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

![スクリーンショット 2024-07-29 15.28.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/3c3fe2eb-c3ef-7d1b-8aab-95b26acae0ef.png)
https://docs.stripe.com/workbench

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

![スクリーンショット 2024-07-29 15.31.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/2e4810b3-2c7e-1d30-423f-24e57b4f5091.png)

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

![スクリーンショット 2024-07-29 15.33.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/bf2d1851-29cc-4fe4-8429-367542dd96c0.png)

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

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

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

![スクリーンショット 2024-07-29 15.36.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/e82cca03-6135-0f84-c3e8-b47525b93bd8.png)

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

- `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、そしてリダイレクト型決済フローのいずれかで顧客が決済を行ったことがわかります。


![スクリーンショット 2024-07-29 15.45.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/5724a353-59cb-b91c-1b89-b80cb3f5d4cb.png)


:::note warn
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` であることとわかります。

![スクリーンショット 2024-07-29 16.00.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2366300/4e6c53a7-ebb0-2f54-7d88-26a1b253caf9.png)

チャレンジとは、ユーザーが認証UIアクションを表示され、それにオンセッションで応答する必要があることを意味します。さらに、 `result: "authenticated"` が表示され、顧客が認証チャレンジを正常に完了したことがわかります。詳細は[ChargeオブジェクトのAPIドキュメント](https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-card-three_d_secure)を参照してください。

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

## まとめ

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

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

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

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

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

https://qiita.com/hideokamoto/items/7920051d7476439e5a5e

https://qiita.com/hideokamoto/items/710f9f006fe59ab83b27

https://qiita.com/hideokamoto/items/0f6d4e5fa34e8e673140

https://qiita.com/hideokamoto/items/fa8223470ad75f5307d1

https://qiita.com/hideokamoto/items/c30eded3fa8cd73f1a93