本人認証サービス補足資料（3Dセキュア2.0対応版）
本ガイドについて
本ガイドの内容
本ガイドには、VeriTrans4Gの本人認証サービス（3Dセキュア2.0）における処理フロー、
処理結果コード及びそれらによる判定方法等について記載したものとなります。
関連ドキュメント
MDKの導入、システム構築の仕方については、技術マニュアル『MDK インストールガイド』をご参照ください。
Ruby / Java / .NET / PHP8
決済時に指定するパラメータ等につきましては『3Dセキュア(3DS2.0)開発ガイド』をご参照ください。
決済サービスオプションタイプについて
VeriTrans4G本人認証サービスでは、3Dセキュア認証の結果をもとにクレジットカード与信（カード与信）処理まで実施可能です。
カード与信を実施するかしないかの判定ルールは、「決済サービスオプションタイプ（serviceOptionType）」に指定する値によって異なります。
「serviceOptionType」に指定する値は、基本的には加盟店様にてご決定いただくものとなります。
商材によっては、カード会社（アクワイアラ）より『完全認証』でのサービス提供を求められるケースがございます。
全体的な注意点：
VeriTrans4G決済サーバは基本的にカード会社側（ブランド、ACS）の応答内容をベースに処理を行います。
特にステータスA（Attempt）に関しては、どのようなケースで Attempt になるかはわかりません。
契約（マスタ）チェック周りの判定詳細につきましては「A-0 判定フロー（キャッシュ判定）」をご確認ください。
「serviceOptionType」の値と、対応するカード与信処理ルールは以下のようになります。
mpi-none（単体認証）
本人認証（3Dセキュア認証）のみを実施し、カード与信は実施しない。
カード与信の実施の判断と処理（リクエスト）は加盟店様で行います（実装する必要があります）。
カード与信の実施については、mpi-none 以外のモードの判定を参考に実装してください。
mpi-complete（完全認証）
ARes/RReq にてステータス値 Y を受信した場合のみ、カード与信を実施します。
ステータス A (Attempt)のケース、3Dセキュア認証未対応ブランドのカード、加盟店様が3Dセキュアのご利用契約をされていないブランドのカード、
カード発行会社が未対応のカード（ ブランドキャッシュ未登録）の場合、カード与信処理は行いません。
mpi-complete でカード与信を実施するケース
RReq Yのみ
mpi-company（通常認証）
完全認証のカード与信実施ケースに加え、カード与信のチャージバックリスクがイシュアリスク負担となる場合にカード与信を実施します。
3Dセキュア認証未対応ブランドのカード、加盟店様が3Dセキュアのご利用契約をされていないブランドのカードの場合、カード与信は行いません（例外あり）。
また、利用されたカードが通常は問題ないカードの場合でも、3Dセキュア認証処理にてエラーなどが発生した場合もカード与信は行いません。
mpi-company でカード与信を実施するケース
RReq YまたはA
以下は新規で3Dセキュアを導入される場合や、3Dセキュア1.0を使用していなかった場合は考慮不要です。
Diners ブランドのオーソリをJCB社に仕向けている加盟店様につきましては、Dinersブランドの設定有無により動作が異なります。
設定あり：3Dセキュア認証を実施し、その結果に従って後続処理を決定
設定なし：加盟店リスクでオーソリを行う（1.0と同じ振る舞い）
詳しくは「A-0 判定フロー（キャッシュ判定）」と「X.JCB仕向けのDinersの提供について」をご確認ください。
三井住友トラストクラブ仕向けの場合は他ブランドと同様の振る舞いとなります。
mpi-merchant（通常認証：加盟店リスクあり）
できる限りカード与信を実施するモードになります。
3Dセキュア認証未対応ブランドのカード、加盟店様が3Dセキュアのご利用契約をされていないブランドのカード、処理中にエラーが発生した場合でも加盟店リスク負担でカード与信を実施します。
ただし、3Dセキュア認証処理が正常に行われ、明確にNG（ステータスN受信ケースなど）の場合、カード与信は行いません。
なお、通常正常に処理されればイシュアリスク負担で3Dセキュア認証されるカードでも、エラーが発生してカード与信を実施したケースは加盟店リスク負担の決済となります。
mpi-merchant でカード与信を実施するケース
RReq 取引が特定できれば判定がエラーとなった場合でもカード与信を実施（判定がN、Rの場合は与信は行わない）
具体的な実施ケースは「B.シナリオ別コード一覧」をご確認ください。
注意事項
*1 チャレンジフローを実施しないフラグを指定した場合、RReqは実施されないため、AResにてチャレンジフロー判定された場合、決済は行われません。
3Dセキュア認証における留意点
本章では、3Dセキュア認証サービスにおける留意点についての説明となります。
3Dセキュア認証は「イシュア」領域の機能（サービス）です
クレジットカードの与信は「アクワイアラ」に対して電文を送信いたしますが、3Dセキュアの認証は「イシュア」によって提供されるサービスとなります。
カード与信が A 社に送信される場合でも、3Dセキュア認証の詳細（なぜＸという結果になったのか？）をA 社に問い合わせることで
回答を得ることはできません。
そのため、3Dセキュア認証の結果等について確認したい場合は、消費者様（カードホルダ）よりそのカードの発行元にお問い合わせいただく必要がございます（除く：VeriTrans4G側での障害など）
※この点については、3Dセキュア認証1.0でも同等です。
結果コード（vResultCode）は、各種3Dセキュア電文のステータスとマッピングされています。
3Dセキュア認証の電文には、トランザクションステータス（transactionStatus）という項目があり、結果コード（vResultCode）は
この項目に設定された値とマッピングしております（例えば、AResでNを受信した場合はGE23とする、など。決済サービスオプションタイプに指定した値により、トランザクションステータスの値とのマッピングが変わる（結果コードが異なる）ケースがあります）。
具体的なマッピングにつきましては「5-3．結果判定マトリックス」や「B.シナリオ別コード一覧」をご確認ください。
※この点については、3Dセキュア認証1.0でも同等です。
認可リクエストにおける任意項目について
基本的な補足事項
これらを指定することが認証結果にどのように作用するかについて、明確な情報は開示されておりません。
そのため、例えば「配送先住所情報」を指定することで認証にどれくらい影響するのか？（チャレンジとなる率が下がるのか？）といった
お問い合わせにご回答することはできません。ご理解くださいますようお願いいたします。
※今後、運用していく中で得られた情報につきましては随時資料に追加いたします
なお、3Dセキュア認証は「イシュア」により提供されております。仮にあるイシュアが X という仕様だということが判明した場合でも、
他のイシュアが必ずしも同じとは限りません。また、海外にもイシュアは存在いたします。
入力チェック仕様となっているか不明な点があります。
リリース前に必ず本番モードで動作確認を実施してください。
DS/ACS側の動作は予告なく変更されることになりますので、データ設定をできるだけ簡潔に変更（設定しないように変更）できるような
形での実装を推奨いたします。
要求パラメータ「消費者IPアドレス」について（本ドキュメントバージョン1.0.4より記載、1.0.5にて更新）
3Dセキュア2.0運用開始後、複数のアクワイアラより「消費者IPアドレス（customerIp）」を電文に設定するように要請を受けております。
決済サーバへの要求電文において、IPアドレスは任意項目となっておりますが、決済サーバ側で収集可能とするように対応いたします。
決済サーバでの収集にあたっては、MAPより加盟店様にて収集機能を有効（ON）にしていただく必要がございます。
決済サーバの収集機能をご利用にあたっては、IPアドレスの収集に関して消費者様から個人情報利用における同意取得を行うことが前提となります。
収集機能を有効にする操作は、個人情報利用における同意取得に対応のうえで実施くださいますようお願いいたします。
MAPからの操作方法は次のようになります。
- MAPにログイン
- 画面右上の「各種設定変更」をクリック
- 各種決済設定変更の「本人認証」で「IPアドレスを自動収集する」にチェックをし（以下参照）、「変更」ボタンを押下し、変更します
決済フロー
フリクションレスフロー
フロー
MAPに記録される内容
上記フローにおいて MAP(A)(B)(C)それぞれのタイミングでMAPにレコードが記録されます。
成功時）
失敗時
チャレンジフロー
フロー
MAPに記録される内容
上記フローにおいて MAP(A)(B)(C)(D)(E)それぞれのタイミングでMAPにレコードが記録されます。
成功時）
失敗時）
フロー(mpi-none)
MAPに記録される内容(mpi-none)
上記5.2.3のフローにおいて MAP(A)(B)(C)(D)それぞれのタイミングでMAPにレコードが記録されます。
成功時）
失敗時）
結果判定マトリックス
ARes
| ステータス | 意味合い | 後続処理 | mpi-none | mpi-complete | mpi-company | mpi-merchant |
|---|---|---|---|---|---|---|
| Y | 認証成功 | オーソリを実施する | G011/success | |||
| N | 認証失敗 | オーソリ実施しない※1 | GE23/failure | |||
| C | チャレンジ実施要求 | チャレンジフローを実施する | 未確定 | |||
| R | 認証拒否 | オーソリ実施しない※1 | GE24/failure | |||
| A | 試行（Attempt） | オーソリを実施する※2 | GE32/failure | G012/success | ||
| U | エラー発生 | オーソリ実施しない※1 | GE25/failure | G004/success | ||
| なし※ | - | オーソリ実施しない※1 | GE26 or GE27 or GE28 / failure | G005/success | ||
RReq
| ステータス | 意味合い | 後続処理 | mpi-none | mpi-complete | mpi-company | mpi-merchant |
|---|---|---|---|---|---|---|
| Y | 認証成功 | オーソリを実施する | G011/success | |||
| N | 認証失敗 | オーソリ実施しない※1 | GE31/failure | |||
| R | 認証拒否 | オーソリ実施しない（※1） | GE31/failure | |||
| A | 試行（Attempt） | オーソリを実施する（※2） | GE32/failure | G012/success | ||
| U | エラー発生 | オーソリ実施しない※1 | GE33/failure | G013/success | ||
| なし※ | - | オーソリ実施しない※1 | GE34 or GE35 or GE36/failure | G014/success | ||
※ ステータス「なし」は受信した電文からステータスを取得できなかった、または3DS Server内部でエラーが発生した場合
※1 オーソリを実施した場合は加盟店リスクとなります
※2 mpi-none / mpi-complete の場合、mstatusは失敗扱いとなる。mpi-complete の場合オーソリは実施しません
※3 通信がタイムアウトするなどで取得できなかった場合、3DS Server内部でエラーが発生した場合
その他補足事項
ダミーモードの試験について
クレジットカード決済では、あらかじめ決められたカード番号が利用可能です。
エラーは指定するクレジットカードの有効期限によってコントロールします。
本人認証サービスの試験は、3Dセキュア認証で取りうるシナリオ（各電文のステータス値やエラー発生）に対して
カード番号が割り振られており、指定したカード番号により、3Dセキュア認証結果が異なります。
具体的なシナリオ（認証パターン）と、そのシナリオに紐づくテストカード番号は「B.シナリオ別コード一覧」を参照ください。
「B.シナリオ別コード一覧」に記載のシナリオは本人認証の動作パターンとなります。
本人認証は成功、その後カード与信NGというパターンを実施したい場合、本人認証のシナリオに合わせたカード番号と、カード決済の
エラーシナリオの有効期限（例：12月/99年）を指定してください。
その他、ダミーモードの動作仕様につきましては、「導入テストガイド」もご確認ください。
verifyTimeout 判定について
決済サーバが決済申込を受信してから3Dセキュア認証結果が確定するまでに一定時間を経過していた場合、3Dセキュア認証の結果が
認証OK（カード会社リスクでカード与信可）の場合でもエラーとするためのパラメータです。
例えば、加盟店サイト側のセッションタイムアウトが15分なのに、認証に20分かかったといったケースでカード与信が行われないように
制御することが可能です（verifyTimeout には加盟店サイトのタイムアウトより短い時間を指定してください）。
この verifyTimeout の判定開始とチェックポイントを「5-1.3Dセキュア2.0決済フロー（フリクションレスフロー）」と
「5-2.3Dセキュア2.0決済フロー（チャレンジフロー）」シートに記載しておりますのでご確認ください。
判定の開始ポイント
時間経過の判定ポイント
本人認証結果確認（MpiGetResult）の運用について（バージョン1.0.5で追記）
決済申込から一定時間経過しても決済申込時に指定したリダイレクションURI（redirectionUri）にアクセスが戻ってこない取引に対してバッチ処理で本人認証結果確認を実施される場合、「これ以上確認しても成立することはない」という時間を経過したあとは本人認証結果確認の対象とならないよう、制御をお願いいたします。
例えば（具体的には）、verifyTimeout に 10（10分）を指定した場合、加盟店様の時間カウントで11または12 分経過して結果が確認できない取引については、その後のバッチで確認対象とならないように配慮をお願いします。
このようなリクエストが確認された場合は、テクニカルサポートより改善のご依頼をさせていただきます。
3D Transaction Status Reason について
認証がNGのケースで、ARes/RReq には 3D Transaction Status Reason というパラメータを受信するケースがあります。
この値により、認証NGとなった理由をある程度予測することは可能です。
3Dセキュアのプロトコルで定義されている値は以下のようになります。
なお、詳細の意味をお問い合わせいただいても回答はできませんので、ご了承ください。
| 値 | 説明 |
|---|---|
| 01 | Card authentication failed |
| 02 | Unknown Device |
| 03 | Unsupported Device |
| 04 | Exceeds authentication frequency limit |
| 05 | Expired card |
| 06 | Invalid card number |
| 07 | Invalid transaction |
| 08 | No Card record |
| 09 | Security failure |
| 10 | Stolen card |
| 11 | Suspected fraud |
| 12 | Transaction not permitted to cardholder |
| 13 | Cardholder not enrolled in service |
| 14 | Transaction timed out at the ACS |
| 15 | Low confidence |
| 16 | Medium confidence |
| 17 | High confidence |
| 18 | Very High confidence |
| 19 | Exceeds ACS maximum challenges |
| 20 | Non-Payment transaction not supported |
| 21 | 3RI transaction not supported |
| 22 | ACS technical issue |
| 23 | Decoupled Authentication required by ACS but not requested by 3DS Requestor |
| 24 | 3DS Requestor Decoupled Max Expiry Time exceeded |
| 25 | Decoupled Authentication was provided insufficient time to authenticate cardholder. ACS will not make attempt |
| 26 | Authentication attempted but not performed by the cardholder |
| 27-79 | Reserved for EMVCo future use (values invalid untildefined by EMVCo) |
| 80-99 | Reserved for DS use |
結果コードの詳細説明と発生時の対応
決済サーバが返戻する結果コードの大まかな分類と、発生時の対応についてまとめます。
加盟店様の監視ルール検討などで参考にしてください。
以下、「3DS Server」は「決済サーバ」と同義となります。
| 結果コード | 発生時の対応 |
|---|---|
| GAxx | ※後述の具体的な結果コードを除く 単発の発生であれば様子見してください。 発生数が気になる場合はテクニカルサポートまでお問い合わせください。 現状、GA07, GA08 がまれに発生することが確認できておりますが、いずれもACSからの戻り値不正が事由で発生したものであり、単発での発生は一時的なカード会社システムの不具合または通信異常が考えられます。 |
| GA11 | verifyTimeoutをご利用の場合で、指定した時間を経過した場合に発生します。 ユーザ操作起因（時間内に認証が完了しなかった）で発生するエラーのため問題ありません。 |
| GA18 ※重要 |
決済は成立していませんので、お客様にはしばらく待ってから再度決済を行っていただくようにご案内してください。このエラーが多発する場合は、テクニカルサポートまでお問い合わせください。 このエラーは、ACSからバックグランドで行われる通信（RReq）が 3DS Server に届かずに画面遷移が行われた場合に発生します。 チャレンジ認証においてインターネット経路（ACS --> DS --> 3DS Server）で通信障害（遅延含む）が発生していた可能性があります。フリクションレスフローでは発生しません。 |
| GE21 | 発生した場合は決済サーバのマスタ設定状況を要確認となりますので、テクニカルサポートまでお問い合わせください。 なお、ご契約などによって特定条件で発生するケースもございます。 |
| GE23 GE24 GE31 |
3Dセキュア認証自体は正常に実施されており、カード会社の判定による認証NGとなります。 |
| GE32 | 3Dセキュア認証自体は正常に実施されており、カード会社の判定による「みなし認証成功（Attempt）」となります。 完全認証（mpi-complete）または認証のみ利用（mpi-none）の場合に発生します。 この結果コードは、カード会社のリスク負担で決済に進むことができることを示しますが、mpi-completeの場合は決済に進むことができません。カード会社から完全認証を求められていない限り、通常認証（mpi-company）に変更すればカード会社リスクで決済に進むことができますので、ご検討ください。 |
| GE25 GE33 |
単発の発生であれば様子見してください。 消費者環境（User-Agentなどで判定）事由による発生が考えられます。 多発する場合は、カード会社側の問題が考えられますので、テクニカルサポートまでお問い合わせください。 |
| GE28 ※重要 |
AReq送信時、3DS Server --> DS の通信でエラーが発生したときに返戻されます。 このエラーが多発すると何らかの障害が発生している可能性が考えられます。 MAPでこのエラー取引の詳細画面にアクセスすると詳細のメッセージが表示されますので、お問い合わせ前に一度ご確認ください。 発生例としては、DSとの通信でタイムアウトとなるケース、DSまたはACSの障害があげられますが、3DS Server（決済サーバ）の不具合でも発生する可能性はございます。 住所などのパラメータを指定している場合、指定した値のフォーマットの問題で本結果コードが返戻される可能性もあります（重要）。 |
MAPの表示例
|
|
| GE36 ※重要 |
単発の発生については様子見してください。 RReq で3DS Serverが受信したデータ（電文）解析でエラーが発生した時に返戻される結果コードとなります。 GE28と同様、MAPで該当取引の詳細画面に詳細メッセージが表示されますので、お問い合わせ前にご確認ください。 繰り返し発生する場合は障害が発生している可能性がございます。 過去の発生例：ECIの値（必須）が受信したデータに含まれていなかった |
| GE26 GE27 GE34 GE35 GH01 |
何らかのエラー発生時に返戻される結果コードとなります。 単発の発生については様子見してください。 多発する場合は、障害の発生が疑われます。障害発生箇所の特定には詳細の確認が必要になりますので、テクニカルサポートまでお問合せください。 左記GExxの過去の発生事例としては、DSからエラー電文（3Dセキュア電文に合致しない）を受信したケースがあります。 GH01の発生事例はありません。 |
| GE22 | mpi-completeでのみ発生します。 3DS Serverで保持しているキャッシュデータにリクエストされたカード情報と合致するデータが存在しない場合に返戻されます。 キャッシュに含まれないのは基本的に3Dセキュア2.0に対応していないことになるため、完全認証（mpi-complete）ではエラーと判定します。 |
| GE29 | withChallengeパラメータを指定していなければ発生しません。 |
以下に続くGBxx、GCxx のエラーはMAPでは確認できない結果コードとなります。
これらの結果コードは加盟店様側でログを監視していないと検知できない結果コードとなりますが、決済サーバ側で監視を行っているため、
加盟店様にて監視しなければならないということではございません（単発の発生で弊社からご連絡するものではありません）。
| 結果コード | 発生時の対応 |
|---|---|
| GB10 GB11 GB12 GB22 - GB35 |
決済サーバの設定と、処理対象のクレジットカード番号の組合せの不整合により発生する可能性があります。 内容確認後となりますが、決済サーバ側の設定変更が必要になる場合があります。 GB12については、ハウスカードなど、3Dセキュア対象外のカードで認証を実施しようとした場合に応答される結果コードとなるため、発生イコール設定不備というわけではございません。 |
| GB13 - GB20 | 決済サーバ内のデータ不整合が発生した場合に発生しうるコードとなりますが 過去発生したことはございません。 |
| GCxx |
※後述の具体的な結果コードを除く パラメータの入力チェックエラー系の結果コードとなります。繰返し発生する場合は、そのパターンに何らかの不具合が生じている可能性が考えられます。 GCxx の多くは決済サーバでは問題ないエラーとして監視対象外となります。 |
| GCA0 GCA3 GCA4 |
単発で発生した場合は様子見してください。 繰返し発生する場合はテクニカルサポートまでお問い合わせください。 今のところ発生は確認されておりません。 |
| GCA2 | ブラウザバックなど、ユーザ操作で発生しうるエラーとなります。 多発しなければ特に問題ありません。 |
| GB21 GE01 - GE06 GE11 - GE16 |
3Dセキュア2.0では発生しない結果コードとなります（3Dセキュア1.0の認証でのみで発生） |
A-0．判定フロー（キャッシュ／仕向け判定）
A-1．判定フロー（mpi-none/mpi-complete）
A-2．判定フロー（mpi-company）
A-3．判定フロー（mpi-merchant）
B．シナリオ別コード一覧
下記の一覧表は、決済サービスオプションタイプごとに各シナリオ（電文の応答パターン）と結果コード（vResultCode）のマッピングをまとめたものとなります。
決済フラグの設定(決済無し／完全認証／通常認証(カード会社リスク負担)／通常認証(マーチャントリスク負担)／未参加ブランド)とチャレンジ認証の実施フラグの設定（チャレンジ認証を行う／チャレンジ認証を行わない）によって処理が異なります。
| リスク負担 | テストカード | 認可（MDKコマンド処理） | 検証（決済サーバー内部処理） | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| No | シナリオ | カード会社／ 加盟店 |
カード番号 | 決済サービスオプションタイプ | 決済無し （mpi-none） |
完全認証 （mpi-complete） |
通常認証 （mpi-company） |
通常認証 （mpi-merchant） |
決済サービスオプションタイプ | 決済無し （mpi-none） |
完全認証 （mpi-complete） |
通常認証 （mpi-company） |
通常認証 （mpi-merchant） |
|||
| リスク負担 | - | カード会社 | カード会社 | カード会社 or 加盟店 |
リスク負担 | - | カード会社 | カード会社 | カード会社 or 加盟店 |
|||||||
| 3D未対応ブランド決済可否 | × | × | × | ○ | 3D未対応ブランド決済可否 | × | × | × | ○ | |||||||
| キャッシュ登録 | mStatus※1 | vResultCode | ARes Status |
RReq Status |
mStatus※1 | vResultCode | ||||||||||
| 1-1 | 本人認証失敗 AResステータスN |
（決済不可） | 378282246310005 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | N | failure | GE230000 | GE230000 | GE230000 | GE230000 | |
| 1-2 | 本人認証失敗 AResステータスR |
（決済不可） | 5105105105105100 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | R | failure | GE240000 | GE240000 | GE240000 | GE240000 | |
| 1-3 | 本人認証失敗 チャレンジ認証実施 RReqステータスN、R |
（決済不可） | 5555444455554442 5111111111111118 |
有 | success | G0010000 | G0010000 | G0010000 | G0010000 | C | N R |
failure | GE310000 | GE310000 | GE310000 | GE310000 |
| 2-1 | 本人認証成功 AResステータスY (チャレンジ不要) |
カード会社 | 4111111111111111 36111111111111 371449635398431 |
有 | success | G0010000 | G0010000 | G0010000 | G0010000 | Y | success | G0110000 | G011A001 | G011A001 | G011A001 | |
| 2-2 | 本人認証成功 RReqステータスY (チャレンジ認証で成功) |
カード会社 | 377752749896404 2222222222222224 |
有 | success | G0010000 | G0010000 | G0010000 | G0010000 | C | Y | success | G0110000 | G011A001 | G011A001 | G011A001 |
| 3-1 | 本人認証成功 AResステータスA |
カード会社 | 5555555555554444 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | A | failure 又は success |
GE320000 | GE320000 | G012A001 | G012A001 | |
| 3-2 | 本人認証成功 RReqステータスA |
カード会社 | 371111111111114 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | C | A | failure 又は success |
GE320000 | GE320000 | G012A001 | G012A001 |
| 4-1 | 本人認証実行不可 （未対応・未契約ブランド※2） |
加盟店 | 3528000000000007 | なし | failure 又は success |
GE210000 | GE210000 | GE210000 | G0020000 | G002A001 | ||||||
| 4-2 | 本人認証実行不可 （未対応・未契約ブランド※2） このシナリオは、新規で3Dセキュアを導入される場合や、3Dセキュア1.0を使用していなかった場合は考慮不要です |
加盟店 | 36363636363632 | 有 | failure 又は success |
GE210000 | GE210000 | G0020000 | G0020000 | G002A001 | G002A001 | |||||
| 5 | 本人認証実行不可 （ブランドキャッシュ未登録※3） |
- *3 | 3530111333300000 | なし | failure 又は success |
G0070000 | GE220000 | G0070000 | G0070000 | A ※3 | G012A001 ※3 | G012A001 ※3 | ||||
| 6-1 | 本人認証失敗 AResステータスU |
加盟店 | 36666666666660 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | U | failure 又は success |
GE250000 | GE250000 | GE250000 | G004A001 | |
| 6-2 | 本人認証失敗 ARes電文解析エラー |
加盟店 | 3528000000000023 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | Error | failure 又は success |
GE260000 | GE260000 | GE260000 | G004A001 | |
| 6-3 | 本人認証失敗 RReqステータスU (チャレンジ認証実施) |
加盟店 | 3528000000000015 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | C | U | failure 又は success |
GE330000 | GE330000 | GE330000 | G013A001 |
| 6-4 | 本人認証失敗 RReq電文解析エラー (チャレンジ認証実施) |
加盟店 | 341111111111111 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | C | Error | failure 又は success |
GE340000 | GE340000 | GE340000 | G013A001 |
| 7-1 | 異常終了 （AReq処理で通信 またはシステムエラー） |
加盟店 | 5500000000000004 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | 不定 | failure 又は success |
GE270000 GE280000 |
GE270000 GE280000 |
GE270000 GE280000 |
G005A001 | |
| 7-2 | 異常終了 （RReq処理で通信または システムエラー） |
加盟店 | 2342342342342341 | 有 | success | G0010000 | G0010000 | G0010000 | G0010000 | C | 不定 | failure 又は success |
GE350000 GE360000 |
GE350000 GE360000 |
GE350000 GE360000 |
G014A001 |
| 凡例： 加盟店リスクで決済 |
||||||||||||||||
※赤字は主に前のバージョンからの変更点となります
※1 応答コードが「GExx」の場合は "failure"（失敗）、「G0xx」の場合は "success"（成功）となります。
※2 判定ルールについては「A-0 判定フロー（キャッシュ判定）」を参照
※3 シナリオ5は、テストシナリオとしては、ARes = A の動作となりますが、本番取引ではAReqを実行する、という意味合いで、必ずしもその応答が A になる保証があるわけではありません。
そのため、リスク負担もシナリオ 5の前半だけで決まるものではなく、サービスオプションタイプの指定とARes、そのあとの処理結果に従います。テストシナリオの結果に限れば「カード会社」リスクとなります。
＜成功系・認可処理＞
G001=本人認証実行可能です。
G002=決済実行可能です。（条件付成功）
G004=決済実行可能です。（条件付成功）
G005=決済実行可能です。（条件付成功）
G007=本人認証実行可能です。（条件付成功）
＜成功系・検証処理＞
G011=本人認証に成功しました。
G012=本人認証に成功しました。（条件付成功）
G013=本人認証に成功しました。（条件付成功）
G014=本人認証に成功しました。（条件付成功）
＜失敗系・認可処理＞
GE21=本人認証実行不可です。（利用契約なしマスタ未登録）
GE22=本人認証実行不可です。（DSキャッシュなし）
GE23=本人認証実行不可です。（認証失敗AResステータスN）
GE24=本人認証実行不可です。（認証拒否AResステータスR）
GE25=本人認証実行不可です。（技術的要因などAResステータスU）
GE26=本人認証実行不可です。（異常応答ARes）
GE27=本人認証実行不可です。（センタ接続通信エラーが発生({0})）
GE28=本人認証実行不可です。（本人認証ライブラリでエラー発生）
GE29=本人認証実行不可です。（チャレンジが必要）
＜失敗系・検証処理＞
GE31=本人認証に失敗しました。（チャレンジ失敗RReqステータスNまたはRReqステータスR）
GE32=暫定的に認証成功とみなされました。（認証試行AResステータスAまたはRReqステータスA）
GE33=本人認証に失敗しました。（技術的要因などRReqステータスU）
GE34=本人認証に失敗しました。（異常応答RReq）
GE35=本人認証に失敗しました。（センタ接続通信エラーが発生({0})）
GE36=本人認証に失敗しました。（本人認証ライブラリでエラー発生）
C．mpi-none についての補足
mpi-none について
mpi-none は、3Dセキュア認証のみ行うモードとなります。
3Dセキュアの認証結果をもとにカード決済を実施するかどうかは加盟店様にて判断する必要があります。
mpi-none モードの判定ルールは、基本的にはmpi-complete と同じとなります（G007となるケースを除く）。
そのため、mpi-company モードと同様のルールでカード与信をコントロールする場合、mpi-none の判定結果がNG(mstatus=failure)と
なった場合でも vResultCode の値をもとにカード決済を行うという判定が必要となります。
3Dセキュア認証の結果をクレジットカード与信に設定する
3Dセキュア認証の結果が認証OKの場合でも、その結果をカード与信（電文）に設定しなければ、その与信のリスクは加盟店リスクとなります。
3Dセキュア認証の結果をカード与信に設定する場合、「カードオプションタイプ（cardOptionType）」に "mpi" を設定し、3Dセキュア関連のパラメータ（dddEci など、ddd で始まるパラメータ）に値を設定します。
具体的なパラメータは以下になります（クレジットカード決済の開発ガイドも参照ください）
| パラメータ名（カード決済） | 応答フィールド名（本人認証サービス） | ||
|---|---|---|---|
| フィールド名 | 項目名 | 詳細パラメータ連携 | Search結果/ResponseDto |
| メッセージバージョン | dddMessageVersion | dddMessageVersion | res3dMessageVersion |
| DSトランザクションID (*1) | dddDsTransactionId | dddDsTransactionId | res3dDsTransactionId |
| 3DSサーバトランザクションID (*1) | dddServerTransactionId | dddServerTransactionId | res3dServerTransactionId |
| トランザクションステータス | dddTransactionStatus | dddTransactionStatus | res3dTransactionStatus |
| CAVV | dddCavv | dddCavv | res3dCavv |
| ECI | dddEci | dddEci | res3dEci |
| CAVVアルゴリズム | dddCavvAlgorithm | dddCavvAlgorithm | res3dCavvAlgorithm |
| トランザクションID(*2) | dddTransactionId | dddTransactionId | res3dTransactionId |
(*1) 3Dセキュア2.0で追加された項目
(*2)オーソリ仕向け先がJCBのAMEX取引においては dddTransactionId を設定する必要があります。決済サーバから返戻された場合は設定するように実装してください。
※ v1.0.3 補足：将来的に dddTransactionId は応答しないようになります。
※ v1.0.6 補足：JCB社からの要請によりあらためて dddTransactionIdを応答するように変更されます。
そのため、ECIの値が取得できないケースでもカード与信を行う場合（リスク負担は加盟店様になります）、カードオプションタイプに "mpi" を指定しない通常のカード決済を行うか、ECI に "07" という固定値を指定してください。
必ず値が返戻される前提の実装はしないでください。
補足
カードセンターを介してカード会社（アクワイアラ）に連携される与信電文には、3Dセキュアの項目を設定する箇所があります。
3Dセキュア2.0の開始に伴い、上記(*1)のパラメータが追加されました。
決済サーバは dddMessageVersion の値が 2.x.x の場合に (*1) のパラメータ電文に設定します。
(*1)のパラメータが設定されるケースは dddMessageVersion の値も返戻されますので、値の設定が漏れないようご注意ください。
mpi-none と MDKトークンについて
トークンサーバから取得したMDKトークンの値は 1度だけ利用できます（1度利用すると使えなくなります）。
mpi-none モードで 3Dセキュア認証とカード与信を分けて実行する場合、MDKトークンが 2つ必要となります。
トークン取得処理を 2度実行し、取得した2つのトークンの値を加盟店様サーバに連携し、1つを3Dセキュア認証、もう 1つをカード与信の電文に設定するという実装が必要となります。
D．3DS Method から AReq が実行されるまでの処理フロー
VeriTrans4Gでは、決済申込の応答に含まれる「応答コンテンツ」の内容（HTML)をクライアントのブラウザにロードさせる流れとなりますが、
本資料は「応答コンテンツ」がブラウザにロードされた際（ブランドのロゴとスピナーが表示されている間）の処理フローの補足となります。
AReq が処理されるまでの処理フローとなるため、フリクションレスフロー、チャレンジフローで共通の流れになります。
なお、実際にブラウザに表示されるブランドごとのロゴやスピナーファイルの取得といった部分は省略しております（すべての処理を記載しているわけではありません）。
また、この部分のフロー（HTMLの構成やタイムアウト値など含む）は予告なく変更する可能性があります。
a) 3DS Method が定義されたカード情報の場合
b) 3DS Method 未定義
c) 3DS Method処理でタイムアウト
X) resResPonseContents を利用した画面遷移（認証開始URL提供前のフロー）
X.Searchを利用している加盟店様へのご案内
本項にて記載している内容は3Dセキュア2.0には直接関係する内容ではございません。
ご注意事項：
決済サーバが払い出す「トランザクションID」について、その値の大小がトランザクションの順番を保証するものとはならないため、Searchをご利用の加盟店様は実装をご確認ください。
本人認証の結果判定の観点では、「リクエストID」を検索条件に含めているかをご確認ください。
対応：
トランザクションIDで順番をチェックしているロジックがある場合、取引日時（txnDatetime）の値でチェックする形に修正してください。
または、チェックしたいトランザクションの条件（例えば「売上」の「成功」トランザクションを探す）をご調整ください。
ご不明な点につきましてはテクニカルサポートまでお問い合わせください。
補足：
詳細パラメータ連携を利用されていない場合、本人認証（＋カード決済）完了時のリダイレクトで加盟店様に連携されるパラメータは「取引ID」と「リクエストID」となります。
MDKサンプルの実装では検索パラメータに「リクエストID」を指定して検索（Search）を行う実装となっておりますが、
その後の流れでトランザクションIDが最新のものを判定する実装例が含まれております。
検索パラメータとして「リクエストID」を指定した場合、応答に含まれるトランザクション情報は最大で2つとなります。
うち 1つが本人認証の結果（トランザクション種別・txnKind が "mpi"）、もう１つがカード決済の結果（同 "card"）です。
そのため、サンプル実装（具体的なロジックの説明は後述）でも誤判定されることはありませんが3Dセキュア2.0対応に合わせて改めてご確認をお願いいたします。
該当するサンプルの実装ロジック
Java版）
・・・ （略 62行目前後）・・・
long txnIdMPI = 0;
…
long txnIdCard = 0;
for (int i = 0; i < index; i++) {
bufTxnId = Long.valueOf(transactionInfo[i].getTxnId()).longValue();
bufMStatus = transactionInfo[i].getMstatus();
bufVResultCode = transactionInfo[i].getVResultCode();
…
// MPI～カード決済までが実行された場合
// このタイミングでリクエストIDによる検索を実行すると
// txnKindが"mpi"と"card"のレコードがそれぞれ１件取得できる
// MPI認証結果(複数件ある場合は最新の一件を取得)
if (bufTxnKind != null && bufTxnKind.equals("mpi")) {
if (bufTxnId > txnIdMPI) {
mStatusMPI = bufMStatus;
vResultCodeMPI = bufVResultCode;
txnIdMPI = bufTxnId;
}
}
// カード決済結果(最新の一件を取得)
if (bufTxnKind != null && bufTxnKind.equals("card")) {
if (bufTxnId > txnIdCard) {
mStatusCard = bufMStatus;
vResultCodeCard = bufVResultCode;
txnIdCard = bufTxnId;
}
}
}
….NET版）
CoreMvcApplication.Controllers
MpiController
・・・ （略 163行目前後）・・・
[HttpPost]
public IActionResult Search([FromForm(Name = "orderId")] string orderId,
...
var mpiTxnId = "";
...
var cardTxnId = "";
...
var txnId = info.TxnId;
...
// MPI認証結果を取得(複数件の場合最新をチェックする)
if (!string.IsNullOrWhiteSpace(txnId) && txnKind == "mpi")
{
if (string.IsNullOrWhiteSpace(mpiTxnId) || Convert.ToInt64(txnId) > Convert.ToInt64(mpiTxnId))
{
mpiStatus = mStatus;
mpiVResultCode = vResultCode;
mpiTxnId = txnId;
}
}
// カード決済結果を取得（複数件の場合最新をチェックする）
if (!string.IsNullOrWhiteSpace(txnId) && txnKind == "card")
{
if (string.IsNullOrWhiteSpace(cardTxnId) || Convert.ToInt64(txnId) > Convert.ToInt64(cardTxnId))
{
cardStatus = mStatus;
cardVResultCode = vResultCode;
cardTxnId = txnId;
}
}
…PHP版）
web/mpi/SearchExec.php
・・・ （略 114行目前後）・・・
$txn_id = 0;
$mpi_txn_id = 0;
$card_txn_id = 0;
for($i = 0; $i < count($transaction_info_list); $i++) {
...
$txn_id = $transaction_info_list[$i]->getTxnId();
...
// MPI認証結果を取得(複数件の場合最新をチェックする)
if (isset($txn_id) && "mpi" == $txn_kind) {
if ($txn_id > $mpi_txn_id) {
$m_status_mpi = $m_status;
$v_result_code_mpi = $v_result_code;
$mpi_txn_id = $txn_id;
}
}
// カード決済結果を取得（複数件の場合最新をチェックする）
if (isset($txn_id) && "card" == $txn_kind) {
if ($txn_id > $card_txn_id) {
$m_status_card = $m_status;
$v_result_code_card = $v_result_code;
$card_txn_id = $txn_id;
}
}
…Ruby版）
web/app/controllers/web/mpi/authorize_controller.rb
※re_authorize_controller.rbも同様の実装
・・・ （略 254行目前後）・・・
@txn_id = "";
@mpi_txn_id = 0;
@card_txn_id = "";
…
@transaction_info_list.each do |info|
@txn_id = info.txn_id
…
# MPI認証結果を取得(複数件の場合最新をチェックする)
if @txn_id != "" && "mpi" == @txn_kind
if @mpi_txn_id == "" || @txn_id.to_i > @mpi_txn_id.to_i
@m_status_mpi = @m_status
@v_result_code_mpi = @v_result_code
@mpi_txn_id = @txn_id
end
end
# カード決済結果を取得（複数件の場合最新をチェックする）
if @txn_id != "" && "card" == @txn_kind
if @card_txn_id == "" || @txn_id.to_i > @card_txn_id.to_i
@m_status_card = @m_status
@v_result_code_card = @v_result_code
@card_txn_id = @txn_id
end
end
…X. JCB仕向けDinersの提供について
はじめに
※本章は、新規で3Dセキュアを導入される場合や、3Dセキュア1.0を使用していなかった場合は考慮不要です。
本章は、「JCB社によるDinersの3Dセキュア2.0オーソリの受け入れ」の開始前に、その他国際ブランドの3Dセキュア2.0への移行完了
または利用開始済みの加盟店様が、新たにDinersの3Dセキュア2.0をJCB仕向けで導入される際にご注意いただきたい内容を説明しています。
三井住友トラストクラブ仕向け（カード会社コード01）でDinersの取引を実施されている加盟店様には関連「しない」内容となります。
本章の想定の読者：
Dinersの決済を JCB社に仕向けるご契約となっている加盟店様で、かつ、JCB社がDinersの3Dセキュア2.0のオーソリを受け入れる前に
3Dセキュア2.0のご利用を始めた加盟店様。
システム的な動作としては、Dinersのカード番号を使って3Dセキュア認証を実施した場合に、「B.シナリオ別コード一覧」に記載のパターンにおける「シナリオ4-2」の動作となっている加盟店様。
※以下、「加盟店様」は上記の条件に合致している前提の記載となりますのでご留意ください。
何がかわるのか？
決済サーバの設定としては、JCB仕向けDinersの場合に 3Dセキュア認証で利用する「アカウント情報」を加盟店様のマスタに追加設定いたします。
以下、どのように動作が変わるのかについてご説明いたします。
現在（設定前）、加盟店様よりDinersのカード情報とともに3Dセキュア認証の決済リクエストを受信した場合、次のような判定の流れになります（「A-0 判定フロー（キャッシュ判定）」より抜粋）
このような動作をしている中で、JCB仕向けDinersのための「アカウント情報」が登録されると、以下のように流れが変わります。
ご利用開始前に実施しておくべきこと
決済サーバにアカウント情報が設定されると上記のように即座に動作がかわります。
しかしながら、加盟店様のマーチャントIDに同設定を行うタイミングはご指定「できません」
そのため、動作確認で問題がないことをご確認いただいたうえで、弊社に登録のご依頼をお願いいたします。
確認方法
ダミーモードにて以下のカードでテストを行い、Dinersブランドでシナリオ 4 以外となるケースで問題がないことをご確認ください。
36111111111111本カードを指定した場合、「B. シナリオ別コード一覧」のシナリオ「2-1（ARes = Y）」で動作するようになっています。