バージョン選択

フォーラム

メニュー

オンライン状況

40 人のユーザが現在オンラインです。 (20 人のユーザが フォーラム を参照しています。)
登録ユーザ: 0
ゲスト: 40
もっと...

サイト内検索

バグ報告 > その他 > EC-CUBEペイメント決済モジュールの不具合

その他

新規スレッドを追加する

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
nowar
投稿日時: 2010/2/17 21:37
対応状況: −−−
新米
登録日: 2010/2/17
居住地:
投稿: 5
EC-CUBEペイメント決済モジュールの不具合
先日よりEC-CUBEペイメント決済モジュールを使用しておりますが、
クレジット決済・コンビニ決済利用時にGMOの管理画面には決済情報が登録されているが、
肝心の受注情報がEC-CUBEのDBに書き込まれていないという事象が発生しており大変困っております。
(GMOの管理画面で確認できるorder_id自体がEC-CUBEのDB上に存在しません。)

正常に書き込まれることのほうが多いですが、
200件中20件程度の受注情報の確認できない決済情報があり無視できない事態となっております。

今回の件と関係があるかどうかは分かりませんが、
原因を探るために決済モジュールにおける決済処理→受注情報の書き込みのフローを確認しましたところ
downloads/mdl_pg_mulpay/class/pages/LC_Page_Mdl_PG_MULPAY.phpにて決済処理を行ってから完了画面にリダイレクトさせ、完了画面でDBに受注情報を書き込んでいるという状況でした。

この仕様ですと何らかの原因で完了画面に遷移できなかった場合、
決済自体は終わるが受注情報がDBに書き込まれないという事も大いにありえると思います。
以下はぱっと思いつく範囲での遷移できない可能性です。
・決済モジュールで決済後にPHPのエラーが発生した場合
・ユーザの回線が切断、タイムアウト等の理由で完了画面に遷移できなかった場合
・サーバダウン、サーバ側の回線切断

本来ならば同一処理中でトランザクションを利用し受注情報をDBに登録してから決済処理を行い、
決済がNGだった場合にロールバックさせる(もしくは該当の受注情報をDBから削除)という処理が正しいのではないでしょうか?

尚、商品購入時に関係しそうなこちらで施したカスタマイズ内容は下記の通りです。
1, shopping/complete.php中の処理でメールを出す箇所を追加
2, モジュール内の配送指定日のswitch文の内容を変更

こちらで調査しましたところ
1に関しましては受注情報をDBに書き込んだ後の処理なので特に関係はなさそうです。
(GMOの方にもログを確認して頂き特に問題となるようなエラーは発生していないことを確認しております。)
2に関しましてはファイルは違いますが、代引きのほうでも同一の処理が問題なく動作しております。
またPHPのエラーログも確認しましたが特にエラーは発生しておりませんでした。

もし同じような現象に遭遇し解決できた方いらっしゃいましたら、
助言をお願いできませんでしょうか。
GMOの方も原因が分からないとの事で困っております。

サーバ上のミドルウェア、アプリケーションのバージョンはそれぞれ以下の通りになります。

EC-CUBE 正式版 2.4.1
EC-CUBEペイメント決済モジュール 1.3.0
 クレジット決済(2clickを含む)
 コンビニ決済

PHP 5.2.12
PostgreSQL 8.4.2


また本件と関係あるかどうかは現時点では分かりませんが、
EC-CUBEペイメント決済モジュールのクレジット決済、コンビニ決済使用時にdtb_orderテーブル内のorder_idが飛び飛びになる事もあります。
現在は決済方法を代引きのみにして対応しておりますが、
代引きのみに変更してからは今のところorder_idが飛ぶことはないようです。
nanasess
投稿日時: 2010/2/17 23:51
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2202
Re: EC-CUBEペイメント決済モジュールの不具合
引用:

nowarさんは書きました:

(GMOの管理画面で確認できるorder_id自体がEC-CUBEのDB上に存在しません。)


該当の order_id は欠番になっているということでしょうか?
dtb_order_temp に情報は残っていますでしょうか?

引用:

本来ならば同一処理中でトランザクションを利用し受注情報をDBに登録してから決済処理を行い、
決済がNGだった場合にロールバックさせる(もしくは該当の受注情報をDBから削除)という処理が正しいのではないでしょうか?


EC-CUBE の決済モジュールの仕様は, shopping/complete.php の前で呼ばれる shopping/load_payment_module.php の中で処理を完結する必要があります.
上記の処理を行うためには, 決済モジュールの仕様上困難だと思われますので, 独自にカスタマイズした方が良いかもしれません.

引用:

また本件と関係あるかどうかは現時点では分かりませんが、
EC-CUBEペイメント決済モジュールのクレジット決済、コンビニ決済使用時にdtb_orderテーブル内のorder_idが飛び飛びになる事もあります。
現在は決済方法を代引きのみにして対応しておりますが、
代引きのみに変更してからは今のところorder_idが飛ぶことはないようです。


関係あるような感じはします.
詳細なログを出力するように, GC_Utils::gfPrintLog() などをたくさん仕込んで, order_id が欠番になった場合, どのような状態だったかを追跡すると良いと思います.
特に, shopping/complete.php へ遷移したかどうかや, dtb_order テーブルの UPDATE が abort してないかなどをチェックすると良いと思います.
tao_s
投稿日時: 2010/2/18 3:00
対応状況: −−−
仙人
登録日: 2008/8/20
居住地: 東京
投稿: 794
Re: EC-CUBEペイメント決済モジュールの不具合
EC-CUBEの他の決済モジュールでもそうですが、おっしゃる通り仕様バグ?みたいな物があったと思います。

本来であれば、料金計算→受注一時テーブルに書き込み→オーソリ→受注テーブルに書き込み→仮売上→コミットorロールバック
となると思います。

オーダーIDが飛び飛びになるのは、新規のオーダーIDの取得方法が、
DBから最後のオーダーID取得→PHPで+1して新しいオーダーID作成→DBに最後のオーダーIDとして書き込み
となっている為だと思います。で、この際に確かテーブルのレコードの値を見ていなかったと思います。

あと、GMO-PGさんの仕様だったと思うんですが、決済リクエストを投げる度にオーダーIDを変えないといけなかった気がします。
以前独自にGMO-PGさんの決済モジュールを作成した際は、その為にオーダーIDを振り直す処理を入れた気がします。


----------------
EC-CUBEカスタマイズ相談してください。
緊急のEC-CUBEの障害対応
EC-CUBEカスタマイズブログ

nowar
投稿日時: 2010/2/18 10:55
対応状況: −−−
新米
登録日: 2010/2/17
居住地:
投稿: 5
Re: EC-CUBEペイメント決済モジュールの不具合
nanasess様
返信ありがとうございます。

引用:

該当の order_id は欠番になっているということでしょうか?
dtb_order_temp に情報は残っていますでしょうか?


欠番になっています。
受注情報が残っていないorder_idに関しましてはdtb_order_tempに残っているパターンもあれば全く残っていないパターンもあります。
決済モジュールの注文情報確認画面と決済情報入力画面を戻るボタンと次へボタンで行き来するとorder_idがどんどん進んでいく現象も確認しており、決済情報にすら残っていないパターンはこれで進んでしまった物かもしれません。

dtb_order_tempの動きを把握してないので何とも言えませんが、
order_idの欠番、決済情報はあるが受注情報が存在しない物のパターンは以下の通りになっております。(それぞれorder_idをキーにした場合です)
1, dtb_order_tempに存在しない、dtb_orderに存在しない、決済情報が存在する
2, dtb_order_tempに存在する、dtb_orderに存在しない、決済情報が存在する
3, dtb_order_tempに存在しない、dtb_orderに存在しない、決済情報が存在しない

3が先述の確認画面と決済情報入力画面を行き来した場合のorder_id欠番パターンかと思います。


引用:

EC-CUBE の決済モジュールの仕様は, shopping/complete.php の前で呼ばれる shopping/load_payment_module.php の中で処理を完結する必要があります.
上記の処理を行うためには, 決済モジュールの仕様上困難だと思われますので, 独自にカスタマイズした方が良いかもしれません.

shopping/complete.phpをそのまま使用するためにこのようなフローになっているのかなとは思うのですが、
何かこのファイルを使用しなければいけない制約や背景などがあるのでしょうか?

カスタマイズするとしたらshopping/complete.php以外に何もしない完了画面を用意して決済モジュールの処理を変更、
新しく作成した完了画面にリダイレクトが一番の近道かなと思っております。

引用:

関係あるような感じはします.
詳細なログを出力するように, GC_Utils::gfPrintLog() などをたくさん仕込んで, order_id が欠番になった場合, どのような状態だったかを追跡すると良いと思います.
特に, shopping/complete.php へ遷移したかどうかや, dtb_order テーブルの UPDATE が abort してないかなどをチェックすると良いと思います.

本番環境は既に稼動中でして直ぐに対応するのは難しいので、
まずはステージング環境にてGC_Utils::gfPrintLog() を仕込んでもう少しテストしてみます。
こちらのテストで再現できればいいのですが・・・。
ATIRA
投稿日時: 2010/2/18 19:53
対応状況: −−−
新米
登録日: 2010/2/18
居住地:
投稿: 2
Re: EC-CUBEペイメント決済モジュールの不具合
nowar さんと似た環境ですが、うちでもおそらく同じと思われる症状が発生しています。

同様に稀にGMOから
「PGマルチペイメントサービス決済モジュール 不一致データ検出」
という件名でエラーメールが送信されてきます。
内容にあるオーダーIDは実際に受注情報にはないオーダーIDでした。

自分でやった場合の再現性がなく、うちの固有の問題と思いしばらく様子を見ていましたが、
他にも似たような症状の方がいたようなので、報告まで。


EC-CUBE 正式版 2.4.1
EC-CUBEペイメント決済モジュール 1.3
 クレジット決済
 コンビニ決済

PHP 5.1.6
PostgreSQL 8.4.1
nowar
投稿日時: 2010/2/18 23:16
対応状況: −−−
新米
登録日: 2010/2/17
居住地:
投稿: 5
Re: EC-CUBEペイメント決済モジュールの不具合
tao_s様
返信ありがとうございます。

引用:

EC-CUBEの他の決済モジュールでもそうですが、おっしゃる通り仕様バグ?みたいな物があったと思います。

本来であれば、料金計算→受注一時テーブルに書き込み→オーソリ→受注テーブルに書き込み→仮売上→コミットorロールバック
となると思います。

やはりそうですよね。
仕様の部分も先方に突っ込んでみたのですが報告件数が少ないようで
企業の体質なのかGMOが動いてくれる様子はなさそうなので、
GMO-PGの仕様を確認しながら自分でモジュールを作り直すしかないのかもしれません。
何のために決済モジュールを用意してるんだか・・・。

引用:

オーダーIDが飛び飛びになるのは、新規のオーダーIDの取得方法が、
DBから最後のオーダーID取得→PHPで+1して新しいオーダーID作成→DBに最後のオーダーIDとして書き込み
となっている為だと思います。で、この際に確かテーブルのレコードの値を見ていなかったと思います。

あと、GMO-PGさんの仕様だったと思うんですが、決済リクエストを投げる度にオーダーIDを変えないといけなかった気がします。
以前独自にGMO-PGさんの決済モジュールを作成した際は、その為にオーダーIDを振り直す処理を入れた気がします。

処理ではなく結果のみしか確認しておりませんが決済情報入力画面から確認画面に戻る度に振り直しされてるみたいです。
(決済NGでの差し戻しではなく、単純に戻るボタンでの遷移で)
確認画面でorder_idの取得(若しくは再取得)を行い、dtb_order_tempのorder_idを書き換えているといったところでしょうか。

ちょっと話は違いますが代引きの場合は決済方法選択画面(shopping/payment.php)と確認画面(shopping/confirm.php)を行き来してもorder_idが振り直される事はないようです。
nowar
投稿日時: 2010/2/18 23:32
対応状況: −−−
新米
登録日: 2010/2/17
居住地:
投稿: 5
Re: EC-CUBEペイメント決済モジュールの不具合
ATIRA様
返信ありがとうございます。

引用:

同様に稀にGMOから
「PGマルチペイメントサービス決済モジュール 不一致データ検出」
という件名でエラーメールが送信されてきます。
内容にあるオーダーIDは実際に受注情報にはないオーダーIDでした。

まさにこれで当方も気付きました!
GMO-PG管理画面でメール通知するように設定されてないショップさんは気付いてないかもしれませんね・・・この件。

引用:

自分でやった場合の再現性がなく、うちの固有の問題と思いしばらく様子を見ていましたが、
他にも似たような症状の方がいたようなので、報告まで。

固有の問題ではなさそうなのでまずは一安心です。
こちらの環境では決済モジュールを利用した注文のうち10%程がこのような状況になってますので、正直このまま使うのはかなり怖いです。
nanasess
投稿日時: 2010/2/19 11:32
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2202
Re: EC-CUBEペイメント決済モジュールの不具合
引用:

決済モジュールの注文情報確認画面と決済情報入力画面を戻るボタンと次へボタンで行き来するとorder_idがどんどん進んでいく現象も確認しており、決済情報にすら残っていないパターンはこれで進んでしまった物かもしれません。


これは明らかに良くない動きをしていますね...(苦笑)

引用:

dtb_order_tempの動きを把握してないので何とも言えませんが、
order_idの欠番、決済情報はあるが受注情報が存在しない物のパターンは以下の通りになっております。(それぞれorder_idをキーにした場合です)
1, dtb_order_tempに存在しない、dtb_orderに存在しない、決済情報が存在する
2, dtb_order_tempに存在する、dtb_orderに存在しない、決済情報が存在する
3, dtb_order_tempに存在しない、dtb_orderに存在しない、決済情報が存在しない


1 のパターンは明らかにおかしいですね. 購入確認画面で dtb_order_temp に必ず行が追加されるはずです.
2 は, shopping/complete.php へ遷移しなかった可能性が考えられますね.

このあたりのクライアントの動きがわかれば, 原因が把めるかもしれません.
ちなみに, 現象が発生しているのは PC でしょうか? モバイルでしょうか?


引用:

引用:

EC-CUBE の決済モジュールの仕様は, shopping/complete.php の前で呼ばれる shopping/load_payment_module.php の中で処理を完結する必要があります.
上記の処理を行うためには, 決済モジュールの仕様上困難だと思われますので, 独自にカスタマイズした方が良いかもしれません.

shopping/complete.phpをそのまま使用するためにこのようなフローになっているのかなとは思うのですが、
何かこのファイルを使用しなければいけない制約や背景などがあるのでしょうか?

カスタマイズするとしたらshopping/complete.php以外に何もしない完了画面を用意して決済モジュールの処理を変更、
新しく作成した完了画面にリダイレクトが一番の近道かなと思っております。


一部の決済モジュールでは, 独自に購入完了画面を用意しています.
特に制約があるわけではないですが, 独自に購入管理画面を定義すると,

引用:

1, shopping/complete.php中の処理でメールを出す箇所を追加


というような独自のカスタマイズと干渉する可能性もあり, 基本は EC-CUBE デフォルトの shopping/complete.php を使用するようになっています.

引用:

本番環境は既に稼動中でして直ぐに対応するのは難しいので、
まずはステージング環境にてGC_Utils::gfPrintLog() を仕込んでもう少しテストしてみます。
こちらのテストで再現できればいいのですが・・・。


postgresql.conf なども設定して, PostgreSQL の出力する SQL ログも取っておくと良いと思います.
何か解りましたら情報お願いします!
nowar
投稿日時: 2010/2/19 19:09
対応状況: −−−
新米
登録日: 2010/2/17
居住地:
投稿: 5
Re: EC-CUBEペイメント決済モジュールの不具合
nanasess様
少々進展がありましたのでご報告致します。

引用:

nanasessさんは書きました:
引用:

決済モジュールの注文情報確認画面と決済情報入力画面を戻るボタンと次へボタンで行き来するとorder_idがどんどん進んでいく現象も確認しており、決済情報にすら残っていないパターンはこれで進んでしまった物かもしれません。


これは明らかに良くない動きをしていますね...(苦笑)

再現性があるので仕様でないのでしたらバグの一つであるのは間違いないと思います。

引用:

引用:

dtb_order_tempの動きを把握してないので何とも言えませんが、
order_idの欠番、決済情報はあるが受注情報が存在しない物のパターンは以下の通りになっております。(それぞれorder_idをキーにした場合です)
1, dtb_order_tempに存在しない、dtb_orderに存在しない、決済情報が存在する
2, dtb_order_tempに存在する、dtb_orderに存在しない、決済情報が存在する
3, dtb_order_tempに存在しない、dtb_orderに存在しない、決済情報が存在しない


1 のパターンは明らかにおかしいですね. 購入確認画面で dtb_order_temp に必ず行が追加されるはずです.
2 は, shopping/complete.php へ遷移しなかった可能性が考えられますね.

このあたりのクライアントの動きがわかれば, 原因が把めるかもしれません.
ちなみに, 現象が発生しているのは PC でしょうか? モバイルでしょうか?

1のパターンですがコンビニ決済で再現できました。
確認画面の次のコンビニ選択画面の次へを押したと同時にリロードすると遷移はしないのですが、
更に次へを押すと下記エラーが出力されます。
エラーが発生しました:M01-M01004014,M01-M01004010

そのまま再度次へを押すと正常に注文できますが、
この場合order_idの欠番が1つ発生しており、その欠番は決済情報は存在するがdtb_order,dtb_order_tempの双方にデータが存在しないという結果になりました。
(正常に注文出来た物は記録されています。)

尚、これに関しましては何度も試しましたが再現性があるようです。
クレジット決済のほうはまだ試しておりませんが、同様のエラーが出そうな気はします。

再現する方法がこれだけであればコンビニ決済には影響はなさそうですが、
クレジット決済でAUTH、CHECKではなく実売上にしていた場合はかなり不味そうです。
運用中のECサイトは幸い仮売上でしたが。

引用:

引用:

引用:

EC-CUBE の決済モジュールの仕様は, shopping/complete.php の前で呼ばれる shopping/load_payment_module.php の中で処理を完結する必要があります.
上記の処理を行うためには, 決済モジュールの仕様上困難だと思われますので, 独自にカスタマイズした方が良いかもしれません.

shopping/complete.phpをそのまま使用するためにこのようなフローになっているのかなとは思うのですが、
何かこのファイルを使用しなければいけない制約や背景などがあるのでしょうか?

カスタマイズするとしたらshopping/complete.php以外に何もしない完了画面を用意して決済モジュールの処理を変更、
新しく作成した完了画面にリダイレクトが一番の近道かなと思っております。


一部の決済モジュールでは, 独自に購入完了画面を用意しています.
特に制約があるわけではないですが, 独自に購入管理画面を定義すると,

引用:

1, shopping/complete.php中の処理でメールを出す箇所を追加


というような独自のカスタマイズと干渉する可能性もあり, 基本は EC-CUBE デフォルトの shopping/complete.php を使用するようになっています.

なるほど、確かにそれはそうですね。
ただカスタマイズしていた場合はどんな形であれ結局モジュールのほうも確認しなければいけないので差ほど影響はでないかも・・・。
「手間がかかるがバグはない」というのと「汎用性はあるがバグもある」、これらを天秤にかけた場合やはり「手間はかかるがバグはない」のほうを選んでしまいます。
開発フェーズよりも運用フェーズのほうがずっと長いですから開発時点での多少の手間には目を瞑れる気はします。
nanasess
投稿日時: 2010/2/22 9:49
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2202
Re: EC-CUBEペイメント決済モジュールの不具合
引用:

nowarさんは書きました:

再現性があるので仕様でないのでしたらバグの一つであるのは間違いないと思います。

... snip

1のパターンですがコンビニ決済で再現できました。
確認画面の次のコンビニ選択画面の次へを押したと同時にリロードすると遷移はしないのですが、
更に次へを押すと下記エラーが出力されます。
エラーが発生しました:M01-M01004014,M01-M01004010

そのまま再度次へを押すと正常に注文できますが、
この場合order_idの欠番が1つ発生しており、その欠番は決済情報は存在するがdtb_order,dtb_order_tempの双方にデータが存在しないという結果になりました。
(正常に注文出来た物は記録されています。)

尚、これに関しましては何度も試しましたが再現性があるようです。
クレジット決済のほうはまだ試しておりませんが、同様のエラーが出そうな気はします。

再現する方法がこれだけであればコンビニ決済には影響はなさそうですが、
クレジット決済でAUTH、CHECKではなく実売上にしていた場合はかなり不味そうです。
運用中のECサイトは幸い仮売上でしたが。


ありがとうございます.
再現性があるということで, GMO-PG さんへご報告頂ければ幸いです.

# もし, 修正されないようであれば, こちらでもパッチの作成など試みてみます.

引用:

ただカスタマイズしていた場合はどんな形であれ結局モジュールのほうも確認しなければいけないので差ほど影響はでないかも・・・。
「手間がかかるがバグはない」というのと「汎用性はあるがバグもある」、これらを天秤にかけた場合やはり「手間はかかるがバグはない」のほうを選んでしまいます。
開発フェーズよりも運用フェーズのほうがずっと長いですから開発時点での多少の手間には目を瞑れる気はします。


すべての制作会社さんが, こういったテストや不具合修正ができる技術があれば問題ないのですが, 残念ながら, できない場合がほとんどです.

EC-CUBE の実装の悪さもあるので, 今後のバージョンでは是非とも改善していきたいと思っています.
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ


 



ログイン



統計情報

総メンバー数は74,789名です
総投稿数は104,242件です

投稿数ランキング

1
seasoft
7333
2
468
3217
3
AMUAMU
2712
4
nanasess
2202
5
umebius
2085
6
yuh
1664
7
red
1525
8
h_tanaka
1189
9
tsuji
942
10
fukap
907
11
shutta
835
12
tao_s
794
13 ramrun 789
14 karin 689
15 sumida 641
16
homan
633
17 DELIGHT 572
18
patapata
502
19
flealog
485
20 tonton 437


ネットショップの壺

EC-CUBEインテグレートパートナー

Copyright© EC-CUBE CO.,LTD. All Rights Reserved.