Stripeではじめる 3Dセキュア2 JP_Stripes Deep Dive vol.10 @hidetaka_dev Oct 2022

今日のトピック 1. 3Dセキュアについてのおさらい 2. 3Dセキュア1と3Dセキュア2 3. Stripeで、3Dセキュア2への追加対応が必要なケース 4. Radarルールで、より細やかな追加認証を実施する 2 JP_Stripes Deep Dive Vol.10 #JP_Stripes

今日のトピック 1. 3Dセキュアについてのおさらい 2. 3Dセキュア1と3Dセキュア2 3. Stripeで、3Dセキュア2への追加対応が必要なケース 4. Radarルールで、より細やかな追加認証を実施する 3 JP_Stripes Deep Dive Vol.10 #JP_Stripes

3Dセキュアでの認証とは ● 身近な例では、カード情報を入力した際に、 カード会社アカウントのID/Password入力などを求められる画面のこと ● 「追加の本人確認」を要求することで、 クレジットカードの不正利用リスクを減らすことを目指している ● 不正利用によるチャージバック要求があった場合、 その責任がカード発行会社側を移せる（ライアビリティシフト） 4 JP_Stripes Deep Dive Vol.10 #JP_Stripes

今日のトピック 1. 3Dセキュアについてのおさらい 2. 3Dセキュア1と3Dセキュア2 3. Stripeで、3Dセキュア2への追加対応が必要なケース 4. Radarルールで、より細やかな追加認証を実施する 5 JP_Stripes Deep Dive Vol.10 #JP_Stripes

最近の3Dセキュアは、リダイレクトしない ● 通販などでよく見かける、「認証画面へのリダイレクト」 ○ 追加のステップが発生することで、カゴ落ちリスクが生まれる ○ ID / Passwordを忘れたことによる、カゴ落ちリスクも ○ 別ドメインへリダイレクトされることで、実装が複雑になる ● 3Dセキュア2では、認証をリダイレクトせずに実施 ○ 住所やデバイス情報などを使った、バックグラウンドでの認証 -> リスクベース認証 ○ 追加情報が必要な場合の画面を、サイト・アプリ内にモーダル表示 6 JP_Stripes Deep Dive Vol.10 #JP_Stripes

7 #Stripe #JP_Stripes https://stripe.com/jp/guides/3d-secure-2

8 #Stripe #JP_Stripes https://stripe.com/jp/guides/3d-secure-2 追加認証の モーダルを表示

3Dセキュア2のモーダル認証画面サンプル 9 JP_Stripes Deep Dive Vol.10

2022/10までに3Dセキュア2への移行が必要 ● 2022/10時点で、多くのカードネットワークが3Dセキュア1を終了 ○ ライアビリティシフトも3DS1では終了 ○ チャージバック発生時のカード発行会社による補償がなくなる ● ユーザー体験の改善にもなる、3Dセキュア2への移行を ○ モバイルアプリでも、認証のためにブラウザへ遷移しない ○ 事前のリスクベース評価で、「追加認証画面なし」の認証も可能に ○ Stripeでは、Radarルールで追加認証画面表示の要件をカスタマイズ可 10 JP_Stripes Deep Dive Vol.10 #JP_Stripes

今日のトピック 1. 3Dセキュアについてのおさらい 2. 3Dセキュア1と3Dセキュア2 3. Stripeで、3Dセキュア2への追加対応が必要なケース 4. Radarルールで、より細やかな追加認証を実施する 11 JP_Stripes Deep Dive Vol.10 #JP_Stripes

Stripeで、3Dセキュア2への移行対応が「不要」なケース ● 「Stripeが用意する決済画面」を使っているケース ○ 例: ■ Checkout / Payment Links ■ BillingやInvoicingでの、メール送信による請求 ● Payment Intent / Setup Intentを利用した組み込みをしているケース ○ Card Element / Payment Element (Stripe.js) ○ confirmXXXメソッド実行時に、SDKがモーダル表示などをハンドル ● これからStripeを組み込む人は、 3Dセキュア対応の追加作業をほぼやらなくてOK 12 JP_Stripes Deep Dive Vol.10 #JP_Stripes

Stripeで、3Dセキュア2への移行対応が「必須」なケース ● 非推奨なAPIを利用しているケース ○ Source API / Token API / Charge API ○ 3Dセキュア2で認証できないため、決済エラーになる ○ Payment Intent / Setup Intent またはStripeが用意する決済ページに移動するように実装を変更する 13 JP_Stripes Deep Dive Vol.10 #JP_Stripes

Payment Intent / Setup Intentへの移行 ● 主な変更点: ○ サーバー側でのStripe API呼び出しタイミング ■ これまで: 決済フォーム入力後 ● Stripe.jsでのcreateXXXメソッド実行後 ■ Payment / Setup Intent: 決済フォームの表示前 ● 先にAPIを呼び出す ● 取得したclient_secretを、Stripe.jsに渡してフォームを表示 ○ 3Dセキュア認証のためのリダイレクト処理などが不要に ■ Stripe.jsでconfirmXXXを呼び出せば、あとはお任せできる 14 JP_Stripes Deep Dive Vol.10 #JP_Stripes

Payment Intent / Setup Intentへの移行ガイド ● Charge API: [Docs | Payment Intents API への移行] https://stripe.com/docs/payments/payment-intents/migration ● Token / Source API: [Docs: Payment Methods API に移行する] https://stripe.com/docs/payments/payment-methods/transitioning 15 JP_Stripes Deep Dive Vol.10 #JP_Stripes

今日のトピック 1. 3Dセキュアについてのおさらい 2. 3Dセキュア1と3Dセキュア2 3. Stripeで、3Dセキュア2への追加対応が必要なケース 4. Radarルールで、より細やかな追加認証を実施する 16 JP_Stripes Deep Dive Vol.10 #JP_Stripes

特定の商品や顧客・条件で3Dセキュアを必須にする 17 JP_Stripes Deep Dive Vol.10 認証画面の表示ルールカスタマイズ ● ３つのレベルから指定可能 ○ 必須のみ ○ 推奨含む ○ 全て ● 厳しくするほど、 カゴ落ちリスクが上がる点に注意 Radar for Team (有料) ● スクリーニング対象の 取引ごとに7円 ● カスタムの追加認証ルール機能 ○ 決済金額やIP、メアド ○ メタデータも含む ○ 「高額商品は必須」 ○ 「未成年の注文は必須」 ○ etc…

支払い認証レポートで、リクエスト閾値をチューニング 18 JP_Stripes Deep Dive Vol.10

まとめ ● 2022/10までに、3Dセキュア2への切り替えが必要 ○ ただし非推奨APIを使っていなければ、Stripeユーザーは対応不要 ○ 4000 0000 0000 3220: テスト環境で、3DS2を試すカード番号 ■ 上のカード番号で、認証画面が出る & エラーにならないならOK ● Source / Token / Charge APIユーザーは、早めの切り替えを ○ Docsの移行ガイドをご確認ください ● Radar (無料) と Radar for Team (有料) で、不正利用リスクをより軽減 ○ 無料版では、リクエストの閾値がカスタム可能 ○ Radar for teamで、商品・顧客などに応じたカスタムルールを設定 ■ metadataを活用することで、複雑なルールも設定可能 19 JP_Stripes Deep Dive Vol.10 #JP_Stripes

参考リンク ● Charge API: [Docs | Payment Intents API への移行] https://bit.ly/3StfOdl ● Token / Source API: [Docs: Payment Methods API に移行する] https://bit.ly/3Svk7Vp ● 3Dセキュア2に関するガイド https://stripe.com/jp/guides/3d-secure-2 20 JP_Stripes Deep Dive Vol.10 #JP_Stripes