認証シーケンス

次のシーケンス図は、3DS2認証処理について、特に3DS2フローにおけるGPaymentsの APIを使用した3DSリクエスターの役割に焦点を当てて各ステップを段階を追って示したものです。

• 処理 1: 認証の初期化
  • ステップ1～ステップ7
• 処理 2: 認証の実行
  • フリクションレス・フロー: ステップ8～ステップ13、およびステップ14(F)
  • チャレンジ・フロー: ステップ8～ステップ13、およびステップ14(C)～ステップ19(C)
• 処理 3: 認証結果の取得
  • フリクションレス・フロー: ステップ15(F)～ステップ17(F)
  • チャレンジ・フロー: ステップ20(C)～ステップ22(C)

1. 認証の初期化用の情報を送信 ←3DSリクエスターの処理

   • カード番号やカード会員の氏名など、決済ページで得られたカード会員情報が、3DS web adapterに送信されます。これは加盟店のフロントエンドシステムをシミュレートした簡潔なJavaScriptのコードです。

2. 認証の初期化　←3DSリクエスターの処理

   • 3DS web adapterは決済ページから収集した情報を使用して3DSリクエスターへのPOSTリクエストを行い、3DSリクエスターに認証の初期化を要求します。

3. 認証の初期化 (/brw/init/{messageCategory})　←3DSリクエスターの処理

   • 3DSリクエスターはフロントエンドから情報を取得し、/brw/init/{messageCategory}へのPOST API呼び出しを行って認証を初期化します。
   • ここで送信される重要なフィールドはeventCallbackUrlであり、ActiveServerがこのURLへのコールバックを行ってブラウザーの情報収集完了を通知できるようステップ8を開始するために必要です。

4. threeDSServerCallbackUrlを応答

   • /brw/init/{messageCategory}からの正常な応答にはthreeDSServerCallbackUrlとthreeDSServerTransIDが含まれています。

5. threeDSServerCallbackUrlを応答 ←3DSリクエスターの処理

   • 3DSリクエスターは3DS web adapterにthreeDSServerCallbackUrlを返します。

6. コールバックiframeを設置 ←3DSリクエスターの処理

   • src属性をthreeDSServerCallbackUrlに設定した非表示のiframeを挿入します。これにより、ActiveServerは3DSリクエスターに接続できる状態になります。ActiveServerは、このiframeへのコールバックを行います。

7. ブラウザ情報の収集

   • ActiveServerはiframeを使用してブラウザー情報を収集し、ACSが3DSメソッドデータを収集できるようにします。次に、ACSは、用意されたiframeを使用して3DSメソッドデータを収集します。

8. コールバック関数の呼び出し ←3DSリクエスターの処理

   • 認証の初期化中、3DSメソッドが終了またはスキップされたときにACSが3DSリクエスターに通知できるよう、3DSリクエスターはeventCallBackUrlを送信します。 ステップ７で設置したiframeからPOST要求がこのeventCallBackUrlに行われます。
   • 3DSリクエスターは、この要求を受けiframe内に必要なcallbackFn含めたパラメーターと一緒にnotify-3ds-events.htmlを表示します。notify_3ds_events.htmlは表示後3ds-web-adaterに定義されたcallbackFnを呼び出します。

9. 認証の実行 ←3DSリクエスターの処理

   • callbackFnは_on3DSMethodSkipped()または_on3DSMethodFinished()のいずれかであり、どちらもdoAuth()を呼び出します。3DS web adapterはdoAuth()を呼び出し、認証を実行するよう3DSリクエスターに要求します。
   • _on3DSMethodSkippedはブラウザの情報がなんらかの理由によってACSが取得できなかったことを意味します。なので、もしこのコールバック関数が呼ばれた場合加盟店は認証を続行しない選択をすることもできます。

10. 認証の実行 (/brw)

    • 3DSリクエスターは/brwを呼び出して認証処理を開始します。

11. AReq/ARes

    • 認証リクエスト（AReq）は、ディレクトリ・サーバーを介してActiveServerからACSに送信されます。ACSからは、認証結果を含む認証応答（ARes）がActiveServerに送信されます。

12. 認証結果を応答

    • /brwは、3DSリクエスターにtranStatusを返します。

13. 認証結果を応答 ←3DSリクエスターの処理

    • 認証結果を3DS webアダプターに返します。

フリクションレス・フローの場合¶

14(F). 結果の表示（フリクションレスの場合) ←3DSリクエスターの処理

• 認証結果のtransStatusが"Y"の場合はauthSuccess()が呼び出され、ページを/auth/result?transIdにリダイレクトします。

15(F). 認証結果を要求 (認証結果を表示するページが必要な場合) ←3DSリクエスターの処理

• ブラウザーがtransIdで3DSリクエスターに通知し、取引結果がリクエストに使用できる状態になります。

16(F). 認証結果を要求(/brw/result)

• 3DSリクエスターは/brw/resultを呼び出し、ActiveServerから結果を受信するように要求します。

17(F). ブラウザに結果を表示

• 結果画面が開き、認証結果が表示されます。

チャレンジフローの場合¶

14(C). iframe の設置（チャレンジの場合）。

• 認証結果のtransStatusが"C"である場合はstartChallenge()が呼び出され、チャレンジ用のiframeを挿入します。

15(C). HTMLの交換

• ACSはiframe内にチャレンジ画面を埋め込み、カード会員は認証チャレンジを実行します。

16(C). チャレンジ結果の判定

• ACSは、実行されたチャレンジが成功したかいなかを判定します。

17(C). RReq/RRes

• ACSは、ディレクトリ・サーバーを介してActiveServerに、認証結果を含む結果リクエスト（RReq）を送信します。ActiveServerは、結果応答（RRes）を使用して受信確認通知を送信します。

18(C). チャレンジ応答（最終的なCRes）

• ACSは、最終的なチャレンジ応答（CRes）を3DSリクエスターに送信します。

19(C). 3DSチャレンジを終了して結果画面を表示 ←3DSリクエスターの処理

• チャレンジが終了したため、3DSリクエスターはページを/auth/result?transIdにリダイレクトします。

20(C). 認証結果を要求(認証結果を表示するページが必要な場合)　 ←3DSリクエスターの処理

• ブラウザーがtransIdで3DSリクエスターに通知し、取引結果がリクエストに使用できる状態になります。

21(C). 認証結果を要求(/brw/result)　 ←3DSリクエスターの処理

• ステップ16(F)と同様に、3DSリクエスターは/brw/resultからの結果受信を要求します。

22(C). ブラウザに結果を表示　 ←3DSリクエスターの処理

• ブラウザーで結果画面が開き、認証結果が表示されます。