3D セキュア

このページでは、バージョン1と2の両方のワークフローをeSuite REST APIの範囲内で3Dセキュアがどのようにサポートされているかを詳しく説明します。

概要

3Dセキュアのバージョン1は2001年にVisaによって最初にロンチされ、その後、MastercardやAmexなどのによって導入されました。これは、カード所有者を認証することで不正行為からの保護を追加し、クライアントのライアビリティシフトを​​導入することを目的としています。 v1プロトコルは広く利用可能ですが、主にユーザーエクスペリエンスと関連するワークフローのため、クライアントによって導入されました。カード所有者は銀行で3Dセキュアプログラムに登録するように要求されます、そして各トランザクションごとにパスワードなどの入力を求められます。3D Secure v1プロセスは、モバイルアプリとブラウジングの使用が一般的になるにつれて、3DSecureに関連するインターフェイスとメソッドは、これらのシナリオはうまく処理出来ておりません、代わりにデスクトップブラウジングに適しています。

2019年に3Dセキュアバージョン2が導入され、欧州地域内でのカスタマー認証強化（SCA）の必要性、および該当するPSD2規制のプロモーションを受けました。 3D セキュア v2は、最新のデータキャプチャと分析を利用して意思決定プロセスを改善し、バイオメトリクスやワンタイムパスコード（OTP）などの新しい認証方法を導入して、カード所有者の認証に対する最新のアプローチを提供します。 3Dセキュアv2のもう1つの大きな変化は、この標準が最初に単一のスキームで導入されたのではなく、ビザ、マスターカード、アメリカンエクスプレス、ディスカバー、JCBやユニオンペイなどの主要なスキームの組み合わせを含むEMVCoによって合意されたことです。
これにより、決済プロセスの各部分（ゲートウェイ、アクワイアラ、発行者など）によるトランザクションの処理方法に関する厳格なルールを使用して、より統一されたアプローチが実現しました。モバイルアプリとブラウザーを最適化することを目的として、これによりユーザーへのフリクションを軽減し、発行者がカード所有者のシナリオに適用するUXも標準化されました。

3D セキュア　バージョン1

3Dセキュア バージョン1は、Visa、Mastercard、およびAmerican Expressスキームカードのトランザクションをサポートしています。

現在、3D セキュア v1は次のeSuite REST API内でサポートされています。

  • POST api/accounts/{accountReference}/subscriptions
  • POST api/accounts/{accountReference}/payments
  • POST api/workflows/purchases/subscriptions
  • POST api/workflows/purchases/products
  • POST api/workflows/purchases/miscellaneous-charge
  • POST api/workflows/purchases/service-credits

現在、3D セキュア v1を以下のeSuite REST APIに導入して、2019年9月に予定されているSCA要件に対応するための作業が進行中です、申し訳ございませんが現在テストできません。これらのエンドポイントは、3Dセキュアの現在のユースケースを、購入シナリオだけでなく、カードの更新やサブスクリプションのアップグレードなどの他の顧客開始トランザクション（CIT）シナリオにも拡張します。

  • POST api/accounts/{accountReference}/payment-details/card
  • POST api/accounts/{accountReference}/subscriptions/{subscriptionReference}/move

ワークフロー

eSuite内のアフィリエイトIDで3D セキュア v1が有効でアクワイアラ MIDが3D セキュアトランザクションが対応後、このカード所有者認証のワークフローのインテグレーションとテストに関わる作業が開始可能です。

  • TermUrlが構成されていることを確認してください。これは、3D セキュアv1ワークフロー中にイベントの通知を送信するためにeSuiteによって使用される固定URLです。
  • 標準の購入タイプのコールをご利用ください。　例 POST api/workflows/purchases/products
  • eSuiteは、非同期プロセスパラメータ内の必要な情報にレスポンスし、ワークフローを続行します（以下を参照）。
  • iFrame内では、クライアントはthreeDSecureAcsUrl、threeDSecureMD、threeDSecurePaReqの値をPostする必要があります。
  • このiFrameは、ACSのイシュアに 3Dセキュアページをカード所有者に提示し、必要に応じて"challenge"を完了するよう依頼します。
  • エンドユーザーによって"challenge"を完了後、ACSのイシュアはポスト内のMDおよびPaRes値を含むiFrameをTermUrlにリダイレクトします。
  • クライアントは、iFrame内のTermUrlへのポストバックをイベントとして検出し、MDおよびPaRes値をキャプチャしてiFrameを閉じます。
  • クライアントは、MD値とPaRes値を渡すPATCHをコールし処理を完了する必要があります。
  • eSuiteは、PATCHをコールしトランザクションの成功結果でレスポンスします。

以下に、3D セキュアv1のワークフローに含まれるステップのプロセス図を例に示します。

3D セキュア V1 トランザクションに成功したワークフロー

このシナリオは、上記のマルチステップワークフローに従っており、完全なエンドツーエンドの3Dセキュアワークフローを示しています。

 

 

3D セキュア V1 トランザクションに失敗したワークフロー

このシナリオでは、ユーザーによるACSのイシュアが 3D Secureページ内のchallengeの完了に失敗する場合を示しています。トランザクションはカード会員の認証に失敗した為、トランザクションが拒否されたとしてeSuiteから返されます。

 

 

発行者が3D Secure v1をサポートしていない場合のワークフロー

このシナリオでは、3D セキュア v1をサポートしないという初期要求がイシュアから返されます。したがって、threeDSecureAcsUrl、threeDSecureMDおよびthreeDSecurePaReqの値はeSuiteのレスポンスで返されず、ワークフローは標準認証（つまり3Dセキュアが適用されていない場合）になります。

 

  

 

 

3D セキュア バージョン 2

3Dセキュアバージョン2は現在開発中であり、完成すると最終仕様が利用可能になります。当面の間は、3D セキュア 2.0 – キーの更新ページを確認することにより、このサービスのベータ仕様が開発されるにつれて、仕様の利用が可能になります。

3D セキュアv2は、Visa、Mastercard、American Express、Discover、JCB、およびUnionPayのスキームカードトランザクションを対応しています。