2025年3月末までにECサイトへ3Dセキュア2.0の導入が義務付けられるらしいです。
カード決済の導入方式によっては、そこそこ工数のかかるシステム改修が必要です。
未対応のサイトがたくさん出てそうですね。
私のところにも3Dセキュア導入の見積依頼がいくつか来ました。
決済代行業者や導入方式によって実装方法は大きく変わってきますが、
ユーザー・ECサイト・決済代行業者・3DSサーバーの4者間の情報の流れはだいたい同じです。
なので、一度実装すると、二度目からは必要な作業を把握するのは早くなります。
直近で実装したのは、
GMOペイメントのAPIで実装されていたサブスクのシステムで、
新規申込み時に3Dセキュアを導入したいというものでした。
サブスクなので新規申込み時には決済はありません。
ユーザー登録とクレジットカード登録があるだけでした。
具体的には、
SaveMember.idPass（ユーザー登録）
↓
SaveCard.idPass（カード登録）
で終わりです。
ここに3Dセキュア2.0を導入するためには、
決済処理の一種である「有効性チェック」を実行する必要があります。
有効性チェックは、実際に決済されるわけではなくカードの有効性チェックで使われます。
3Dセキュア認証では決済処理を伴わせる必要があるため、
カード登録時に3Dセキュア認証をさせるためにはこの有効性チェックを使用します。
（GMOペイメントの担当者もこの方法を指示してきました）
有効性チェック実行後、レスポンスとして3Dセキュアの認証URLが返ってくるのでリダイレクトします。
3Dセキュア認証後、コールバックで帰ってきたら「3Dセキュア2.0認証後決済実行」「ユーザー登録」「決済後カード登録」
という流れになります。
具体的には、
EntryTran.idPass（取引登録（有効性チェック））
↓
ExecTran.idPass（決済実行（有効性チェック））
↓
3Dセキュアのサーバへリダイレクト（3Dセキュア認証）
↓
コールバックURLに戻ってくる
↓
SecureTran2.idPass（3Dセキュア2.0認証後決済実行）
↓
SaveMenber.idPass（ユーザー登録）
↓
TradedCard.idPass（決済後カード登録）