3Dセキュア2.0（EMV 3-D Secure）は、オンラインでのクレジットカード決済時に本人認証プロセスを追加することで、Eコマースにおける不正利用のリスクを低減する仕組みです。
この記事は、エンジニアとして3Dセキュア2.0を実装する際に理解すべき点をまとめています。
なお、3Dセキュアの具体的な仕様はペイメントゲートウェイの実装によって異なる場合があるため、汎用的な点に絞って解説します。また、この記事ではブラウザーベースのフローについて説明します。ブラウザーとスマホアプリ両方のフローに当てはまる部分も多々ありますが、スマホアプリのみに当てはまるデバイス情報の取得などの仕様については解説しませんのでご了承ください。
目次
- 3Dセキュアの３つのドメイン
- 3Dセキュア2.0の2種類のフロー
- 3Dセキュア2.0の流れ
- 3Dセキュアプロセスの開始リクエスト/レスポンス
- 3DSメソッドのリクエスト/レスポンス
- 3DSサーバーへのフォーム送信
- AReq/ARes（認証リクエスト/レスポンス）
- CReq/CRes（チャレンジリクエスト/レスポンス）
- RReq/RRes（結果リクエスト/レスポンス）
- 与信（オーソリ）実施
- ユーザーへの決済結果表示
- Webhookによる決済結果通知
- まとめ
3Dセキュアの３つのドメイン
「3D」とは「3 Domains」の略で、以下の3つのドメインがこのプロトコル上でやり取りを行なうことに由来しています。
マーチャント/アクワイアラ・ドメイン（Acquirer Domain）
マーチャントは加盟店、つまりEコマースではECサイトの運営者が該当します。一方、アクワイアラは加盟店の募集・管理を行うクレジットカード会社です。3Dセキュアで本人確認が成功した後の与信電文は、アクワイアラに対して送られます。
Eコマースでは、アクワイアラと加盟店間のやり取りはペイメントゲートウェイが仲介するのが一般的です。EMV 3-D Secureの仕様において、このドメインで稼働する加盟店側のサーバーコンポーネントを「3DSサーバー（3DS Server）」と呼び、多くの場合はペイメントゲートウェイがこの機能を提供します。
イシュア・ドメイン（Issuer Domain）
イシュアはクレジットカードの発行会社です。3Dセキュアの本人確認はイシュア・ドメインが主体となって行います。イシュアが3Dセキュアの本人認証のために運用するサーバーは「アクセス・コントロール・サーバー（ACS: Access Control Server）」と呼ばれます。
インターオペラビリティ・ドメイン（Interoperability Domain）
マーチャント/アクワイアラ・ドメインとイシュア・ドメイン間のやり取りを中継し、相互互換性を保つ役割を果たします。このドメインで運用されるサーバーは「ディレクトリ・サーバー（DS: Directory Server）」と呼ばれ、VisaやMastercardなどの国際ブランドがそれぞれ運営しています。
3Dセキュア2.0の2種類のフロー
3Dセキュア2.0には2種類のフローがあり、それぞれ「フリクションレスフロー」と「チャレンジフロー」と呼ばれます。
- フリクションレスフロー (Frictionless Flow): ユーザーによるパスワード入力などの追加認証なしで進むフロー。
- チャレンジフロー (Challenge Flow): ユーザーにワンタイムパスワードの入力などを求める追加認証が発生するフロー。
どちらのフローが選択されるかは、イシュア（ACS）がカード会員情報、決済情報、デバイス情報などから不正利用のリスクをリアルタイムで判定し、トランザクションごとに決定します。
3Dセキュア2.0の流れ
1. 3Dセキュアプロセスの開始リクエスト/レスポンス
消費者のブラウザーがEコマースサイトでチェックアウトすると、Eコマースサイトのサーバーはペイメントゲートウェイ（3DSサーバー）に3Dセキュアプロセスを開始したい旨のリクエストを送信します。このリクエストは「認可リクエスト」などと呼ばれることがあります。
このリクエストには、以下のような情報が含まれます。
- カード保有者の情報（メールアドレス、電話番号、氏名）
- 消費者のIPアドレス
- 決済情報（決済金額、クレジットカード情報）
- 3Dセキュアが完了した後のリダイレクトURL、Webook通知先URL
3DSサーバーは、対象カードが3Dセキュアに対応しているか、加盟店が契約済みかなどを確認し、問題がなければレスポンスを返します。このレスポンスには、多くの場合、次のステップでブラウザーにレンダリングさせるためのHTMLが含まれます。
このHTMLには、主に以下の2つのフォームが含まれており、ページ読み込み時にJavaScriptによって自動実行されます。
- ACSへのフォーム（3DSメソッド用）
- 3DSサーバーへのフォーム
ユーザーにはフォーム自体は見えず、代わりに「処理中」を示す各カードブランドのロゴなどが表示されるのが一般的です。
2. 3DSメソッドのリクエスト/レスポンス
HTMLに含まれるACSへの送信フォームは、JavaScriptによって自動的に送信されます。このとき、フォームのtarget属性に同ページ内の非表示iframeを指定することで、画面遷移なくバックグラウンドで処理が実行されます。この一連の流れを「3DSメソッド」と呼びます。
3DSメソッドは、イシュア（ACS）ができるだけ早い段階でブラウザー情報などを収集し、リスク評価を開始するために行われます。
ただし、3DSメソッドの完了は必須ではありません。タイムアウト時間を設け、時間内にACSから応答がない場合でも次のステップに進むのが一般的です。
3. 3DSサーバーへのフォーム送信
3DSメソッドの完了後（またはタイムアウト後）、もう一方のフォームがJavaScriptによって3DSサーバーへ自動送信されます。このフォームには、3DSメソッドで収集しきれない、あるいは補完するためのブラウザー情報が含まれます。
これらの情報は、以下のようなJavaScriptコードで収集されます。
- Javaが有効か:
window.navigator.javaEnabled() - ブラウザー言語:
window.navigator.language - 画面の色深度:
screen.colorDepth - 画面の横幅:
screen.width - 画面の縦幅:
screen.height - タイムゾーン:
new Date().getTimezoneOffset()
これらのコードはペイメントゲートウェイから提供されるHTMLに含まれるため、加盟店側で実装する必要はありません。
4. AReq/ARes（認証リクエスト/レスポンス）
ブラウザーから情報を受け取った3DSサーバーは、リスク評価に必要な情報をDS経由でイシュアのACSに送信します。これを「AReq (Authentication Request)」と呼びます。
AReqには、カード会員情報、決済情報、3DSメソッドで収集したブラウザー情報などが含まれます。
AReqを受け取ったACSは、すべての情報を基にリスクを総合的に判断し、フリクションレスフローとチャレンジフローのどちらに進むかを決定します。この結果は「ARes (Authentication Response)」として3DSサーバーに返されます。
代表的なAResのステータスは以下の通りです。
Y(Yes) /A(Attempt): 認証成功。フリクションレスで完了。N(No) /U(Unknown) /R(Rejected): 認証失敗。決済は承認されない。C(Challenge): 追加認証が必要。チャレンジフローへ移行。
ステータスが C 以外の場合、次の「CReq/CRes」はスキップされます。
5. CReq/CRes（チャレンジリクエスト/レスポンス）
AResのステータスが C だった場合、チャレンジフローに移行します。ここでは、ブラウザーを介してACSと直接通信し、追加認証が行われます。
- 3DSサーバーは、ACSのチャレンジ用URLと「CReq (Challenge Request)」のデータをブラウザーに返します。
- ブラウザーは、その情報を使ってACSにCReqを送信します。CReqを受け取ったACSは、ワンタイムパスワード入力画面などをブラウザーに表示します。
- ユーザーが認証操作を完了すると、ACSは認証結果である「CRes (Challenge Response)」のデータを生成し、ブラウザーを3DSサーバーの指定URLへリダイレクトさせます。これにより、3DSサーバーはチャレンジ結果を受け取ります。
6. RReq/RRes（結果リクエスト/レスポンス）
「RReq (Results Request)」は、認証プロセスの最終結果を通知するために、サーバー間通信でACSからDS経由で3DSサーバーへ送信されます。
- フリクションレスフローの場合: AResを返した直後にRReqが送信されます。
- チャレンジフローの場合: ユーザーの認証が完了し、CResを生成した後にRReqが送信されます。
RReqに含まれるステータスはAResとほぼ同じですが、チャレンジを要求する C は含まれません。注意点として、AResではレスポンスにステータスが含まれますが、RReqではリクエストにステータスが含まれます。
3DSサーバーはRReqを正常に受信したことを伝えるために「RRes (Results Response)」を返します。
※実装によっては、フリクションレスフローではこのRReq/RResが省略され、AResの結果を最終結果とみなす場合もあります。
7. 与信（オーソリ）実施
RReq（またはARes）のステータスが認証成功であった場合、3DSサーバーはアクワイアラに対して与信（オーソリ）リクエストを送信します。
このステップは3Dセキュアを導入していない決済と同様です。本人認証が成功しても、クレジットカードの利用限度額超過などがあれば与信は失敗します。
8. ユーザーへの決済結果表示
認証と与信が完了すると、ユーザーに決済結果を表示する必要があります。3DSサーバーは、プロセス開始時に指定されたEコマースサイトのURLへブラウザーをリダイレクトさせます。
リダイレクト先URLには注文IDなどが含まれているため、Eコマースサイトはそれを使って3DSサーバーに決済の最終結果を問い合わせ、成功ページまたは失敗ページを表示します。
9. Webhookによる決済結果通知
ブラウザーのリダイレクトは、ユーザーが途中でタブを閉じるなど、通信の失敗リスクが伴います。そのため、リダイレクトとは別に、3DSサーバーから加盟店サーバーへWebhookで結果を通知する仕組みが用意されているのが一般的です。
加盟店側では、このWebhook受信を正として注文ステータスの更新などを行うことで、より確実な処理が実現できます。
まとめ
3Dセキュア2.0では、フリクションレスフローの導入により、セキュリティを確保しつつユーザーの負担を軽減する仕組みが実現されました。
エンジニアとして実装する箇所は全体の流れの一部ですが、各コンポーネントの役割や通信の流れといった全体像を把握することは非常に重要です。それにより、障害発生時の原因切り分けや、より堅牢なシステム構築が可能になります。