refirio.org

■概要 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 ■決済の確認 ベリトランス管理画面の取引検索画面で 決済品目: クレジットカード決済 取引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つ削除し、保存ボタンを押下後、再オーソリボタン押下（減額後の金額で再オーソリされる） 前者であっても「オーソリの金額は減額前だが、実際に売上として記録する際は（タイムラグがあるので）減額後の金額が使われるみたい」 ただしどちらにせよ、恐らく「警告が残らないパターン」の手順で対応するのが正しい流れだと思われる ■「本人認証(3Dセキュア)」を使用 クレジットカード決済の安全性を高める「3Dセキュア」とは | 企業のお金とテクノロジーをつなぐメディア「Finance&Robotic」 https://www.robotpayment.co.jp/blog/creditcard/4046/ 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日限度額オーバー 限度額オーバーの為、カードが使用できない状態です。 「取引判定保留（有人判定）」というのは、 カード会社が「本人以外の使用」「立て続けに商品を購入」「急に高額な商品を買った」などといった理由で使用をストップさせているときに表示されるもの カードの所有者からカード会社に連絡すると解除されるケースが多い ただしカードの所有者に確認すると、今回は「他社ではカードが使えた」とのことだった システムとしては同日に決済できている方もいるため、問題は無いと思われる 「他社では使えた」ということについては、以下のようなことが考えられる ・他社で使ったのち、本サイトで使ったため、限度額に達した ・本サイトで使ったのち、他社で使用する際は日をまたいだため、限度額に達していなかった ・本サイトで使ったのち、他社で使用する際は限度額に達しない金額だった ・クレジット決済代行会社によってセキュリティが働くロジックが違う ・ネットではなく対面で利用したため