Stripeでの3Dセキュア対応について
katStripe：クレジットカード・セキュリティガイドラインについて
チェックポイント
- Charges API、Orders APIを使用しているか？
- Payment Intents APIに移行推奨
- 支払いにおいてサードパーティとの連携があるか？
- 顧客向けのコミュニケーション
- サポート体制を作っておく（エンジニアリングとはずれるが、大事）
クレジットカード・セキュリティガイドラインの改訂と3Dセキュアの導入
クレジットカード・セキュリティガイドラインの改訂
改訂の背景と目的
-
2024年3月15日に改訂された「クレジットカード・セキュリティガイドライン」は、クレジットカード取引に関わる事業者が実施すべきセキュリティ対策を定めている。
-
不正対策の一環として、オンライン販売を行う全ての加盟店は、2025年3月末までに3Dセキュアの導入を完了する必要がある。
3Dセキュアの概要
-
3Dセキュア（3DS）は、クレジットカード取引に追加の認証レイヤーを提供し、不正使用によるカード支払いに対する賠償責任からビジネスを保護する仕組みである。
-
この仕組みは、顧客のカード発行会社が追加の認証を要求することで、取引の安全性を高める。
Stripeにおける3Dセキュアの適用
適用開始日と段階的導入
-
Stripeは2025年3月31日から全ての対象取引に3Dセキュアを適用する。
-
2025年1月からは、段階的に3Dセキュアの認証を適用し、2025年3月31日には100%の取引に拡大する。
加盟店の準備と実装
-
加盟店は、決済の取引失敗を避けるために、2024年末までに必要な実装を行う必要がある。
-
3Dセキュアへの対応準備が間に合わない場合、除外申請が可能だが、2025年3月31日からは全ての取引に3Dセキュアが必要となる。
APIの実装と移行
Charges APIとOrders APIの制限
-
Charges APIおよびOrders APIは3Dセキュア2をサポートしておらず、これらを使用している場合、クレジットカードの支払いは失敗する。
-
支払い拒否の増加を避けるため、早めにPayment Intents APIに移行することが推奨される。
Payment Intents APIの利用
-
Payment Intents APIでは3Dセキュアを通じて支払いを受け付けることができ、顧客に支払いの認証を促すことが可能である。
-
サーバー側で決済を確定している場合、クライアント側で3Dセキュア認証を完了させるために追加の処理が必要となる。
サードパーティとの連携
サードパーティの影響
-
サードパーティやプラットフォームを通じてStripeを実装している場合、仕様はサードパーティに依存するため、直接確認が必要である。
-
サードパーティが3Dセキュアに向けて準備や更新を行っていることを確認することが重要である。
顧客向けのコミュニケーション
- 3Dセキュアに関する顧客からの問い合わせ対応の準備が必要であり、カスタマーサポートへの対応や説明記事を用意することが求められる。
不正対策とリスク管理
Radarの活用
-
Stripeは、機械学習を活用した不正対策プロダクト「Radar」を提供しており、数百のシグナルを基にリスク判定を行う。
-
3Dセキュアを動的にリクエストするためのデフォルトのRadarルールを設定することができ、顧客の追加認証をリクエストすることが可能である。
リスクカスタマイズの重要性
-
Radar for Teamsを利用することで、事業の顧客特性に合わせた独自のリスクをカスタマイズすることができる。
-
リスクレベルや特定のメタデータに基づいて3Dセキュアをリクエストすることで、正当な支払いの過度なブロックを防ぎ、収益の最大化につなげることが期待される。
よくある質問
対面取引の扱い
- 物理的カードを使用する対面取引は、3Dセキュアの導入基準の対象外である。
3Dセキュア未導入の影響
- 罰金等の罰則規定はないが、加盟店のセキュリティ対策が不十分な場合、カード会社等による調査が行われ、必要な対策を講じるよう指導される。
手数料について
- 一般的に、3Dセキュア認証によって手数料は発生しないが、カスタム料金体系が設定されている場合は手数料が課されることがある。
サードパーティ利用時の対応
- サードパーティ/プラグインを通じてStripeを利用している場合、3Dセキュアに伴う変更が必要になる可能性があるため、迅速にサードパーティへ連絡し、準備を確認することが推奨される。
kat3Dセキュア対応テストカード
katCasher使ってさらっと実装してそう。
ぱっと見特別な実装してなさそうだが、Exceptionの処理が肝なんだろうか？
git
やってるのは公式ドキュメントのこの辺の実装と同じっぽい。
とりあえずException入れたら3Dセキュアのデモは動いた。が、サブスクが購入された際のアプリ側のステータス更新等が動作しない（例外発生し、Catch内で3Dセキュアページにリダイレクトしているためトランザクションはロールバックされる）ので、リダイレクト先でやるでいいのか？
katAPI を使用して 3DS を手動でリクエストする
PaymentIntent または SetupIntent の作成または確認時、あるいは Checkout セッション の作成時に最適化する対象に応じて、payment_method_options[card][request_three_d_secure] を any または challenge に設定します。
このプロセスは、1 回限りの支払いの場合も、今後の支払いのために支払い方法を設定する場合も同じ。
このパラメーターを指定すると、Stripe は 3DS の実行を試み、PaymentIntent、SetupIntent、または Checkout セッションの 動的 3D Secure Radar ルール を上書きします。
とある。
サブスクの作成やカード情報の更新でも同じパラメータが使えるか？
$stripe->paymentIntents->create([
'amount' => 1000,
'currency' => 'usd',
'payment_method_options' => ['card' => ['request_three_d_secure' => 'any']],
]);
request_three_d_secure を any : 3DS認証しないかも？
request_three_d_secure を challenge : 3DS認証する
Stripe Elementsを使っている場合は、この辺が修正ポイントか？
stripe.confirmCardPayment(
'{{PAYMENT_INTENT_CLIENT_SECRET}}',
{
payment_method: {card: cardElement},
return_url: 'https://example.com/return_url'
},
// Disable the default next action handling.
{handleActions: false}
).then(function(result) {
// Handle result.error or result.paymentIntent
// More details in Step 2.
});
return_urlを指定して
kat3Dセキュアの「3D」とは
3DセキュアのDは「Domain（ドメイン）」を指し、以下の3つのドメイン（領域）が連携することを意味します。
・イシュアドメイン：カード発行会社（イシュア）とカード会員
・アクワイアラドメイン：加盟店管理会社（アクワイアラ）とEC加盟店
・インターオペラビリティ（相互運用）ドメイン：国際カードブランド（Visa・JCB・Mastercardなど）
katフリクションレス認証
フリクションレス：必要な情報を入力せずに処理が完了する仕組み。認証においては認証情報（ワンタイムパスワード等）の入力せずに認証が完了するという意味合い
