PAY.JP における 3D セキュア

3D セキュアの基本的な説明については、こちらのガイドをご覧ください。

• 3Dセキュア認証とは

当記事では PAY.JP における 3Dセキュア認証の概要について説明いたします。

PAY.JPにおける3Dセキュアの種類

PAY.JP では、下記の 3 パターンの 3Dセキュア実施方法と2種類のワークフローがあります。

3Dセキュア実施パターン

• トークン作成時の3Dセキュア
• 支払い作成時の3Dセキュア
• 顧客カードに対する3Dセキュア

3Dセキュアワークフロー

• サブウィンドウ型
• リダイレクト型

3Dセキュア義務化要件を満たすためには、下記のどちらかを実施する必要があります。

• すべての支払い作成前に、使われるカードに対してのトークン作成時の 3Dセキュアを行う
• すべての支払い作成時に 3Dセキュアを行う

上記を併用することも可能ですが、基本的に全件に対して 3Dセキュアを実施することが求められます。
また、それ以外のタイミングにおいても不正が疑われる場合や定期課金を行なっている場合などには顧客カードに対する 3Dセキュアの実施が求められる場合があります。

どの方法を使うかの検討には3Dセキュアの各組み込み方法ごとの導入指針をご覧ください。

個人情報の取得について

3D セキュアでは、取引の安全性を確認する目的で、エンドユーザーの一部個人情報を取得します。
ご利用にあたっては、加盟店様のページ上で個人情報の取り扱いについて同意を得ていただく必要があります。
詳しくは下記資料の「顧客からの同意取得について」をご確認ください。

PAY.JP 3Dセキュア ご紹介資料

3Dセキュアワークフローとは

3Dセキュアを組み込む際、ブラウザで認証させる場合はサブウィンドウ型とリダイレクト型の2種類のワークフローで組み込みが可能です。どちらのワークフローを選んでも認証の成功・失敗には影響しませんが、実装までの流れが大きく変わります。
また、ユーザーからの画面の見え方にも影響の出るものですので、御社サービスでの実装方針に合わせて最適なものをお選びください。

• サブウィンドウ型
• リダイレクト型

モバイル SDK を使って 3Dセキュアを行う場合、ワークフローはこのどちらともなりません。
詳細な実装方法はモバイル SDK を利用して 3Dセキュアを導入するをご覧ください。

●サブウィンドウ型

3Dセキュア認証画面を表示するサブウィンドウを表示し、購入者はその内部に表示されるカード発行会社の画面上でパスワード入力等を行います。

実際にお手元で動作するサンプルをご用意しております。

サブウィンドウ型での注意事項

下記に列挙するような環境ではポップアップに対して警告やブロックが働くため、3Dセキュアが行えない場合がございます。
それを踏まえた上でご利用いただくか、リダイレクト型での実装をご検討ください。

1. ポップアップブロック

ブラウザごとのデフォルト値やユーザー設定によって、ポップアップブロック機能が有効化されている場合があります。
そのような環境からサブウィンドウ型での 3Dセキュア認証を実行しようとした場合、サブウィンドウの起動がブロックされ認証ができません。
サブウィンドウ型をそのような環境の利用者に使ってもらうには下記の対応が考えられます。

1. ポップアップブロック機能を無効化してからカード情報を入力してもらう
2. ポップアップがブロックされた際にブラウザ URL バー付近のポップアップブロック通知からポップアップを許可する

※ 2 で許可を選ぶとポップアップまたは新規タブにおいて、カード会社による 3Dセキュア認証画面が現れますが、ブロックされた時点でその認証は無効となります。
その場合再度カード情報の入力からやり直してください。

上記が難しい場合、リダイレクト型に切り替える必要があります。

2. Cross-Origin-Opener-Policyヘッダー

加盟店様サイト側でレスポンスヘッダーに Cross-Origin-Opener-Policy を設定している場合にサブウィンドの起動がブロックされる場合があります。
この場合はサイト側のヘッダー設定を変更していただくか、リダイレクト型に切り替える必要があります。

3. モバイルアプリブラウザ

モバイルアプリ内のブラウザはその中で別タブを開いたりといった機能に基本的に対応していません。
そのためサブウィンドウ型は動作しませんので、モバイル SDKのご利用をご検討いただくか、リダイレクト型に切り替える必要があります。

●リダイレクト型

サービスから PAY.JP が提供する 3Dセキュア開始エンドポイントにリダイレクトさせ、認証完了後にサービスが指定するエンドポイントにリダイレクトで戻す方式です。
リダイレクト型では 3Dセキュア画面への誘導・3Dセキュア完了処理などの実装を加盟店様側で行う必要がございます。

サブウィンドウ型に比べると実装は煩雑になりますが、一部モバイル環境ではサブウィンドウ型が適切に動作しない可能性があるため、より広い環境で動作させたい場合や、サブウィンドウのユーザー体験が望ましくない場合にはリダイレクト型をご利用ください。

PAY.JPにおける3Dセキュアの種類ごとに、3Dセキュア処理待ち状態のリソースを作成し、利用者を3Dセキュア開始エンドポイントにリダイレクトさせます。

実際にお手元で動作するサンプルをご用意しております。

3Dセキュアの認証期限時間について

3Dセキュアを完了するまでに30分以上の時間が経つと有効期限切れとなりそれ以降の手順へ進めなくなります。

3Dセキュア認証結果のハンドリング・完了処理

PAY.JP における 3Dセキュア認証フローはカード発行会社による認証に加えて、PAY.JP の 3Dセキュアフロー完了も実施する必要があります。その際、リソースの状態を確認して認証結果のハンドリングを行うことができます。

カード発行会社における認証の終了を検知したら 3Dセキュア対象リソースを取得し状態を確認します。
リソースの three_d_secure_status を確認し、後続処理を行うかを判断します。

3Dセキュアの種類ごとの後続処理は以下の通りです。

three_d_secure_status が verified または attempted であった場合、3Dセキュア認証の結果は成功とみなすことができます。しかし、たとえば完全認証を行いたい場合、 three_d_secure_status が attempted だとしても処理を中断することになります。

unverified のままであったり、error であったりする場合は、3D セキュアの手順中に離脱した、パラメーターに異常があった等の問題が考えられます。

3Dセキュア認証における追加項目

3Dセキュア認証を行う場合、カード番号・有効期限など必須の情報以外にも追加の認証項目として下記が求められます。

• カード名義
• メールアドレスまたは電話番号

必要となる背景は3Dセキュア認証とは - 3Dセキュア認証の追加項目をご覧ください。
この追加項目は 3Dセキュア実施までに対象カードに対してセットする必要があります。

具体的なセット方法については、下記をご参照ください。

• トークン作成時にセットする場合
• トークン作成時以外にセットする場合

追加項目を送信しなかった場合

当面は追加項目のパラメーターがなかったとしても決済時にエラーにはなりません。
しかし各ブランドからは本来必須として求められている情報のため、今後厳格化しエラーとなるよう仕様変更を行う可能性がございます。
その際は別途アナウンスさせていただく予定ではありますが、加盟店様におかれましては可能な限り早めのご対応をご検討くださいますようお願いいたします。

既存カードのカード名義、メールアドレス、電話番号の更新について

過去に登録したカードに対して有効なカード名義、メールアドレスまたは電話番号が登録されていない場合、3Dセキュアを実施する前にエンドユーザーに対しデータの入力を求めるようにしてください。
収集した追加項目は顧客カード更新のAPIにてセットできます。

3Dセキュア実装サンプル・デモ

実際にお手元で動作するサンプルをご用意しております。