3Dセキュア（本人認証）を使ったクレジットカード決済で、決済代行会社の画面では「完了」なのに、EC-CUBEの受注ステータスが「決済処理中」から進まない――この現象は、決済画面から戻ってくるリクエスト（決済結果）をEC-CUBEが受け取り損ねていることがほぼ原因です。カード自体は正常に処理されているため、まずは「二重に課金されていないか」を落ち着いて確認したうえで、原因の切り分けに進みます。
本記事はEC-CUBE 4系（4.2 / 4.3）を主対象に、原因の候補とログの確認手順を具体的に整理します。仕組み自体はバージョン非依存のため、2系・3系でも考え方は共通です。該当する古いバージョン特有の注意点は各項目で補足します。
決済処理中ステータスとは？
EC-CUBEから外部の決済サイトに遷移して決済手続きを行なっている間に設定されるステータスです。購入者から見える「購入処理中」と似ていますが、「決済処理中」は決済会社のプラグインが内部的に使うステータスで、決済結果の戻りを受け取った時点で「新規受付」などへ更新される想定になっています。
決済ページから戻る途中に「redirecting to payment result...」といった文言が一瞬表示されることがありますが、これは決済結果ページへリダイレクトしている最中というだけの表示です。ここで止まったまま進まない、あるいは戻っても「決済処理中」のままの場合は、この後の戻り処理でつまずいていると考えてください。
解決方法は？
決済完了してもEC-CUBE上で注文ステータスが決済処理中から変化しない直接の理由は、決済会社の決済画面からのリクエストの戻り（またはサーバー間の決済通知）を受け取り損なっているためです。
ではなぜ受け取れないのか。原因は一つではありません。代表的なものを、確認すべきログとあわせて列挙します。まずは下の「原因を切り分ける手順」でログの当たりをつけてから、該当しそうな項目を読むと早いです。
SameSiteクッキーの不具合に未対応
ブラウザのクッキー処理の挙動（SameSite属性の既定変更）に伴い、3Dセキュアやリンク型カード決済の完了後に戻ってくる際、外部サイトからのPOSTリクエストでセッションが引き継げず、決済対象の受注を特定できなくなる問題です。結果としてステータスが「決済処理中」のまま止まります。
該当する古いバージョン（EC-CUBE 2系、3.0.17以前、4.0.3以前）では、この問題が残っている可能性があります。以下のホットフィックスの適用、もしくはサポート対象の最新バージョンへの更新で解消します。
SameSite Cookie 対応（EC-CUBE公式ドキュメント）
4.1以降で発生している場合は、EC-CUBE本体よりも決済プラグイン側の戻り処理や、後述のリバースプロキシ・ドメイン設定を先に疑ってください。ログにセッション不整合や受注が見つからない旨のエラーが出ていないかを確認すると判断材料になります。
決済完了通知（バック通知）エラーの不具合
決済の状況に変更があったとき、その変更をサーバー間で通知してくれる機能が多くの決済代行会社に用意されています。この機能は「決済通知」「バック通知」「Webhook」などと呼ばれ、ブラウザの戻りとは別経路でステータスを確定させる保険になっています。
この決済通知が、ECサイト側のWAFにブロックされたり、SSL証明書のエラーや通知先URL（エンドポイント）の設定ミスで受信できていないと、ブラウザ側で戻り損ねた際のリカバリーも効かず、ステータスが更新されません。決済代行会社の管理画面で「通知先URL」「通知の送信ログ・リトライ状況」を確認できる場合が多いので、まずそこを見ると受信できているかの判断が早いです。
受信側では、WAFのアクセスログ、Webサーバー（Apache / Nginx）のアクセスログで、決済代行会社からのIPアクセスが4xx/5xxで弾かれていないかを確認します。到達しているのに処理で失敗している場合は、EC-CUBEのログにエラーが記録されます。
戻ってきたときのURLに何らかの不具合
決済画面から戻ってきた時、プラグイン独自のコールバックURLに遷移することが多いですが、そのURLやルーティングに不具合があると戻り処理が完走しません。よくあるのは、リバースプロキシやロードバランサ配下でHTTP/HTTPSやドメインが食い違い、生成される戻りURLと実際のアクセス先がずれるケースです。
この場合もエラーの多くはEC-CUBEのログに残ります。ログの読み方は下記記事も参考にしてください。
「システムエラーが発生しました」の原因をログから確認する方法
原因を切り分ける手順（確認すべきログと箇所）
「決済処理中から進まない」ときは、どこで戻り処理が止まっているかを特定するのが最短ルートです。次の順に確認すると当たりをつけやすくなります。
- EC-CUBEのログ：4系では
var/log/ディレクトリ配下に日付単位のログが出力されます（環境によりsite_YYYY-MM-DD.logなど）。決済で止まった時刻の前後で、セッション不整合・受注が取得できない・例外（Exception）が出ていないかを確認します。決済プラグインが独自のログを出す場合はその出力先も見ます。 - Webサーバーのアクセスログ：Apacheの
access_log／error_log、Nginxのaccess.log／error.logで、戻りURLや決済通知URLへのアクセスが記録されているか、ステータスコードが200以外になっていないかを見ます。POSTが届いていないなら、そもそも受信していない可能性が高いです。 - WAFのログ：決済代行会社からのアクセスやPOSTがブロックされていないかを確認します。ブロックされている場合は、決済通知の送信元IPや対象URLを除外設定に追加します。
- 決済代行会社の管理画面：その取引が「完了」になっているか、決済通知の送信・リトライ履歴、通知先URLの設定を確認します。カード側は成立しているのにEC-CUBEだけ未更新、という切り分けができます。
ログを見ても該当時刻にアクセス自体が記録されていなければ「受信できていない（通知・戻りが届いていない）」、記録はあるがエラーで終わっていれば「受信後の処理で失敗している」と判断できます。この違いが分かるだけで、SameSite・WAF・URL設定のどれを先に疑うべきかが決まります。
なお、決済処理中のまま実害としてカードが二重に成立していないかは、必ず決済代行会社の管理画面側の取引状況で確認してください。EC-CUBE側のステータスは戻り処理が復旧すれば追いつきますが、課金状態そのものは決済代行会社の記録が正となります。判断に迷う場合は、契約中の決済代行会社サポートへ取引IDを添えて問い合わせるのが確実です。
EC-CUBEゴールドパートナー
EC-CUBEに関するお問い合わせ
[重要]現在公式にセキュリティサポートが切れていないPHPは8.1以上、MySQLは8.0以上で、対応しているEC-CUBEバージョンは4.2以上です。古いEC-CUBEを使っている方は適切なタイミングでバージョンアップをご検討ください。
