3Dセキュア導入事例の紹介

2025 10/22

2025年10月22日 2025年10月22日

はじめに

2025年4月より、クレジットカード決済における「3Dセキュア（本人認証）」の導入が必須となりました。
当社プロジェクトでもこれまで対応を見送っていましたが、今回の必須化に伴い導入を実施しました。
本記事では、その対応事例を共有します。

参考：
GMOペイメントゲートウェイ株式会社
「EMV 3-Dセキュア（3Dセキュア2.0）とは？仕組みやメリット・導入すべき事業者などについて解説」
https://www.gmo-pg.com/blog/articles/article-0098/

3Dセキュア2.0とは

▼3Dセキュア1.0
①　エンドユーザー（購入希望者）が購入ボタンを押下
　↓
②　認証確認画面でのパスワード※入力必須
　↓　※カードホルダー本人が予めカード発行会社に登録したパスワードで本人認証
③　購入完了

▼EMV 3-Dセキュア
①　エンドユーザー（購入希望者）が購入ボタンをタップ押下
　↓（リスクベース認証：低の場合）
②　購入完了
引用サイト：
GMOペイメントゲートウェイ株式会社 – あなたのとなりに、決済を – EMV 3-Dセキュア（3Dセキュア2.0）とは？仕組みやメリット・導入すべき事業者などについて解説
https://www.gmo-pg.com/blog/articles/article-0098/

前提

今回はとあるプロジェクトのカートシステムに3Dセキュアの対応を実装しました。

一度の注文で複数の受注が作成され、それぞれで決済処理を行う可能性がある運用となっています。

3Dセキュアの導入

本プロジェクトでは一般的な決済代行サービスを利用しています。

通常、1回の購入で1件の受注（決済）しか発生しない場合は、その注文に対して3Dセキュアを実施すれば問題ありませんのでシンプルな実装となります。
しかし今回のケースでは、1回の購入で複数の受注（決済）が発生するため、3Dセキュアを実行するタイミングを検討する必要がありました。

決済のたびに3Dセキュアを実行するというのは現実的ではありません。
そのため、決済代行サービスの担当者にも確認を行い以下の対応方針に決定しました。

クレジットカードの有効性チェックを行う仮取引を作成し、そのタイミングで3Dセキュアを実施する
1.でチェックOKの場合、そのカード情報を利用して全ての注文について決済を実施する

このようにすることで、比較的シンプルな構造を保ちつつ3Dセキュアの導入を進めることができました。
通常3Dセキュアは各カード会社の専用ページにリダイレクトするため、そのページでのユーザーの動き（ブラウザバックしてしまったり、そのままブラウザを閉じてしまったり）も考慮する関係で注文のトランザクションの管理も複雑になってしまいますが、今回はカードの有効性チェックのみのため、3Dセキュア成功時以外のフローがシンプルになりました。

最終的な3Dセキュア実装フローは以下の通りです。

注文の確定
3Dセキュア処理ページへリダイレクト
3Dセキュア処理
3DセキュアのコールバックURLへPOSTリクエスト
注文の完了処理（受注の作成や決済）

スマホアプリでの対応

続いて、3Dセキュア導入にあたり課題となったスマートフォンアプリ側の対応について紹介します。

本プロジェクトのスマホアプリは、基本的にはWebViewを利用してWebアプリをそのまま表示する構成で開発しています。

セキュリティの対策として許可したドメインのみを表示できるようにしているのですが、この場合3Dセキュアをアプリのみで完結させることが困難でした。
ドメインが事前に分かっていれば対応可能ですが、クレジットカード会社ごとに異なる多数のドメインへ個別対応するのは現実的ではありません。そのため、より汎用的な対応方法を検討しました。

制約はあるものの、3Dセキュアの処理のみを別のWebViewで実行する方式を採用しました。
ただし、この方法でもカード会社ごとのページ構成によっては、想定外のページへ遷移できてしまう場合があります。
そのため、一定時間内に3Dセキュアの処理が完了しなかった場合は、そのWebViewを破棄することでリスクの軽減を図りました。

最終的な処理フローは下記のようになりました