質問 > その他 > 決済処理中受注の在庫ロールバック処理 |
その他
スレッド表示 | 古いものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
tacky14 |
投稿日時: 2021/10/29 19:18
対応状況: −−−
|
半人前 登録日: 2021/4/23 居住地: 投稿: 16 |
Re: 決済処理中受注の在庫ロールバック処理 ご返信いただきありがとうございます。
確かに、別途ステータスを用意して振り分けたうえで処理を行った方が良さそうですね。 リミットは審議の上でバッチ処理で対応進めてみたいと思います。 ありがとうございました! |
h_tanaka |
投稿日時: 2021/10/27 16:52
対応状況: −−−
|
神 登録日: 2016/7/22 居住地: 愛媛県 投稿: 1651 |
Re: 決済処理中受注の在庫ロールバック処理 データベースに保存されているカート情報を日次のバッチ処理で2週間経過している場合に削除するような対応を行ったことがあります。
注文情報の場合は基本的に削除されることを想定していない設計のため、「時間経過による自動削除」のような受注ステータスを用意して変更し、在庫戻し処理を行うのが良いかと思います。 経過時間は店舗の商材や方針によると思います。
|
tacky14 |
投稿日時: 2021/10/27 15:26
対応状況: −−−
|
半人前 登録日: 2021/4/23 居住地: 投稿: 16 |
決済処理中受注の在庫ロールバック処理 [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系には、決済処理中ロールバックプラグインがあるようですが3・4系にはなさそうでした。 3・4系でこの辺りの対応がされていない背景などご存知でしょうか? ③ロールバック対応のカスタマイズを行う場合、決済処理中ステータスへの更新からどの程度の時間経過すればロールバック対象としても問題ないでしょうか。 また、在庫を戻す際にEccube上の処理で懸念点などありますでしょうか。 可能な範囲で、ご教授いただければ幸いです。 どうぞよろしくお願いいたします。 |
スレッド表示 | 古いものから | 前のトピック | 次のトピック | トップ |