管理しているクライアントサイトのStripeアカウントから、こんな件名のメールが届きました。
Webhook エンドポイントへのリクエスト送信に問題が発生しました
本文にはこうあります。
- 問題が発生したエンドポイントURL:
https://example.com/shop/?wc-api=wc_stripe - 2026年8月8日以降、17回イベント送信を試みた
17 requests returned HTTP 404, indicating the URL doesn't exist.- 2026年8月17日までに送信を停止する
心当たりを探して、すぐに違和感を覚えました。そのショップ、1年前に削除しているんです。
結論から書くと、削除済みWordPressに紐づくWebhookエンドポイントが、Stripe側に3つも残ったまま放置されていた、というオチでした。決済自体には一切影響がなく、対応は「削除」だけ。ただ、そこにたどり着くまでの切り分けが勉強になったので記録しておきます。
そもそもWebhookとは何か
Stripeは、決済の成功・返金・請求書の発行といった出来事（イベント）が起きたときに、こちらのサーバーに向けてHTTPリクエストを飛ばして知らせてくれます。これがWebhookです。
WooCommerceでStripe決済を使っている場合、「支払いが成功した」という通知をStripeから受け取って、初めてWooCommerce側で注文ステータスが「処理中」に変わります。つまりWebhookは、Stripeとサイトの間の連絡係です。
連絡係が行き先を見失えば、Stripeは「送れませんでした」と警告してくるわけです。
エラーコードから原因を絞り込む
まず見るべきはHTTPステータスコードです。ここで原因の方向性がほぼ決まります。
| コード | 意味 | 主な原因 |
|---|---|---|
| 404 | URLが存在しない | サイト・プラグインの削除、URL変更、パーマリンク変更 |
| 403 | アクセス拒否 | セキュリティプラグインやWAFがブロック |
| 500 | サーバー内部エラー | プラグインのPHPエラー、DB接続不良 |
| タイムアウト | 応答なし | サーバー高負荷、DNS解決失敗 |
今回は404。Stripe側の不具合ではなく、こちら側にURLが無いということです。403ならセキュリティプラグインを疑うところですが、404は「そもそも存在しない」なので話が早い。
URLの形から構成を読み取る
エラーになっていたURLはこれでした。
https://example.com/shop/?wc-api=wc_stripeこの ?wc-api=wc_stripe という形式は、WooCommerce公式のStripe決済プラグイン（WooCommerce Stripe Payment Gateway）が使う旧来のWebhook受信URLです。
そして /shop/ というパスが付いているということは、サイトのルートではなく /shop/ ディレクトリ配下にWordPressがインストールされていたことを意味します。本体サイトとは別に、ショップだけを別インストールで運用していた構成ですね。
その /shop/ を、1年前にショップ運用終了に伴って丸ごと削除しました。URLの持ち主がいなくなったのに、Stripe側の宛先リストだけが生き残っていたというわけです。
「1年前に消したのに、なぜ今？」
ここが一番の疑問でした。1年前に消したのなら、エラーも1年前から出ているはずです。なぜ2026年8月8日から急に17回なのか。
答えはシンプルで、イベントが発生しなければWebhookも送られないからです。
このアカウントは現在、WooCommerceを使っていません。高額な商品が売れたときだけ、お客様がクレジットカードで支払えるようにStripeの決済リンク（Payment Links）を用意して使っています。
つまり流れはこうです。
- 1年以上、決済がまったく発生しない → イベントも発生しない → Webhookも飛ばない → エラーも起きない
- 8月8日、高額商品が1つ売れて決済リンク経由で決済が成立
- Stripeが
payment_intent.succeededなどのイベントを生成 - 登録されている宛先（＝存在しない
/shop/）に向けて配信を試行 - 全部404 → 警告メール
1年間眠っていた地雷が、久しぶりの売上で踏まれたという構図でした。売上が立ったこと自体は喜ばしいのですが。
決済リンクにWebhookは必要ない
ここも整理しておく価値があります。
決済リンク（Payment Links）は、Webhookを一切必要としません。 決済処理から領収書メールの送信まで、すべてStripe側で完結します。入金もそのまま残高に反映されます。
Webhookが必要になるのは、自社サーバー側で何か処理をしたいときです。
- WooCommerceの注文ステータスを更新したい
- 会員サイトの権限を自動付与したい
- 自前のDBに決済記録を書き込みたい
こうした「Stripeの外側で動く処理」がない限り、Webhookは不要です。今回のケースでは、3つのエンドポイントは全て役目を終えていました。
Webhook設定画面がどこにあるか問題
いざ削除しようとして、少し迷いました。
歯車アイコン →「開発者」の設定画面には、APIキーやSDK言語の設定はあるのにWebhookの項目がありません。現在のStripeダッシュボードでは、Webhook管理は「ワークベンチ（Workbench）」という開発者向けツールの中に移動しています。
一番確実なのは、URLを直接叩くことです。
https://dashboard.stripe.com/webhooksこれでワークベンチのWebhookタブが開きます。
見つかったのは3つだった
開いてみると、想定していた1つではなく3つのエンドポイントが並んでいました。
| 送信先 | 状態 | エラー率 |
|---|---|---|
/shop/?wc-api=wc_stripe | アクティブ | 100% |
/shop/wp-json/cpsw/v1/w... | アクティブ | 100% |
/shop/wp-json/cpsw/v1/w... | 無効 | — |
2つ目・3つ目の cpsw は、Checkout Plugins – Stripe for WooCommerce という別のStripe決済プラグインが登録したものです。過去にプラグインを乗り換えた際の名残ですね。3つ目は失敗が続いた結果、Stripeが自動的に無効化した残骸です。
ここが今回一番の教訓でした。
Stripe決済プラグインは、有効化時にWebhookエンドポイントを自動登録することがある。しかしプラグインを削除しても、Stripe側の登録は自動では消えない。
プラグインを乗り換えるたびに宛先が増え、サイトを消しても宛先は残る。誰も掃除しないので、静かに溜まっていくわけです。
削除前に確認したこと
「消えているサイト宛だから消してOK」と即断せず、2点だけ確認しました。
1. 有効なサブスクリプションが残っていないか
Billing → サブスクリプション で、ステータス「有効」の契約を確認します。
WooCommerce Subscriptionsのような仕組みで継続課金を回していた場合、プラグインを削除してもStripe側の課金スケジュールは止まりません。サイトが消えた後もお客様のカードから引き落とされ続ける、という事故があり得ます。ここが0件であることを確認しました。
2. 未処理の決済が無いか
「支払い」一覧で、8月8日以降の成功した決済を確認します。決済リンク経由の1件のみで、残高にも正しく反映済み。Webhookが届かなかったことによる取りこぼしはありませんでした。
もし checkout.session.completed イベントの配信に失敗していた場合、Stripe側では入金済みなのにサイト側では注文が完了していないという状態があり得るので、そのときは個別照合が必要になります。
削除作業
確認が済めば、あとは各行の右端の「…」から削除するだけ。3つとも消して、作業完了です。所要3分。
放置しても8月17日にStripeが自動停止しますが、ログが汚れたままになるので明示的に削除しておくのが気持ちいいです。
再発防止チェックリスト
WordPressサイトで決済を扱う場合、サイトやプラグインを消すときにStripe側も掃除するという手順が抜けがちです。チェックリスト化しました。
決済プラグインを削除・変更するとき
- [ ] Stripeダッシュボードの
https://dashboard.stripe.com/webhooksを開く - [ ] そのプラグインが登録したエンドポイントを特定する
- [ ] 有効なサブスクリプションが紐づいていないか確認する
- [ ] 不要なエンドポイントを削除する
- [ ] APIキー（制限付きキー）も不要なら失効させる
サイト・ショップを閉じるとき
- [ ] 上記に加えて、有効なサブスクリプションを全て確認・整理する
- [ ] 決済手段が他に残っているか（決済リンク等）を棚卸しする
- [ ] クライアントに現状と今後の運用方法を書面で共有する
年1回くらいの棚卸し
- [ ] Webhook一覧のエラー率をチェック（100%のものは死んでいる）
- [ ] 使っていないAPIキーが残っていないか確認
まとめ
- Stripeの404エラーは、ほぼ確実にこちら側にURLが存在しないことを意味する
- URLの形（
?wc-api=や/wp-json/）から、どのプラグインが登録したものか推測できる - プラグインを消してもStripe側のWebhook登録は残る
- 決済リンクだけの運用なら、Webhookは不要
- 削除前に「有効なサブスクリプション」と「未処理の決済」だけは必ず確認する
- Webhook設定は
https://dashboard.stripe.com/webhooksを直接開くのが早い
久しぶりの売上が、1年間放置されていた設定の不備を教えてくれた——という、なかなか味わい深い一件でした。同じような構成でサイトを預かっている方は、一度Webhook一覧を覗いてみることをおすすめします。
