先日より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が飛ぶことはないようです。