[EC-CUBE] 4.0.5
[サーバ] OCI
[OS] 　　　　Linux
[PHP] 　　　　7.3.27
[データベース] MySQL 5.7.34
[WEBサーバ] Apache/2.4.25 (Debian)
[導入プラグイン] PGマルチペイメントサービス決済プラグイン 1.0.9、他
[カスタマイズの有無] 有

[現象]

EC-CUBE4・PGマルチペイメントサービス決済プラグインを利用して楽天ペイやキャリア決済を行った際の挙動について
決済処理中ステータスのまま受注情報が残ることで、Eccube上の在庫数が実数以上に減ってしまう状態です。
改善のご助言等いただければ幸いです。

以下事象発生例になります。

[Eccubeフロント]
↓　マスク（在庫:1)を1点カートに入れる
　　支払い方法で楽天ペイを選択し「注文する」ボタンを押して注文を確定する
[楽天ペイ]
↓　楽天ペイ支払い用の外部サイトに遷移する。遷移後、支払いを確定させずそのままブラウザを閉じる
[Eccube管理画面]
↓　当該受注が「決済処理中」ステータスで登録されている
　　マスクの在庫が0に更新される
[GMO管理画面]
↓　当該受注の取引状態が「未決済」→「決済成功」→「決済開始」と以降し、決済開始で止まる
↓
[Eccubeフロント]
　　注文者が再度、マスク1点をカートに入れようとすると在庫が0のため購入に進めない


GMOのサポートセンターに問い合わせたところ、
引用：
を確認できました。


ただ、対象のサイトでは決済処理中のものを見てみると2か月で100件ほどと決して少なくはなく。
在庫数が2～10点程度の商品が大半でまとめて購入されるケースも多々あるので、
購入者が途中で離脱してしまう可能性が高く改善の必要がある状況です。


以下の質問が事象としては同様かなと思うのですが根本的な解決には至らず。
クレジット決済エラー時の在庫数戻しについて。
クーポンプラグイン 決済処理中でもクーポンが利用済みとなるバグについて



[質問]
前置きが長くなりましたが、上記のような事象があった場合

①他サイト事例として何か対策等行われているか伺えたら幸いです。

②2系には、決済処理中ロールバックプラグインがあるようですが３・４系にはなさそうでした。
　３・４系でこの辺りの対応がされていない背景などご存知でしょうか？

③ロールバック対応のカスタマイズを行う場合、決済処理中ステータスへの更新からどの程度の時間経過すればロールバック対象としても問題ないでしょうか。
また、在庫を戻す際にEccube上の処理で懸念点などありますでしょうか。


可能な範囲で、ご教授いただければ幸いです。
どうぞよろしくお願いいたします。