Article

TL;DR

Subscriptionで、3Dセキュアの対応をするには、Subscription.Createのオプションに下記を設定

• collection_method: charge_automaticallyを設定
  • 支払いの即時実行
• expand: [‘latest_invoice.payment_intent]を設定
  • 支払いの紐付け

また、一度手戻りが発生するので、一個のAPIだと解決できない。
3Dセキュアの認証が完了したら、pyamentIntentのinvoiceを確認する

2025年3月末より、クレカのセキュリティが強化

昨今クレカの不正利用が多発し、各クレカ会社の対応によりセキュリティが向上
それにより、一般ECサイトでも3DSの対応が急がれる

今回は、僕の本業の方で、課金に失敗するケースが多発していて、Stripeのコンソール上で確認したところ、3DSの認証に失敗していることが発覚

急いで対応にあたり、なんとか3DSの認証ができるように改善できた

影響範囲

フロントだけの修正にとどめたかったが、それも叶わず。
サーバーサイドも同様に修正した。

既存のルーティンだと、

1. カード入力を受け付ける(フロント
2. カードのトークンを発行(フロント
3. トークンを元に、決済とサブスク作成(サーバ
4. 結果を返す(サーバ

だったのが、

1. カード入力を受け付ける(フロント
2. カードのトークンを発行(フロント
3. サブスク作成と決済を試す(サーバ
4. PaymentIntentの状態がrequires_actionだった場合、フロントに3DSを要求(サーバ
5. 3DSの認証(フロント
6. 3DSの認証を確認依頼(フロント
7. 3DSの認証を確認(サーバ
8. 結果を返す(サーバ

と煩雑になります。

もちろん、ユーザ側も決済に一段階あるので、何か分からず離脱してしまう可能性があります。
（どうしようもない…

まとめ

3DSでかなりつまづいたというところはそんなにないです（stripe様様）。
結構ラッピングしてくれてて、割とすんなり行きました。
ですが、stripeのドキュメントに、もっとネイティブのユースケースの情報を増やして欲しいです！
自分の見方が悪いかもですが、ドキュメント見づらく、情報を探すのに一苦労でした
自社の支払いサービスを使えということなんでしょうか…