タグアーカイブ 決済エラー

WooCommerce PayPal決済が断続的に失敗する原因と直し方

WooCommerce PayPal決済が断続的に失敗する原因と直し方

WooCommerce PayPal Payments プラグインで決済が断続的に失敗し OrderProcessor.php のエラーが発生する場合、注文 ID のセッション保存が決済リダイレクトと競合しているか、PayPal ウェブフックの署名検証に失敗している可能性が高い。原因をログから特定し、設定と更新状況を見直せば、決済の取りこぼしを止められる。

なぜ PayPal 決済やカード決済が断続的に失敗するのか

なぜ PayPal 決済やカード決済が断続的に失敗するのか

断続的に発生する決済失敗は、一定の条件が重なった時だけ起こる「競合状態」が原因になっていることが多い。WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal にリダイレクトされる直前に注文 ID をセッションへ保存する処理と、PayPal 側の承認完了後の戻り処理がうまく噛み合わず、注文 ID を見失うケースが報告されている。

また PayPal から届く CHECKOUT.ORDER.APPROVED ウェブフックの署名検証に失敗すると、ブラウザ経由の戻りが完了しなかった注文を復旧できず、売上が失われる。キャッシュや最適化を完全に停止しても再発するケースは、プラグイン内部のタイミング問題である可能性が極めて高い。

エラーログから失敗のパターンを特定する

エラーログから失敗のパターンを特定する

WooCommerce PayPal Payments の詳細ログを有効にする

管理画面の「WooCommerce」から「設定」へ進み「決済」タブを開く。PayPal の項目にある「接続を管理」画面の下部に「ログ」というチェックボックスがあるので、これを有効にして保存する。有効化後は決済のたびにログが蓄積され始めるので、エラーが出たタイミングを正確に追える。

ログに記録されるエラーメッセージを読み解く

失敗時のログには「Payment failed: There was an error processing your order. OrderProcessor.php:109」と出力される。ただしこのメッセージだけでは表面的な情報に過ぎない。同じ時刻付近に PayPal API への注文作成リクエストや capture 呼び出しが記録されているかを確認することが重要だ。

もしログに PayPal 側の注文作成すら残っていないなら、プラグインが PayPal へ処理を引き継ぐ前の段階でコケている。逆に注文作成は成功しているのに capture 呼び出しが見つからないなら、戻り処理かウェブフックの不具合を疑う。

STEP 1 WooCommerce 設定で PayPal の詳細ログを有効にする
STEP 2 失敗時刻の前後で PayPal API 呼び出しの有無を調べる
STEP 3 注文作成ログがない場合はセッションと注文 ID の欠落を疑う

上の手順で失敗パターンを大まかに分類できる。注文作成ログが欠けているパターンは後述の注文 ID 消失問題と合致する。

ウェブフック検証失敗の原因と直し方

ウェブフック検証失敗の原因と直し方

ウェブフックが届いているのに検証に失敗する仕組み

PayPal から WordPress サイトの REST エンドポイント(/wp-json/paypal/v1/incoming)に届いたウェブフックは、プラグインが PayPal の公開鍵を使って署名を検証する。この検証が通らないと、たとえ CHECKOUT.ORDER.APPROVED イベントを受け取っていても支払いを完了できず、注文は保留のままになる。

署名検証が失敗する典型的な原因

まず疑うのはサーバー時刻のずれだ。署名にはタイムスタンプが含まれており、サーバーの時刻が大きく狂っていると検証に失敗する。次に考えられるのがプラグイン内部で保持している PayPal 公開鍵のキャッシュ不整合だ。接続情報を更新した直後や、マルチサイト構成でドメインが一致していない場合にも起こりうる。

ウェブフック検証を復旧させる具体的な対処

最初に PayPal との接続を一度解除し、再度接続し直す。これで公開鍵のキャッシュが強制的に再取得される。それでも直らない場合は WooCommerce の「ステータス」画面から「ツール」タブを開き、「WooCommerce のトランジェントをクリア」と「期限切れのトランジェントをクリア」を順に実行する。最後に PayPal のデベロッパーダッシュボードでウェブフック URL が本番環境の正しいドメインを指しているか確認する。

Before(検証失敗時)
ウェブフック受信 → 署名照合エラー → 注文が未完了のまま放置
After(再接続後)
ウェブフック受信 → 署名照合成功 → 注文が正常に完了
検証失敗  再接続で復旧

上の流れで復旧しない場合はプラグインバージョン固有の不具合が根底にある可能性が高い。

注文 ID がセッションから消える問題に対処する

注文 ID がセッションから消える問題に対処する

リダイレクト前に注文 ID が保存されない既知の不具合

GitHub の issue #4458 でも報告されているが、WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal へリダイレクトされる直前に注文 ID を正しくセッションへ格納できないケースがある。これが発生すると、PayPal 上で決済が承認されても、戻ってきた WooCommerce 側でどの注文に紐づければよいかわからず、OrderProcessor がエラーを起こす。

修正パッチやバージョンアップで解決できるか

バージョン 4.1.0 ではこのタイミング問題に対する修正が含まれていると開発者からアナウンスされている。まずはプラグインを 4.1.0 以降へ更新することが最も確実な対処となる。どうしても本番環境で即時の更新が難しい場合は、プラグインの公式サポートチャネルを通じて修正パッチの提供を依頼する手もある。

更新前に検証するべき設定

更新前に WooCommerce の「システムステータス」レポートを取得し、PHP のバージョンが 8.0 以上であること、WordPress 本体と WooCommerce が最新の安定版であることを確認する。多言語プラグイン(WPML 等)を併用している場合は、プラグイン同士の互換性もあわせてチェックしておく。

それでも直らない場合に踏むべき最終手順

それでも直らない場合に踏むべき最終手順

キャッシュとセキュリティ系プラグインの完全な切り離し

速度最適化プラグインやサーバー側の動的キャッシュはすでに無効化していても、WAF(ウェブアプリケーションファイアウォール)やセキュリティプラグインが PayPal からのコールバック通信をブロックしている場合がある。一時的にすべてのセキュリティ系プラグインを停止し、サーバーのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストが 200 ステータスを返しているか確認する。

注文メタデータとセッションデータの直接確認

失敗した注文の詳細画面を開き、カスタムフィールドに _ppcp_paypal_order_id というメタキーが存在するか調べる。これが空になっている注文は、まさに注文 ID の引き継ぎに失敗した注文だ。WooCommerce が生成した注文番号は存在するのに PayPal 側の注文 ID だけ欠落している場合は、前述の競合が再現したと断定してよい。

確認項目
注文メタデータ _ppcp_paypal_order_id の有無を確認
アクセスログ /wp-json/paypal/v1/incoming への POST が 200 を返しているか
プラグインバージョン 4.1.0 以上へ更新済みか
データ・技術系の確認ポイント

この三点を確認すれば、問題がインフラ寄りなのかアプリケーション寄りなのか切り分けられる。

よくある質問

PayPal のウェブフック検証失敗は何が原因か

サーバー時刻のずれや PayPal 公開鍵のキャッシュ不整合が最も多い原因だ。接続を一度解除して再接続し、WooCommerce のトランジェントをクリアすることで解決することが多い。まれにホスティング環境のファイアウォールが PayPal の検証用リクエストを遮断しているケースもある。

決済が断続的に失敗する場合、キャッシュが原因か

キャッシュが直接の原因でないケースも多い。キャッシュを完全に停止し、カートやチェックアウトの除外設定を施しても再発するなら、プラグイン内部の競合状態や注文 ID の引き継ぎ不良を疑うべきだ。

WooCommerce PayPal Payments の最新バージョンで問題は修正されたか

バージョン 4.1.0 では、注文 ID のセッション保存タイミングに関する修正が含まれている。4.0.4 以前で OrderProcessor エラーが断続的に出ている場合は、まず 4.1.0 以降へ更新することが推奨される。

注文 ID が保存されない問題はどうやって確認するか

失敗した WooCommerce 注文のカスタムフィールドを確認し、_ppcp_paypal_order_id というメタキーが空かどうかを調べる。空であれば注文 ID の引き継ぎに失敗している。プラグインの詳細ログにも PayPal 側の注文作成リクエストが記録されない。

ウェブフックのエンドポイントにアクセスできるか確認する方法は

サイトのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストを探し、HTTP ステータスが 200 であることを確かめる。PayPal のデベロッパーダッシュボード上でウェブフック URL が本番ドメインを指しているかも同時に検証する。

この記事のポイント

  • ログを有効にして OrderProcessor エラーの前後に PayPal API 呼び出しが存在するか確認する
  • ウェブフック検証失敗は接続の再設定とトランジェントクリアで復旧する可能性が高い
  • 注文 ID のセッション消失は 4.1.0 以上のプラグイン更新で根本対処できる
  • キャッシュ停止だけでは直らない競合はプラグイン内部のタイミング問題を疑う
  • 注文メタデータとアクセスログの二面から原因の切り分けを進める