WooCommerce Subscriptionsで同じ定期購入の更新が何度も失敗する場合、原因は「カードそのものが通らない」「保存された支払い情報がサイト側から使えない」「スケジュール処理が正しく動いていない」の3系統に分けられます。失敗した決済は再試行のルールに従って自動でやり直されるため、根本の原因を直さない限り失敗の通知が続きます。この記事では、失敗の理由をどこで読み取るか、原因ごとの直し方、そして再発を防ぐための確認項目を説明します。
失敗が「繰り返される」仕組みを知っておく
定期購入の更新日が来ると、WooCommerce Subscriptionsは更新用の注文（更新注文）を作り、保存されている支払い方法で決済を試みます。決済が失敗すると、更新注文は「失敗」、定期購入は「保留」になります。
ここで再試行の設定が有効になっていると、あらかじめ決められた間隔で同じ決済が自動的にやり直されます。再試行の有無は「WooCommerce」→「設定」→「定期購入（Subscriptions）」のタブにある失敗した決済の再試行に関する項目で切り替えられます。再試行の間隔や回数の既定値はバージョンによって変わる可能性があるため、詳しくは公式ドキュメントで確認してください（2026年10月現在）。
つまり「失敗が繰り返される」こと自体は仕様どおりの動きで、問題は再試行しても成功しない原因が残っていることです。再試行のたびに顧客へ失敗メールが届くこともあるため、原因の特定を急ぐ必要があります。
失敗の理由を確認する場所
原因を推測で決めず、まず記録を読みます。確認する場所は次の4つです。
- 定期購入の編集画面のメモ：「WooCommerce」→「定期購入」から該当の定期購入を開くと、右側にメモが時系列で残っています。更新注文が作られた時刻、失敗した理由の要約、ステータスが変わった記録がここで追えます。
- 更新注文のメモ：更新注文を開くと、決済サービスから返ってきたエラーの内容が記録されていることがあります。「カードが拒否された」「顧客が見つからない」「認証が必要」など、原因を絞る一番の手がかりです。
- WooCommerceのログ：「WooCommerce」→「ステータス」→「ログ」で、決済プラグインのログや、PHPの致命的エラーのログ（fatal-errors）を確認します。決済プラグインのログは、プラグインの設定でログ出力を有効にしないと残らない場合があります。
- 決済サービスの管理画面：Stripeなどを使っている場合、そちらのダッシュボードで決済の試行と拒否の理由が確認できます。サイト側に記録が何もないのに決済サービス側に記録がある場合は、結果がサイトに戻ってきていないことを示します。
原因1：カードが通らない（顧客側の問題）
残高不足、有効期限切れ、カード会社による不正利用の判定などで拒否されている場合、サイト側の設定では直せません。再試行しても同じ結果になりやすいため、顧客に支払い方法の更新をお願いします。
顧客は、マイアカウントの定期購入の画面から支払い方法を変更できます（決済プラグインが支払い方法の変更に対応している場合）。新しいカードを登録すると、以降の更新はそのカードで行われます。保留中の更新注文は、顧客がマイアカウントから手動で支払うこともできます。
ヨーロッパなどで求められる追加の本人認証（3Dセキュア）が更新時に必要と判定された場合も、顧客が操作しない限り決済は完了しません。決済サービス側の記録に「認証が必要」と出ている場合は、顧客に連絡して支払い画面から認証してもらいます。
原因2：保存された支払い情報がサイトから使えない
ステージング（複製サイト）モードになっている
サイトの引っ越しやドメイン変更、ステージング環境からの複製を行ったあとに更新が失敗し始めた場合、最初に疑うのがこれです。WooCommerce Subscriptionsは、サイトのURLが記録と異なると「複製サイト」と判断し、二重請求を防ぐため自動更新を止めて手動更新に切り替えます。
この状態になると、管理画面の上部に複製サイトであることを知らせる通知が表示されます。本番サイトであることが確かな場合だけ、その通知から自動決済を有効に戻します。ステージング環境でこの操作をすると、本番と同じ顧客に二重に請求が飛ぶおそれがあるため、ブラウザのアドレスバーでどちらのサイトを開いているかを確かめてから操作してください。
決済サービスのアカウントやモードが変わった
決済プラグインのAPIキーを別のアカウントのものに差し替えた、テストモードと本番モードを切り替えた、といった場合、サイトに保存されている顧客IDや支払い方法のIDが新しいアカウントには存在しません。更新注文のメモに「顧客が見つからない」といった内容が出るのが典型です。元のアカウントのキーに戻すか、顧客に支払い方法を登録し直してもらう必要があります。
Webhookが届いていない
Stripeなどでは、決済の最終的な結果がWebhookでサイトに通知されます。Webhookの設定が抜けている、署名用のシークレットが古い、セキュリティプラグインやWAFが通知を遮断している、といった状態では、決済サービス側では成功していてもサイト側の更新注文が「保留」「失敗」のまま残ります。決済プラグインの設定画面に表示されるWebhookのURLが決済サービスに登録されているか、決済サービス側の配信履歴でエラーが出ていないかを確認してください。
原因3：スケジュール処理が動いていない・途中で止まる
定期購入の更新はAction Schedulerという仕組みで予約され、woocommerce_scheduled_subscription_payment というアクションとして実行されます。「WooCommerce」→「ステータス」→「予定されたアクション」でこのフック名を検索すると、各定期購入の更新が予定どおり実行されたか、失敗したかがわかります。
- 「過去の予定」が溜まっている：WP-Cronが動いておらず、更新が実行されていません。アクセスの少ないサイトや、
DISABLE_WP_CRONを設定したのにサーバー側のcronを登録していないサイトで起こります。 - アクションが「失敗」になっている：実行中にPHPのエラーやタイムアウトが起きています。ログの詳細と、前述のfatal-errorsのログを照らし合わせると、どのプラグインで止まっているかが見えてきます。
- 同じ更新が二重に実行されている：サーバーのcronとWP-Cronが重なって動いている、キャッシュやバックアップの処理でサイトが二重に動いている、などが考えられます。
プラグインの更新直後から失敗が始まった場合は、ステージング環境で該当プラグインを1つずつ無効化し、手動で更新処理を実行して再現するかを確かめます。定期購入の編集画面にある操作メニューから更新処理を手動で実行できますが、実際に決済が走るため、本番で試すのは原因を直したあとにしてください。
再発を防ぐための確認項目
- サイトの移転・複製のあとは、管理画面に複製サイトの通知が出ていないかを確認する。
- 決済プラグインのキーを変更する前に、既存の定期購入への影響を確かめる。
- 「予定されたアクション」で、更新のアクションが「過去の予定」や「失敗」で溜まっていないかを定期的に見る。
- サーバー側のcronでWP-Cronを動かしている場合、その設定が移転後も生きているかを確かめる。
- 作業の前には、データベースのバックアップを取っておく。定期購入と更新注文の状態を元に戻せるようにするためです。
まとめ
- 失敗した決済は再試行ルールに従って自動でやり直されるため、原因が残る限り失敗が繰り返される。
- 原因は定期購入と更新注文のメモ、WooCommerceのログ、決済サービスの記録の順に読んで特定する。
- カードの拒否や追加認証は顧客側の対応が必要で、支払い方法の更新を依頼する。
- 移転後の複製サイト判定、決済アカウントの切り替え、Webhookの不達は、サイト側で直せる代表的な原因。
- 「予定されたアクション」で更新処理が実行されているかを確認し、WP-Cronやサーバーのcronの状態も見る。