refirio.org

プラグインの導入: ECCube VeriTrans4G決済プラグイン(4.0系)

■概要 4.0系|VeriTrans4G決済プラグイン(4.0系)|ベリトランス株式会社 https://www.ec-cube.net/products/detail.php?product_id=1835 ※2020年7月に確認すると、「EC-CUBE対応バージョン」は「4.0.0, 4.0.1, 4.0.2, 4.0.3」となっている。 現状4.0.4はサポートしていないとのこと。 このプラグインを使うなら、ECCube本体は4.0.3を使う方が無難か。もしくは実質4.0.4でも問題ないか。 ※2021年2月に確認すると、「EC-CUBE対応バージョン」は「4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5」となっていた。 以下にマニュアルがあるので、これをもとに進める。 https://www.ec-cube.net/upload/manual_file/04151400_5e9694fe5c61f.pdf ■API設定情報を確認 ベリトランス管理画面で、あらかじめAPI設定情報を確認しておく。 ダッシュボード下部で「API設定情報」の「API設定情報はこちら」をクリック。 「API設定情報」として表示される内容を控えておく。 ■インストール（P.11） ECCube管理画面「プラグイン → プラグインを探す」からプラグインを入手。 「購入する」をクリックする。（無料で購入できる。） 公式サイトで購入処理を行うと、「プラグイン → プラグインを探す」に「VeriTrans4G決済プラグイン(4.0系)」が表示される。 「インストール」をクリックする。 インストール確認画面が表示されるので、再度「インストール」をクリックする。 インストールが完了したら、ダイアログに表示されている「完了」をクリックする。 プラグイン一覧で、プラグインを有効化する。 ステータスが「無効」から「有効」になれば成功。 プラグインは以下に保存された。 html\app\Plugin\VeriTrans4G html\html\plugin\vt4g 以下にログファイルが作成された。（必要に応じて書き込み権限を与えておく。） html\var\log\mdk.log データベースに、以下のテーブルが作成された。（説明はマニュアルより。） plg_vt4g_order_log ... 決済ログ保持テーブル plg_vt4g_order_payment ... 決済情報保持テーブル plg_vt4g_payment_method ... 各決済方法の設定情報保持テーブル plg_vt4g_plugin ... プラグイン設定情報保持テーブル また、dtb_customerテーブルに以下の列が追加された。 `vt4g_account_id` varchar(100) DEFAULT NULL ■プラグインの設定（P.20） プラグイン一覧の設定アイコンをクリックする。 API設定情報でメモした内容をもとに、以下のように設定する。 マーチャントCCID: A100000000000001234567xx マーチャント認証鍵: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx マーチャントID: （空欄のまま） ハッシュシード: （空欄のまま） トークンAPI キー: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 取引IDプレフィックス: TEST_ 有効にする支払方法: クレジットカード決済 ダミーモード: ダミーモードで稼働 注文完了メール送信タイミング: 注文完了画面表示時 「登録」ボタンをクリックする。 ■支払い方法の設定（P.22） ECCube管理画面「設定 → 店舗設定 → 支払い方法設定」から設定を行う。 今回は一覧から「クレジットカード決済」をクリックする。 今回は以下を変更してみる。 支払い種別: 「一括払い」のみにチェックを入れる。 ベリトランス会員IDプレフィックス: TEST_CARD_ 「登録」ボタンをクリックする。 ■配送方法の設定（P.26） ECCube管理画面「設定 → 店舗設定 → 配送方法設定」から設定を行う。 今回は「サンプル業者」の詳細画面で「取り扱う支払方法」から「クレジットカード決済」にチェックを入れる。 「登録」ボタンをクリックする。 ■動作確認（P.28） 通常の手順でカートに商品を入れ、レジに進む。 配送方法で、上記で設定した「サンプル業者」を選択すると、お支払い方法で「クレジットカード決済」を選択できる。 注文確認画面に進むと、 お支払方法: クレジットカード決済(￥0) と表示されている。（「(￥0)」は手数料が表示されており、「設定 → 店舗設定 → 支払方法設定」から設定できる。） そのまま「注文する」ボタンをクリックする。 「クレジットカード決済」という画面が表示される。 ※この時点でECCube管理画面の「受注管理 → 受注一覧」を確認すると、以下のデータが確認できる。 対応状況: 新規受付 支払方法: クレジットカード決済 決済状況: （空欄） クレジットカード番号: 4111111111111111 カード有効期限: 12/20 カード名義人名: TARO YAMADA セキュリティコード: 123 お支払い方法: 一括払い 「入力したクレジットカード情報でお支払い」ボタンをクリックする。 ご注文完了画面に遷移する。 通常の完了メッセージとご注文番号に加えて、「クレジットカード決済情報」として以下が表示された。 決済取引ID: TEST_363534656663653700000000002 ■与信とオーソリについて クレジットカードにおける与信とは、カード利用者を信用して利用限度額を与えること。 一般的なクレジットカードの仕様として、購入時にオーソリ（仮売上処理）を行うことで、後から購入確定と引き落としを行うことができる。 ただしこれには期限が定められていて、最大60日と決められている。 クレジットカードのオーソリゼーションのお話。 - メモ代わりのブログ https://murabit.hatenablog.com/entry/2020/09/01/182838 クレジットカードの与信とは？途上与信・与信確保についても解説｜クレジットカードの三井住友VISAカード https://www.smbc-card.com/nyukai/magazine/knowledge/credit.jsp オーソリにより、利用限度額を正確に把握したり、支払い遅延トラブルがあったかなどを確認し、 EC事業者が安全に取引できるようにしている。 オーソリ（オーソリゼーション）とは?クレジットカード決済において必要な理由｜決済代行のSBペイメントサービス https://www.sbpayment.jp/support/ec/card_beginner/about-authorization/ 与信とオーソリについては、このファイル内を「与信」「オーソリ」で検索すると詳細がある。 ■決済の確認 ベリトランス管理画面の取引検索画面で 決済品目: クレジットカード決済 取引ID: TEST_363534656663653700000000002 テスト取引: 「除外する」チェックを外す として検索。 先程テストしたデータが表示されていることを確認する。 この時点では、「ステータス」は「与信」となっている。 ECCube管理画面「受注管理 → 受注一覧」から確認すると、以下のデータが確認できる。 対応状況: 新規受付 支払方法: クレジットカード決済 決済状況: 与信 また、詳細画面の下部に「ベリトランス4G決済情報」が表示されている。 「売上確定(実売上)実行」をクリックすると売上が確定されるみたい。 対応状況: 新規受付 支払方法: クレジットカード決済 決済状況: 売上 なお「対応状況」は自動で変わらなかった。（「新規受付」のまま。） 手動で「入金済み」に変更することはできた。 ベリトランス管理画面の取引検索画面で再度確認すると、 「ステータス」が「売上」となっているデータが追加されていた。 ■決済時の「与信」を「与信+売上」に変更 クレジットカード決済のオーソリとは？安全性をさらに高める対策も紹介｜クレジットカード決済代行のベリトランス株式会社 https://www.veritrans.co.jp/tips/column/authorization.html クレジットカード決済では売上確定などの処理は必要ですか？ - イプシロンよくある質問 https://www.epsilon.ne.jp/support/faq/ufaqs/credit002/ ECCube管理画面「設定 → 店舗設定 → 支払い方法設定 → クレジットカード決済」から設定を行う。 処理区分: 与信のみ ↓ 処理区分: 与信+売上 「登録」ボタンをクリックする。 この状態でクレジット決済すると、購入完了直後で以下の状態になった。 対応状況: 入金済み 支払方法: クレジットカード決済 決済状況: 売上 なお、与信から売上確定に変更できる期間は60日間と定められている。 クレジットカードのオーソリゼーションのお話。 - メモ代わりのブログ https://murabit.hatenablog.com/entry/2020/09/01/182838 また、デビットカードの場合はその性質上与信の時点で引き落とされる。 デビットカードの正しい基礎知識と使い方 ｜ JCBデビット https://www.jcb.jp/products/jcbdebit/article1/ ■決済キャンセルへの対応 ・ECCubeの注文詳細画面で「[売上済]再売上(実売上)実行」をクリックすると、ベリトランス管理画面で「ステータス」が「キャンセル(売上)」のデータが追加された。 前回の売上をキャンセルして、再度売上にしたということだと思われる。 ・同画面で「取消(返品)実行」をクリックすると、決済が取り消された。 取り消し後、詳細画面に「お支払い合計と決済の金額が異なります。」と警告が表示されるようになった。 恐らく「入金済みで売上金額も記録したが、その後取り消されたのでカード決済状況とデータベースの内容に差異がある」という警告だと思われる。 （この警告は、再オーソリを行なうことで表示されなくなるみたい。後述の「金額変更への対応」「与信切れへの対応」「「お支払い合計と決済の金額が異なります。」の表示が残るパターン」も参照。） また、「対応状況」は「新規受付」になっている。 ■決済金額減額への対応 ※以下で正しいはず…というもの。 一例だが、以下の手順で決済金額の減額ができる。 1. 「商品A」と「商品B」の商品を普通に購入し、クレジットカードで決済完了。 2. 管理画面から受注情報を編集して「商品B」を削除し、内容を確定させる。 3. 「お支払い合計と異なります」のエラーになる。 4. 「再売上(実売上)実行」ボタンを押す。 このとき、決済ログには以下が記録された。（下の2行は、決済金額減額によって追加されたもの。） 決済取引IDが変更されているが、決済情報は以下のとおり変化が無かった。 「決済取引ID」は変わらず古い方が表示されているが、 ログを確認する限り減額は行われている。（3865から始まる決済はキャンセルされ、6539から始まる決済が登録されている。） 「決済取引ID」は新しい方が表示される方が自然に思うが、このプラグインの仕様みたい。 （意図的に「最初の取引」の情報を残しているのか。もしくは単に不具合の可能性もあるが詳細不明。） なお決済金額を変更する場合、与信の金額よりも小さければ（つまり減額なら）そのまま処理できる。 決済金額の増額については、後述の「決済金額増額への対応」を参照。 決済金額を減額する方法が知りたい｜クレジットカード決済代行の株式会社DGフィナンシャルテクノロジー（DGFT,旧：ベリトランス株式会社） https://www.veritrans.co.jp/trial/4g/faq/3g_qno_64.html ■決済金額増額への対応 ※以下で正しいはず…というもの。 ユーザ側から9,800円の商品を購入。 合計15,180円。 決済ログには以下が記録された。 金額が変更になる例として、管理画面で72,000円の商品を追加。 合計94,380円。 いったん「保存する」をクリック。 保存すると「お支払い合計と決済の金額が異なります。」と表示される。 この状態で「再オーソリ実行」ボタンをクリック。 決済ログには以下が追加で記録された。 https://pay.veritrans.co.jp/maps/search の取引検索画面で 決済品目: クレジットカード決済 取引ID: （上記でメモした値） テスト取引: 「除外する」チェックを外す として検索。 先程テストしたデータが表示されていることを確認する。 （「TEST_383533616661663500000000370」と「TEST_346461343463396600000000370」でそれぞれ検索する。） なお決済金額を増額する場合、再度与信が行われる。 もし再度の与信に失敗した場合、元の受注をキャンセルして、新しい受注を登録する。 与信については、後述の「与信切れへの対応」も参照。 決済金額を増額する方法が知りたい｜クレジットカード決済代行の株式会社DGフィナンシャルテクノロジー（DGFT,旧：ベリトランス株式会社） https://www.veritrans.co.jp/trial/4g/faq/3g_qno_65.html ■与信切れへの対応 ※以下で正しいはず…というもの。 ドキュメントに明示されているわけでは無いので注意。 ECCubeがどうこうではなく一般的なクレジットカードの仕様として、 購入時にオーソリ（仮売上処理）を行うことで、後から購入確定と引き落としを行うことができる。 ただしこれには期限が定められていて、最大60日と決められている。 クレジットカードのオーソリゼーションのお話。 - メモ代わりのブログ https://murabit.hatenablog.com/entry/2020/09/01/182838 それを踏まえてベリトランスの仕様として、オーソリの期限が切れると「与信有効期限切れ」というステータスになる。 これをECCube側で自動感知する仕組みは用意されていない。 そしてECCubeの挙動として、オーソリ期限が切れたものを決済したければ「再オーソリ実行」ボタンを押して再度オーソリを行うことができ、 これによりベリトランス側でのステータスも変更される。 （新たなオーソリ（与信）を取得後、元の取引のキャンセルが実行される。） あとは通常の手順で売上確定処理を行うことができる。 なお、ここで元の取引が与信有効期限切れになっていると、取引のキャンセルに失敗するため、エラーが表示される。 が、あらたな与信の取得に成功していれば、売上確定処理は可能。 …となっている模様。 「再オーソリ実行」に「最大60日」などの期限が関係あるかどうかまでは調べられていない。 ■「お支払い合計と決済の金額が異なります。」の表示が残るパターン ※クライアントからの依頼で他の方に調査してもらった内容を、調整して転載したもの。 「お支払い合計と決済の金額が異なります。」の表示は、 ベリトランスプラグイン用のテーブルデータと、ECCube標準の受注テーブルデータの金額とが異なっている場合に表示されている模様。 前者は plg_vt4g_order_payment.memo10 に（PHP配列の内容がシリアライズされて）格納されており、後者は dtb_order.payment_total に格納されている。 何のために表示しているかはベリトランスに聞くのが確実だが、おそらく再オーソリ・再売上を促すために表示していると思われる。 この警告は、残るパターンとそうでないパターンがある。 警告が残るパターン： 1. 受注登録（商品は2つ） 2. クレジット決済実施 3. 商品を1つ削除し、保存ボタンを押下する前に再オーソリボタン押下（減額前の金額で再オーソリされる） 4. 商品が消えていないので、もう一度商品を削除し、保存ボタン押下 警告が残らないパターン： 1. 受注登録（商品は2つ） 2. クレジット決済実施 3. 商品を1つ削除し、保存ボタンを押下後、再オーソリボタン押下（減額後の金額で再オーソリされる） 前者であっても「オーソリの金額は減額前だが、実際に売上として記録する際は（タイムラグがあるので）減額後の金額が使われる」みたい。 ただしどちらにせよ、恐らく「警告が残らないパターン」の手順で対応するのが正しい流れだと思われる。 ■EMVについて EMVとは、国際カードブランドであるVisaとMasterCardが策定した「ICチップ搭載クレジットカードの統一規格」のこと。 両社の頭文字である「M」と「V」に、規格策定当時ヨーロッパでMasterCardブランドを運営していたEuropay Internationalの「E」を加えて「EMV」と名付けられた。 EMV対応カードは、情報が暗号化された状態でICチップに保管されているため、磁気カードよりも安全性が高い。 EMVとは？ICチップ搭載クレジットカードの統一規格について - Finance&Robotic - 株式会社ROBOT PAYMENT https://www.robotpayment.co.jp/blog/creditcard/3957/ ■セキュリティコードについて セキュリティコードとは、カード番号や有効期限とは別に、セキュリティを保護するために入力を求められるコードのこと。 3桁もしくは4桁の番号で、クレジットカードの裏面または表面に記載されている。 セキュリティコードは、カード券面の印字によってのみ確認できるものであり、クレジットカードの磁気情報の中には含まれていない情報。 磁気情報に含まれているのは、カード番号と有効期限のみなので、所有者以外の第三者がセキュリティコードを知るためには、カード本体を確認する必要がある。 スキミングやクレジットマスターなどの不正利用防止に有効とされる。 ただし、カード本体の盗用に対しては無力。 クレジットカードのセキュリティコードとは？EC事業者が知るべき不正利用の対策 | ヤマト運輸 https://business.kuronekoyamato.co.jp/promotion/learning/payment/security-code/index.html ■本人認証（3Dセキュア）について 本人認証（3Dセキュア）とは、インターネット上でクレジットカード決済をより安全に行うために、国際カードブランドが推奨する本人認証サービス。 各ブランドごとに名称は異なるが、総称して「EMV 3-Dセキュア」と呼ばれている。 3Dセキュアにおける「3D」とは。 ・EC事業者その決済ゲートウェイ ・カード発行会社（楽天カード、イオン銀行、りそなカードなど） ・3Dセキュア認証システム提供元（Visa、MasterCard、American Express、JCBなど） の3つの領域を表す「ドメイン（Domain）」を意味しており、この三者間で適切な認証を行ないながらカード利用者の安全性を確保している。 カードの保有者であるユーザーが3Dセキュアを利用するには、事前に3Dセキュア提供元にパスワードを登録する必要がある。 利用時はカード情報の入力後3Dセキュアパスワード入力画面に遷移し、パスワードを入力することになる。 セキュリティコードとは異なり、仮にカードを盗難された場合でも「本人しか把握していない情報」で認証するため、不正利用防止に繋がる。 3Dセキュア2.0の前身である3Dセキュア1.0は、1999年にVisaが開発した本人認証システム。 ECでの決済など非対面での決済時に、カード番号や有効期限などのカード情報の他に、 あらかじめ設定したパスワードを入力することでセキュリティを強固にする。 ただしカゴ落ちが増えるというデメリットがあり、なかなか普及しなかった。 3Dセキュア2.0では、SMSやアプリを使用したワンタイムパスワードを導入できる。 またリスクベース認証（なりすましを防ぐ認証技術）により、 リスクの高い取引のみに対して承認を要求することができるようになったため、ユーザーにとっての障壁が低くなった。 取引の大半は追加認証なしに認証が完了されるが、高リスクと判断される取引のみ、ワンタイムパスワード等の追加認証が実施される。 3Dセキュア1.0は2022年10月をもって各ブランドでサポートが終了された。 よってこれから対応する場合は3Dセキュア2.0であることが必須となる。 以下は3Dセキュア2.0での認証の流れ。 1. 購入手続き 顧客がECサイトなどで、クレジットカードを使って決済を行う。 2. 認証ページへの遷移 決済ゲートウェイからカード会社に認証の要求が送られ、3Dセキュア認証ページにリダイレクトされる。 3. 本人認証の実施 ・パスワード入力型：事前に登録したパスワードを入力する。 ・ワンタイムパスワード (OTP)：SMSやメールで送信されたコードを入力する。 ・生体認証：指紋や顔認証などで認証する。 4. 認証結果の確認 カード会社が本人確認を完了すると、認証の成功・失敗を加盟店側に通知する。 5. 決済完了 認証が成功した場合、決済が確定し購入が完了される。 2025年までに導入が義務化される3Dセキュア2.0 ECサイトで必須級の本人認証サービスを解説 | ecbeing https://www.ecbeing.net/contents/detail/247 EMV 3-Dセキュアとは | 決済代行のゼウス https://www.cardservice.co.jp/service/creditcard/3d.html クレジットカード決済の安全性を高める「3Dセキュア」とは | 企業のお金とテクノロジーをつなぐメディア「Finance&Robotic」 https://www.robotpayment.co.jp/blog/creditcard/4046/ ■本人認証（3Dセキュア）の認証タイプ 3Dセキュア認証では、本人認証の結果に応じて、決済におけるリスク負担（不正利用時の責任）が異なる。 基本的にはECサイト側で決めるものだが、商材によっては、カード会社より「完全認証」でのサービス提供を求められる。 恐らく、基本的には「通常認証（カード会社リスク負担）」でいいのだと思われる。 ・完全認証 顧客は3Dセキュア認証に成功する必要がある。 クレジットカード自体が3Dセキュアに対応していない場合や、カード保有者が事前にパスワード設定をしていない場合、認証をすることができない。 不正利用があった場合、カード発行会社が損失を負担する。 不正利用時の返金要求も免除される。 商材によっては、カード会社より「完全認証」でのサービス提供を求められる。 ・通常認証（カード会社リスク負担） カード会社側の判断で本人認証が不要とされるので、購入手続きがスムーズに進む。 不正利用があった場合、カード発行会社が損失を負担する。 不正利用時の返金要求も、一定条件下で免除される。 ・通常認証（カード会社、加盟店リスク負担） クレジットカード自体が3Dセキュアに対応していない場合、3Dセキュアの利用契約がされていない場合、処理中にエラーが発生した場合でも加盟店リスク負担で購入手続きを進める。 （ただし、3Dセキュア認証処理が正常に行われ、明確にNGの場合、カード与信は行なわれない。） 不正利用が発生した場合、カード会社と加盟店の双方がリスクを負担する可能性がある。 不正利用時の返金要求も、ECサイト側で対応する必要がある。 顧客にとってはスムーズな決済ができるので、コンバージョン率の向上は期待できる。単価の低い商品なら、これを優先することは考えられる。 本人認証サービス補足資料（3Dセキュア2.0対応版）｜クレジットカード決済代行の株式会社DGフィナンシャルテクノロジー（DGFT,旧：ベリトランス株式会社） https://www.veritrans.co.jp/docs/credit/secure_3d_tips.html ■本人認証（3Dセキュア）の対応義務化 ECサイトのクレジットカード決済において、3Dセキュア認証への対応が義務化される。 2025年3月までに対応が必要とされており、対応できなければ順次警告が来ると思われる。 （前述のとおり3Dセキュア1.0はサポートが終了しているため、3Dセキュア2.0に対応する必要がある。） 本人認証（EMV 3-Dセキュア）導入が義務化？義務化の背景やEC事業者がとるべき対策とは｜決済代行のSBペイメントサービス https://www.sbpayment.jp/support/ec/emv3ds/ すべてのECサイト事業者が対象！EMV 3-Dセキュア(3Dセキュア2.0)が義務化へ。義務化のポイントと注意点を解説｜クレジットカード決済代行の株式会社DGフィナンシャルテクノロジー（DGFT,旧：ベリトランス株式会社） https://www.veritrans.co.jp/tips/column/3d_secure.html ECCubeのプラグインは、3Dセキュア2.0に対応している。 基本的にはプラグインを最新にして設定を行えば対応できるはずだが、独自のカスタマイズを行なっている場合、追加改修が発生する可能性はある。 プラグインをアップデートしたときのメモが「プラグインの導入: プラグインをアップデートしたときの挙動を検証」にある。 VeriTrans4G決済プラグイン(4.0系)|株式会社DGフィナンシャルテクノロジー https://www.ec-cube.net/products/detail.php?product_id=1835 4.2系|VeriTrans4G決済プラグイン(4.2系)|株式会社DGフィナンシャルテクノロジー https://www.ec-cube.net/products/detail.php?product_id=2660 DGFP（旧ベリトランス）の場合、以下に技術的な資料がある。 VeriTrans4G-MDK｜クレジットカード決済代行の株式会社DGフィナンシャルテクノロジー（DGFT,旧：ベリトランス株式会社） https://www.veritrans.co.jp/trial/4g/download/mdk.html VeriTrans4G・3G　無料試用プログラム　新ドメイン対応ガイドのご案内｜クレジットカード決済代行の株式会社DGフィナンシャルテクノロジー（DGFT,旧：ベリトランス株式会社） https://www.veritrans.co.jp/trial/4g/change_connection_guide.html ドキュメントは以下のとおり。（ファイル名の下に書いているのは自分のメモ。） 共通 開発ガイド本体 Ver1.0.8 … 24/03/15 VeriTrans4G_MDK_Development_Guide_108.pdf ・VeriTrans4Gを利用するための専用ソフトウェアである、MDK（Merchant Development Kit）を導入するためのドキュメント。 全体の大枠や他ドキュメントなどを紹介している。 共通 概略システムフロー図 Ver1.0.10 … 24/05/29 VeriTrans4G_Development_Guide_Appendix_flowDiagram_1010.pdf ・システムのフローが紹介されているドキュメント。 どんなタイミングでどんな通信が行われるかの、フローを紹介している。 今回必要なのは、クレジットカード決済に関する部分のみのはず。 共通 検索機能(Search) Ver1.0.7 … 23/09/11 VeriTrans4G_Development_Guide_IF13_Search_107.pdf ・決済情報の検索を行う際の、必要なパラメータなどを紹介している。 クレジットカード決済でもそれ以外でも、共通して使われるみたい。 クレジットカード ＭＤＫトークン Ver1.0.9 … 24/03/15 VeriTrans4G-MDKToken_Development_Guide_109.pdf ・MDKトークンを利用して決済を行うためのドキュメント。 クレジットカード情報を非保持で通信するための、システムを実現するための仕組みを紹介しているみたい。 クレジットカード インターフェース詳細 Ver1.0.13 … 24/05/29 VeriTrans4G_Development_Guide_IF02_Card_1013.pdf ・クレジットカード決済を行う際の、必要なパラメータなどを紹介している。 クレジットカード 3Dセキュア(3DS2.0) Ver1.0.14 … 24/05/29 VeriTrans4G_Development_Guide_ex_3DS2_1014.pdf ・クレジットカード決済と連動する、本人認証サービス（3Dセキュア）を導入するためのドキュメント。 サービスの概要、処理のフロー、必要なパラメータなどを紹介している。 クレジットカード −3DS2.0補足資料 Ver1.0.6 … 23/09/11 Veritrans4G_3DSecure2_Supplement_tips_106.xlsx ・本人認証サービス（3Dセキュア）について、まとめて記載したドキュメント。 クレジットカード −3DS2.0移行ガイド Ver1.0.6 … 22/08/02 VeriTrans-3DSecure2.0_migration_guide_106.xlsx ・本人認証サービス「MPIホスティングサービス」を利用中の加盟店が、3Dセキュア2.0に移行するためのドキュメント。 recoleやunicolleが「MPIホスティングサービス」を利用して稼働しているのかは、すぐには判らなかった。 クレジットカード 不正検知サービス Ver1.3.0 … 21/04/22 VeriTrans4G-FraudDetection_Overview_130.pdf ・VeriTrans4Gの不正検知サービスについて、概要を紹介したドキュメント。 管理画面の取引一覧に不正検知の結果を表示できるが、別途申し込みが必要なサービスとなっている。 ■本人認証（3Dセキュア）を使用 ECCube管理画面「設定 → 店舗設定 → 支払い方法設定 → クレジットカード決済」から設定を行う。 本人認証（3Dセキュア）: 利用しない ↓ 本人認証（3Dセキュア）: 利用する 「登録」ボタンをクリックする。 この状態でクレジット決済すると、直後に以下の画面が表示された。（何のデザインも無い簡素なページだった。） 「OK」をクリックすると「決済結果にリダイレクト中です」と表示され、しばらく待つと注文完了画面が表示された。 恐らくプラグインの設定で「ダミーモード」を「本番モードで稼働」にすればいいとは思うが、テストサイトで有効にして大丈夫かは要確認。 ■ベリトランスのログをダウンロード 「設定 → システム設定 → ベリトランス4G ログダウンロード」 ログをダウンロードできない場合、以下ファイルの「log4php.appender.R1.File」項目で適切なパスが指定されているか確認する。 app/Plugin/VeriTrans4G/Resource/tgMdkPHP/tgMdk/log4php.properties ■本番アカウントでの決済 「オーナーズストア → プラグイン → プラグイン一覧 → ベリトランス4G → 設定（歯車アイコン）」 ベリトランスと契約すると、本番環境用の設定が送られてくるので設定する。 具体的には「マーチャントCCID」「マーチャント認証鍵」「トークンAPI キー」を本番環境用の値に設定する。 「取引IDプレフィックス」は設定すると決済取引IDの先頭に付加されるので、その案件用に判りやすい値にしておくといい。 本番用のマーチャントCCIDなどを設定しても、ダミーモードだとテストカードでの決済になった。（本物のカードだとエラーになった。） これは、テストカードを使ってベリトランスとの疎通確認を行うためのものだと思われる。 ベリトランスの本番アカウントの管理画面には、決済履歴は記録されない。 本番用のマーチャントCCIDなどを設定した状態で、本番モードにすると本物のカードで決済完了できた。 （本番モードにするには同画面で「メール送信に同意する」にチェックを入れる必要があった。） これは実際に運用するためのもの。運用開始前に、このモードにした上で本物のカードで決済を試しておく。 ベリトランスの本番アカウントの管理画面に、決済履歴が記録される。 ■管理画面で受注登録する際のクレジットカード決済 プラグインを導入すると、管理画面で受注登録する際「支払方法」に「クレジットカード決済」が現れる。 ただしこれを選択して受注登録しようとしても。 「クレジットカード決済に必要な情報がありません。他の支払方法を選択してください。」 というエラーになって登録できない。 ユーザのカード情報を入力することは実質不可能なので、ある意味当然の仕様ではある。 ■クレジットカード決済を中断した際の注文日時の記録 注文時に「クレジットカード払い」を選択した場合、正常に注文が進めば以下の遷移が行われる。 /shopping （注文画面） /shopping/confirm （注文確認画面） /shopping/vt4g_payment （クレジット決済画面） /shopping/complete （完了画面） 「/shopping/vt4g_payment」の画面で止まっていた場合、決済処理は完了されない。 購入時にサーバが重いなどの原因で、例えば 1. ご注文内容確認画面に遷移。 2. クレジット決済画面に遷移。 3. クレジット決済ボタンを押下した後、なかなか画面が変わらないので離脱。 という操作をされると、つまり決済が中断されると、直感的でない挙動があった。 具体的には、クレジットカード決済を完了せずに離脱すると。 ・「注文日」が空欄の状態になる。 ・その受注情報を編集すると、最初に編集ボタンを押した日時が「注文日」として記録される。 となる。 これ自体はプラグインの標準の振る舞いではあるが、知らないと「何故こんな注文日なんだ」となるので注意。 本来の注文日を調べたい場合、注文番号をもとに このように検索すれば、以下のような値を得ることができる。 create_dateがデータベースに記録された日時なので、この日時の前後数分を調べることで対象のログを見つけられるはず。 また「ご注文内容のご確認」画面で「注文する」ボタンを押した際に。 の文言がログに出力される。 これをもとに注文処理を開始した厳密な日時を得ることができる。 （初めからこの文言でログを検索するのも有効。） 以下、実際に操作を試した内容。 お客様情報を入力後、ご注文手続き画面へ進んだ時点で、以下の受注情報が作成される。 この受注情報は、受注管理の「購入処理中」に現れる。（絞り込まないと表示されない。） 対応状況: 購入処理中 支払方法: クレジットカード決済 注文日: （空欄） 更新日: （ご注文手続き画面へ進んだ日時） ユーザ側からクレジット決済で注文を行う。 クレジットカード情報入力画面へ進んだ時点で、以下のように受注情報が更新される。 この受注情報は、受注管理の「新規受付」に現れる。（絞り込まなくても表示される。） 対応状況: 新規受付 支払方法: クレジットカード決済 注文日: （空欄） 更新日: （注文した日時） 決済を完了せずに離脱すると、上記のデータがそのまま残る。 この状態で管理画面の受注編集で「保存する」ボタンを押すと、以下のようにその時点の注文日と更新日が記録される。 対応状況: 新規受付 支払方法: クレジットカード決済 注文日: （ボタンを押した日時） 更新日: （ボタンを押した日時） さらにボタンを押すと、以降は注文日はそのままに、更新日が記録される。 例えばこの後すぐにキャンセル処理を行うと、「ユーザ側から注文された数秒後に、管理画面から決済がキャンセルされた」ように見えるデータができてしまう。 実際に上記のデータができてしまったとき、ベリトランス側でのクレジットカード決済の与信は成功となっていた。 （成功するかどうかは、そのときの状況による可能性はある。） 決済が完全に完了されていた場合、該当の注文は「対応状況」を「入金済み」にしておくのが混乱が無いかと思われる。 決済が行われていなかった場合、該当の注文は「対応状況」を「注文取り消し」にするなどし、注文者に「改めて注文作業をしていただきたい」旨を伝えるのがいいかと思われる。 もしベリトランス管理画面に「完了ではないが、おかしなデータが残っている」という場合、ベリトランス側に問い合わせるのがいいと思われる。 ■クレジットカード決済の後に完了画面へ遷移できなかった際の記録 購入時にサーバが重いなどの原因で、例えば 1. ご注文内容確認画面に遷移。 2. クレジット決済画面に遷移。 3. クレジット決済ボタンを押下した後、なかなか画面が変わらないのでブラウザバックを実施。 という操作をされると、 対応状況: 新規受付 支払方法: クレジットカード決済 注文日: （空欄） 更新日: （注文した日時） のままのデータが残ることがある。 このとき、クレジットカード決済の与信は成功となっていた。 操作のタイミングによってはまた異なる結果になるかもしれないが、そのようなことがあったメモとして残しておく。 決済の中断については「クレジットカード決済を中断した際の注文日時の記録」も参照。 ■決済時の警告ログ 決済時のログを確認すると、以下のようになっていた。 その際のECCubeログは以下のとおり。 以下のエラーらしきログがあるのは気になったが、 このエラーメッセージは、ECCube標準でも出力されるらしい。 これ自体は特に問題無さそう。 EC-CUBE 開発コミュニティ - フォーラム https://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=23554&forum=10 ■トラブル: プラグインが動作しない プラグイン一覧で「ベリトランス4G」の設定アイコンが表示されないことがあった。 設定画面に直接アクセスしてもエラーになる。 html/var/log/mdk.log が存在しない場合、以下の手順でファイルを作成してからブラウザを再読込すると表示された。 なお、上記トラブルが発生したのは複数台構成の環境で、rsyncで双方向動機する環境だった。 html/var 内はログファイル置き場なので、同期対象外としていた。 ■トラブル: 特定範囲の日時のみ売上確定できていない ログを確認したところ、7/18の12:53〜13:15において、ECCubeから決済代行会社に対する売上確定の通信処理がエラーとなっていた。 障害情報を調べたところ、下記のとおり、決済代行会社側で決済システムの障害が発生していた（DGFTというのはベリトランスのこと。商号を変更らしい。） 一部のお客様における弊社決済サービスがご利用できない不具合に関するお詫び https://www.dgft.jp/company/info/2021/apology202107.html ECCubeの決済プラグインの仕様では、先の「与信切れへの対応」に書いた対応をするようになっている。 ただし今回はベリトランス側の障害なので、「再オーソリ実行」だけで対応できるかは何とも言えない。 ベリトランスに確認すると、以下の回答があった。 ■トラブル: 特定のクレジットカードが利用できない エラーコード AG39000000000000 が表示され、クレジットカード決済できないという問い合わせがあった。 所持している3種類のカードで試したがどれも駄目だったが、対象カードは他社では使えたとのこと。 調査すると、以下のログが記録されていた。 ・カードA: 7回試行 コード: AG39000000000000 エラーメッセージ: 取引判定保留（有人判定）です。 [G30]（7回ともすべてこのエラー。） ・カードB: 1回試行 コード: AG33000000000000 エラーメッセージ: カード使用不可です。 [G12] ・カードC: 1回試行 コード: AG45000000000000 エラーメッセージ: 1日限度額オーバーです。 [G55] ベリトランスのサイトからダウンロードできる結果コード一覧によると、 それぞれ想定される原因は下記のようになっている。 AG39: 取引判定保留（有人判定） カード会社のモニタリング上電話確認が必要なカードであり、カードがネットでは使用できない状態です。 AG33: カード使用不可 カードが使用できない状態です。限度額オーバーやカード会社のモニタリング上使用できない場合、脱会済カードの場合等の理由が考えられます。 AG45: 1日限度額オーバー 限度額オーバーの為、カードが使用できない状態です。 「取引判定保留（有人判定）」というのは、 カード会社が「本人以外の使用」「立て続けに商品を購入」「急に高額な商品を買った」などといった理由で使用をストップさせているときに表示されるもの。 カードの所有者からカード会社に連絡すると解除されるケースが多い。 ただしカードの所有者に確認すると、今回は「他社ではカードが使えた」とのことだった。 システムとしては同日に決済できている方もいるため、問題は無いと思われる。 「他社では使えた」ということについては、以下のようなことが考えられる。 ・他社で使ったのち、本サイトで使ったため、限度額に達した。 ・本サイトで使ったのち、他社で使用する際は日をまたいだため、限度額に達していなかった。 ・本サイトで使ったのち、他社で使用する際は限度額に達しない金額だった。 ・クレジット決済代行会社によってセキュリティが働くロジックが違う。 ・ネットではなく対面で利用したため。