nowarさんは書きました：

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

... snip

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

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

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

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

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

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 でしょうか? モバイルでしょうか?

引用：

引用：

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 を使用するようになっています.

決済モジュールの注文情報確認画面と決済情報入力画面を戻るボタンと次へボタンで行き来すると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に存在しない、決済情報が存在しない

引用：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nowarさんは書きました：

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

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

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