ForminatorでStripe決済は通るのに送信履歴が残らない時の対処法
Forminator のフォームに必須の Stripe 決済フィールドを設置したサイトで、カード決済は成功しているのに送信履歴（エントリー）が保存されず、管理者への通知メールも届かない場合は、ページキャッシュとフォーム保存処理の競合をまず疑うべきだ。「AJAX を使用してフォームを読み込む」を有効にし、送信後のリダイレクトを一時的に外して切り分けるのが最短の対処になる。
なぜ Stripe 決済は成功するのにフォーム送信履歴が残らないのか
送信ボタンを押すと、Stripe への決済実行と、WordPress データベースへのエントリー保存という2つの処理がほぼ同時に走る。この2つは経路が完全に独立しているため、片方だけが成功する状態が起こり得る。決済は Stripe の画面で完結するが、送信履歴の保存は WordPress 側のセキュリティトークン（nonce）検証を通らないと書き込まれない。
このデモは、決済が成功してもフォーム保存だけが別経路で失敗する仕組みを示している。保存に失敗する典型的な原因は、ページキャッシュに取り残された古いセキュリティトークンだ。フォームの HTML が静的キャッシュとして配信されると、トークンの有効期限が切れたまま送信され、非同期保存だけが拒否される。
送信後に別の URL へリダイレクトする設定にしている場合は、保存処理が終わる前にページ遷移が始まり、データベースへの書き込みが中断されることがある。3D Secure（本人認証）でカード会社の認証画面を挟む決済では、フォームへ戻ってから保存が再開されるため、この競合が断続的に発生しやすい。
まず「AJAX を使用してフォームを読み込む」を有効にする
Forminator のフォーム編集画面を開き、「動作」タブ（英語環境では Behavior）の「レンダリング」セクションに「AJAX を使用してフォームを読み込む」チェックボックスがある。これが無効のままだと、フォームの HTML がそのままキャッシュされ、トークン劣化の引き金になる。
このオプションを有効にすると、フォーム部分だけが非同期で最新の状態に置き換わる。キャッシュされたページにアクセスしても、フォーム内部のトークンはその都度更新され、送信履歴の保存処理が正しく通る。設定を保存したら、必ずサイトのページキャッシュをクリアしてから動作確認する。
既に有効にしていても症状が出る場合はどこを確認する？
チェックが既に付いていた場合は、AJAX 読み込みだけでは競合を防ぎきれていない。次に、送信後のリダイレクトを一時停止して症状が消えるか確認する。それでも直らない場合は、Stripe 側の本人認証フローとキャッシュの二重がけを順に調べる。
送信後のリダイレクトを一時停止して切り分ける
Forminator の「送信後動作」（英語環境では After Submission Behavior）設定では、複数の動作を追加しても先に登録した1つだけが処理される。インラインメッセージのあとにリダイレクトを設定していた場合は、実質インラインメッセージだけが動いていた状態になる。そこからリダイレクトだけに変えると、保存完了を待たずにページが遷移し、送信履歴が残らなくなることがある。
このデモのように、まずリダイレクト設定を外してインラインメッセージだけにし、数回テスト送信する。これで全ての送信履歴が残れば、リダイレクトが引き金になっていたと判断できる。
リダイレクトを使いたい場合はどうすればいい？
保存処理を追い越さない順序に組み直す必要がある。具体的には、まずインラインメッセージで送信完了を知らせ、その画面からページ遷移する導線にする。これが難しい場合は、当面リダイレクトなしで運用し、症状が出ないことを確認してから設定を戻す。保存処理の完了を待たずに遷移させる構成は、たとえ短い間隔でも断続的な欠損を招く。
3D Secure（本人認証）経由の決済かどうかを確認する
Stripe の 3D Secure（カード会社がワンタイムパスワードやアプリ認証を求める仕組み）が発動する取引では、認証画面や銀行アプリへの切り替えが入る。この認証が終わってフォーム画面に戻るとき、Forminator 側の保存処理が正しく再開されず、決済だけ記録される事例がある。
まず Stripe ダッシュボードの「支払い」から該当の取引を検索し、決済金額と顧客情報が残っているか確認する。決済は残っているのにフォームのエントリーだけ欠損している場合、症状が一致する。続けて、症状が特定のカードブランドや発行会社に偏っていないかを支払い方法別に絞り込む。3D Secure の認証フローが絡む場合は、Forminator と Stripe の API 連携上の問題になるため、プラグインを最新版へ更新した上で、フォームのエクスポートを開発元サポートに渡して再現確認を依頼する。
キャッシュプラグインとフォームページを除外設定にする
サイトでページキャッシュを使っている場合は、フォームを設置しているページをキャッシュ対象外にする。特に決済フォームのある固定ページやランディングページは、静的な HTML 配信をやめて、常に WordPress が生成する最新の画面を返す設定にする。
利用しているキャッシュプラグインの除外設定で、対象ページの URL パスや、フォームの ID を含むクエリを指定する。あわせて、ログイン状態のユーザーにはキャッシュを返さない設定が有効かも確認する。サーバー側のキャッシュ（共用サーバーの高速化機能など）が二重にかかっている場合は、管理画面やホスティングの設定から該当ページのキャッシュを無効化する。これで、AJAX 読み込みを有効にしていても起きる断続的な症状を防げる。
よくある質問
Stripe の決済が通っているのに送信履歴が残らないのはなぜ？
決済と送信履歴の保存は別経路で処理されている。ページキャッシュでフォームのセキュリティトークンが古くなると、決済は Stripe 側で成功しても、WordPress 側のエントリー保存だけが拒否されることがある。送信後のリダイレクトが保存処理を追い越すのも原因の一つだ。
AJAX 読み込みを有効にするとデザインや表示速度に影響はあるか？
フォームの HTML が非同期読み込みに変わるため、ページ表示後すぐにフォームが出ず、一瞬だけ空の枠が出ることがある。見た目はほとんど変わらず、速度も体感できる差はない。キャッシュされたページとの相性は大幅に改善する。
送信履歴が残っていないのに決済は成功している場合、二重請求を防げるか？
顧客が送信を繰り返すと二重決済のリスクがある。該当期間の Stripe ダッシュボードで同一顧客の複数決済を確認し、重複が疑われる場合は返金対応を行う。フォーム側では二重送信防止の設定を確認しておく。
送信履歴が消えた分のデータは復元できるか？
WordPress のデータベースに送信エントリーが書き込まれていないので、Forminator の管理画面上では復元できない。一方、Stripe 側には支払いデータが残っているため、決済情報と顧客メールアドレスを照合して注文内容を再構成することになる。メール通知が届いていない分は、Stripe のレシートが顧客との連絡手段になる。
決済後に送信履歴が残らない確率はなぜ回によって違うのか？
ページキャッシュの状態とトークンの有効期限の関係で、キャッシュが新しければ保存が通り、古ければ失敗する。3D Secure の認証が挟まる場合は、戻り方のタイミングでさらにバラつく。そのため同じフォームでも数回に1回だけ失敗するような断続的な症状になる。
この記事のポイント
- Stripe 決済と送信履歴の保存は別経路で処理される
- まず「AJAX を使用してフォームを読み込む」を有効にしてキャッシュ競合を減らす
- 送信後のリダイレクトを一時停止して保存処理の追い越しを切り分ける
- 3D Secure が絡む決済かどうかを Stripe ダッシュボードで確認する
- フォーム設置ページをキャッシュ対象外にして再発を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce支払いページで重大エラーが出る原因と直し方
WooCommerce の「支払いページ（Pay for Order）」で「このサイトで重大なエラーが発生しました」と表示されたり、決済フォームが読み込まれない場合、原因はほぼプラグインの競合かテーマのテンプレート不整合だ。管理画面からエラーログを確認し、プラグインの全無効化と標準テーマへの切り替えで原因を特定する手順を取れば、数十分で復旧できる。
Pay for Order ページで重大なエラーが出る原因
WooCommerce の Pay for Order（支払い）ページは、注文確認メールやマイアカウントの「注文の支払い」リンクから遷移する専用のチェックアウト画面だ。通常のチェックアウトと異なり、すでに作成済みの注文に対して決済だけを行う設計のため、内部で呼ばれる処理やパラメータが少し異なる。
決済プラグインやカスタムコードがこの固有のフローに対応していない場合、「このサイトで重大なエラーが発生しました」という WordPress の致命エラー画面が表示されたり、決済フォーム部分だけが真っ白になる。特に注文件数が多いサイトほど、Pay for Order の動作不良は直接売上に響くため即時対応が必要だ。
支払いページだけが壊れる仕組み
WooCommerce の内部では、Pay for Order ページの URL に pay_for_order=true と key（注文キー）というパラメータが渡される。通常のチェックアウトとは異なり、カートの中身を参照するのではなく、指定された注文 ID のデータを直接読み込んで決済処理を開始する流れだ。
このとき、決済ゲートウェイプラグインや注文カスタマイズ系プラグインが「カートが空」「注文データが見つからない」といった前提でコードを書いていると、Pay for Order のフローでは関数がエラーを吐き、画面全体が停止する。また、テーマが checkout/payment.php などのテンプレートを上書きしている場合、WooCommerce のバージョン更新に追従できておらず古いテンプレートが原因で決済フォームが欠落することもある。
エラーの詳細を特定する手順
Pay for Order ページでエラーが発生したら、まずエラーログを有効にして原因の PHP エラーを記録させる。WordPress 5.2 以降のサイトヘルス機能や、wp-config.php のデバッグ定数を使えば、エラーメッセージをファイルに出力できる。画面に何も表示されない場合でもログには原因が記録されているケースがほとんどだ。
デバッグログを有効化してエラーを特定する流れ。ログのパスがわからない場合は管理画面の「ツール」→「サイトヘルス」→「情報」タブの「WordPress 定数」セクションで確認できる。
wp-config.php に追加するデバッグ定数
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY を false にすることで、エラーを画面に表示せずログファイルだけに出力する。公開中のサイトでもこの設定なら訪問者にエラーメッセージを見せずに原因を特定できる。debug.log は /wp-content/ ディレクトリに生成される。
ログに記録されているエラーメッセージには、発生元のプラグインディレクトリ名やテーマ名が含まれる。たとえば /wp-content/plugins/woocommerce-gateway-stripe/ のようなパスが出れば、その決済プラグインが Pay for Order に対応できていない可能性が高い。
エラーログから原因を読み解く
Pay for Order ページで頻出するエラーには次のようなパターンがある。PHP の致命的エラー（Fatal error）では「未定義の関数を呼び出した」「null に対してメソッドを実行した」といったメッセージが記録される。特に Call to a member function 〜 on null は、注文オブジェクトの取得に失敗している典型的な兆候だ。
決済ゲートウェイプラグインが WC()->cart や WC()->session に依存している場合、Pay for Order のフローではこれらのオブジェクトが期待通りに動作せずエラーになる。ログにプラグイン名が出たら、まずそのプラグインを開発元のサポートに報告し、Pay for Order 対応の有無を確認するのが確実だ。
プラグイン競合を切り分ける短時間の方法
管理画面にアクセスできるなら、プラグインの一括無効化とテーマ切り替えによる切り分けが最も速い。この作業は公開中のサイトには影響が出るため、メンテナンスモードを有効にするか、低トラフィック時間帯に実施する。
プラグイン競合の切り分けで目指す最終状態。すべての不要プラグインを無効化し標準テーマに切り替えた状態で動作すれば、原因は無効化した中にある。
全プラグインを一括無効化して一つずつ再有効化する
WooCommerce 本体と、その動作に必須な決済プラグインを除くすべてのプラグインを一度無効化する。特に注意すべきは、キャッシュ系プラグイン、セキュリティプラグイン、そして注文カスタマイズ系のプラグインだ。Pay for Order の URL パラメータをキャッシュやリダイレクトルールが干渉して弾いているケースも多い。
無効化後に Pay for Order ページが正常に表示されれば、原因は無効化したいずれかのプラグインにある。次に、WooCommerce と決済プラグイン以外のプラグインを一つずつ再有効化し、その都度 Pay for Order ページを再読み込みしてエラーの再発を確認する。エラーが再発した時点で直前に有効化したプラグインが原因だ。
標準テーマに切り替えてテーマ由来の不具合を除外する
プラグインをすべて無効化しても直らない場合、使用中のテーマが WooCommerce のテンプレートを上書きしている可能性が高い。管理画面の「外観」→「テーマ」から Twenty Twenty-Five などの標準テーマに一時的に切り替え、再度 Pay for Order ページを表示する。標準テーマで問題なく動作するなら、元のテーマ側のテンプレートファイルが原因だ。
切り分け時に注意すべきキャッシュの削除
WooCommerce のチェックアウト周りはキャッシュの影響を強く受ける。プラグインを無効化しても、サーバーキャッシュや CDN キャッシュが残っていると古いエラー画面が表示され続けることがある。管理画面の「WooCommerce」→「ステータス」→「ツール」タブから「WooCommerce の一時データをクリア」「商品の参照カテゴリをカウントする」を実行し、さらに利用中のキャッシュプラグインのキャッシュも全削除してからテストする。
テーマと WooCommerce テンプレートのバージョン不整合を解消する
テーマが WooCommerce のテンプレートファイルを子テーマや独自ディレクトリで上書きしている場合、WooCommerce 本体がバージョンアップするとテンプレートの構造や関数が変更され、古いテンプレートでは Pay for Order の処理に失敗する。特に checkout/form-pay.php や checkout/payment.php は Pay for Order ページで直接使われるファイルのため、上書きされていると影響が大きい。
上書きテンプレートの状態を確認する
管理画面の「WooCommerce」→「ステータス」画面を開き、「テンプレート」セクションを表示する。ここに「上書きあり」と表示されているテンプレートの一覧がある。checkout/form-pay.php が上書きされていて、かつ WooCommerce 本体のバージョンより古いテンプレートバージョンが記載されている場合、このファイルを最新の WooCommerce テンプレートと比較して更新する必要がある。
テンプレートを安全に更新する手順
まず WooCommerce プラグインディレクトリの templates/checkout/form-pay.php を最新の状態で確認し、現在テーマ側で上書きしている同名ファイルと差分を比較する。差分が少ない場合はテーマ側のファイルを最新に置き換え、カスタマイズがある部分だけ必要な修正を手動で適用する。差分が多い場合は、WooCommerce のアクションフックを使ってテンプレート上書きを避ける設計に移行するのが長期的に安全だ。
よくある質問
Pay for Order ページだけがエラーになるのはなぜか
通常のチェックアウトと Pay for Order では WooCommerce 内部のフローが異なり、カートセッションの状態や注文オブジェクトの取得方法が変わる。多くの決済プラグインは通常のチェックアウトだけを想定して開発されているため、Pay for Order の特殊なパラメータを受け取った際に未定義エラーや null 参照が発生する。
管理画面にもアクセスできなくなった場合はどうすればよいか
FTP またはサーバーのファイルマネージャーで /wp-content/plugins/ ディレクトリにアクセスし、エラーの原因と思われるプラグインのディレクトリ名を変更する（例 plugin-name → plugin-name-disabled）。これで強制的にプラグインを無効化できる。復旧後に管理画面から原因の特定を進める。
WooCommerce のステータスページで推奨される PHP 設定はあるか
WooCommerce の推奨 PHP メモリ制限は 256MB 以上、実行時間の上限は 300 秒以上だ。「WooCommerce」→「ステータス」画面の「サーバー環境」セクションで現在値を確認し、不足している場合はレンタルサーバーの管理画面や php.ini から引き上げる。メモリ不足が原因で Pay for Order の処理中にプロセスが停止することもある。
特定の決済プラグインだけが Pay for Order で動かない場合の対処は
まずその決済プラグインの公式サポートに「Pay for Order ページでエラーが発生する」と明記して問い合わせる。急を要する場合は、WooCommerce 標準の銀行振込や代金引換などの決済手段を一時的に有効化して Pay for Order での支払いを受け付けつつ、該当プラグインの修正を待つ運用で売上を止めないようにする。
エラーログに何も記録されない場合はどうすればよいか
JavaScript のエラーが原因で画面が動作しないケースが考えられる。ブラウザの開発者ツール（F12 キー）の「コンソール」タブを開き、Pay for Order ページを読み込んだ際の赤いエラー表示を確認する。jQuery の競合や決済フォームのスクリプト読み込み失敗が主な原因で、PHP ログには記録されない。
この記事のポイント
- Pay for Order ページのエラーは主にプラグイン競合かテーマのテンプレート不整合が原因
- wp-config.php のデバッグ定数でエラーログを取得し原因プラグインを特定する
- 全プラグイン無効化と標準テーマへの切り替えで短時間に原因を切り分ける
- テーマの WooCommerce テンプレート上書きはステータス画面でバージョン確認し最新化する
- JavaScript エラーの場合はブラウザの開発者ツールで別途確認が必要
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている