この記事では、Stripeダッシュボードを活用して現在は非推奨となっているCharges APIをシステムが利用しているかどうかを調査する方法を紹介します。2025年3月に必須化される3Dセキュアによる追加認証への対応を進めている方は、この記事を参考にシステムの組み込み状況を調査してみてください。

2025年3月から対応が必須となる3Dセキュアを利用した追加認証、Stripeを利用している場合、基本的には追加の対応はほとんど必要ありません。これはStripeが提供する決済ページや決済フォーム側に3Dセキュアの提供を行う仕組みが用意されているためです。

一方で次のようなケースでは、3Dセキュアを利用するための追加実装が必要です。

サーバー側で支払いの実行（confirm）を行う支払いフローで、Payment Intents / Setup Intentsのrequires_action状態を処理する仕組みが用意されていない場合
現在は非推奨の、Charges APIを利用して決済フローを提供している場合
サブスクリプションで、3Dセキュア認証操作を依頼するメールを送信する機能をオフにしている場合

今回の記事では、このうちCharges APIを利用しているケースについて、紹介します。

Charges APIは現在の3Dセキュア認証（ EMV-3DS ）に対応していない

Charges APIはかつてStripeを利用した決済フローを構築する際に利用されていたAPIで、現在は利用が非推奨となっているAPIの１つです。新しい組み込み方法であるPayment Intents API（決済処理へ利用する）およびSetup Intents API(支払い情報の保存へ利用する)への移行が推奨されており、その理由の1つが3Dセキュア認証への対応です。

Charges APIはAPIが非推奨になった後から登場した、EMV-3DS ( 3Dセキュア2 )に対応していません。そして現在はCharges APIが対応している3Dセキュア1での認証はすでに日本で提供されておらず、2025年3月から必須化される3Dセキュア認証の必須化への対応が困難です。

そのため、Charges APIを利用した決済フローを提供している日本のユーザーは、3Dセキュア必須化への対応として、Payment Intents APIおよびSetup Intents APIへの移行を必ず行う必要があります。

ワークベンチでCharges APIの呼び出し履歴を確認できる

Charges APIから移行を行うには、まず現在のシステムとStripe連携がどのような状態かを知る必要があります。システムは現在もCharges APIを利用しているのか。それともすでにPayment IntentsやSetup Intentsへの移行が完了しているのか。はたまたStripe Checkoutを利用したリダイレクト型の組み込みに切り替えているのか。システムがStripeのAPIをどのように利用しているかを把握することで、移行プロジェクトを立ち上げるべきかどうかの判断や、工数の見積もりなどを始めることができます。

システムがStripeのAPIをどのように利用しているかを把握するには、Stripeダッシュボードを使うことをお勧めします。ダッシュボードには、APIのリクエストログやWebhookイベントを調査するためのワークベンチ機能が提供されています。これはダッシュボード右下にあるワークベンチを展開ボタンをクリックするか、[Shiftキー]と[~キー]を同時に入力することで、起動できる開発者向けの支援ツールです。

ワークベンチを起動すると、APIログやイベント・エラーなど、調査対象のタブを含む画面が表示されます。Charges APIのような、特定のAPIが利用されているかを調査するには、ログタブを選択します。ここではStripeのAPIがいつ・どんな内容で呼び出されたかを調べることができます。

ここでCharges APIが実際に利用されているかを調べてみましょう。フィルターとして用意されているAPIエンドポイントを選択し、Charges APIを新しく作成する際に利用するパス(/v1/charges)と入力します。このフィルターを利用することで、特定のAPIパスに対するリクエストだけを調べることができます。

もしCharges APIが利用されている場合、このフィルターを設定するとPOST /v1/chargesのリクエストログが表示されます。

ワークベンチでは、APIリクエスト内容の詳細も調べることができます。ここでは呼び出されたIPアドレスや、Stripe SDKが送信するユーザーエージェント情報などを利用して、どのアプリケーション・サービスからCharges APIが呼び出されたかを深掘りします。スクリーンショットの例では、NodeBindingsがユーザーエージェントに含まれていることから、stripe-node SDKを利用したアプリケーションがCharges APIを利用していることがわかります。

また、右側の詳細パネルをスクロールすると、APIリクエストのBodyも見ることができます。ここでリクエスト内容を調べることで、ソースコードを検索する際に検索キーワードとして使えるパラメータ名などを調べます。下のスクリーンショットでは、tok_から始まるIDをsourceとして渡していることから、フロントエンド側のアプリケーションでTokens APIを利用した処理が実行されており、そこから決済フローが始まっていることが伺えます。

Tokens APIが出てきましたので、フィルターを更新して/v1/tokensについても調べてみましょう。するとフロントエンドのSDKが作成したTokens API作成リクエストの履歴が出てきます。こちらの詳細データを見ると、アプリケーションのどのURLからリクエストが送信されたかが把握できます。あとはTokens / Charges APIが利用されたであろうページのURLをヒントに、アプリケーション側のフローやソースコードを調査することができます。

あとは移行ドキュメントを参考にPayment Intents APIやSetup Intents APIへの移行を進めます。テスト・ステージング環境でコードを変更した後、ワークベンチのログを調べることで、Charges APIの呼び出し履歴が依然として追加されてきているかを調べましょう。呼び出し履歴がゼロになれば、Charges APIを利用した決済フローは顧客に提供されていないと判断できます。

Charge succeededイベントはPayment Intentでも発生する

ワークベンチでCharges APIについて調査する際、必要な点が１つあります。それは「Stripeが内部的にCharge APIを利用することがあること」です。

ワークベンチのイベントタブを開くと、charge.updatedやcharge.succeededイベントが発生していることが確認できます。しかしログタブを見るとCharges APIの呼び出し履歴が残っていないケースがあります。これはPayment Intents APIやCheckout Sessions APIで決済を行った時に、Stripeが内部的に処理を行っていることがあるからです。

イベントログでCharges APIが利用されているかどうかを確認するには、Chargeに関するイベントの詳細データを確認します。Chargesオブジェクトの中にある、payment_intentパラメータにpi_から始まる文字列が含まれているかをチェックしましょう。もし文字列が含まれている場合、そのイベントはPayment Intents APIやCheckout Sessions APIを利用した決済にて送信されたイベントであると判断できます。

次のスクリーンショットのように、payment_intentがnullの場合、これはCharges APIを利用した決済で発生したイベントである可能性が高いです。この場合はログタブに移動して、Charges APIの呼び出し履歴が残っているかを確認・調査しましょう。

まとめ

クレジットカードの不正利用を減らすため、2025年3月以降のオンライン決済では3Dセキュア(3DS)による認証が必須となります。Stripeを利用している場合、基本的には追加の対応は不要です。

ただしCharges APIを利用した決済フローを提供されているユーザーは、Payment IntentまたはSetup Intentを利用した組み込みへのアップグレードが必要です。具体的なアップグレード方法については、Stripe Docsの移行方法に関するページをご確認ください。

もし現在運用している決済フローがCharges APIを利用したものかどうかが不明な場合は、今回紹介したワークベンチを利用することで、Charge APIがどこで呼び出されているかを調査できます。APIリクエスト内容の調査やエラーログの分析も行うことができますので、変更後の動作確認や不具合検証などにもお使いいただけます。

2025年3月の必須化に備えて、一度決済フローの現状について確認してみましょう。