SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Stripeの支払いが突然0件になったとき、最初の30分でやること

Stripeで支払いが突然0件になった直後に、原因（流入/Checkout/決済失敗/Webhook/提供）を30分で切り分ける手順です。

著者: 川原更新: 2026-05-17収益改善RSS
Xで共有FacebookLinkedIn
料金相談

Stripeの支払いが突然0件になったとき、最初の30分でやることは「①そもそも購入開始（Checkout開始）が起きていないのか」「②購入開始は起きているが決済が失敗しているのか」「③決済は成功しているが提供/計上が止まっているのか」を分けることです。ここを分けずにデプロイや設定を触ると、復旧が遅れます。

最初に結論

  • まずStripe Dashboardで、直近30〜60分の“成功/失敗/試行”が本当に0かを確認します（期間/通貨/フィルタ/テスト・本番の取り違えを潰す）。
  • 次に、Checkout/支払いの試行自体が起きているかを見て、0なら「流入/導線/アプリ側の開始地点」に戻ります。
  • 試行はあるのに成功がないなら、失敗理由の型（declined/認証/連携/3DS/上限） を固定し、上位の原因を1つに絞ります。
  • 成功はあるのに売上/提供が止まっているなら、Webhook（配信/署名/受信）とアプリ側の提供処理 を最短で確認します。

まずやらないこと（誤爆を止める）

  • 原因が分かる前に、Stripeの設定（Webhook/商品/価格/支払い方法）を一気に触らない
  • 「とりあえずデプロイ」や「WAF/ルーティングを雑に緩める」を先にしない
  • 「売上0」を見て、いきなり値下げ/広告出稿など別レイヤーの打ち手に逃げない

最初の30分でやること

1) “本当に0か”を確認する（ダッシュボードの前提潰し）

  • 見ているのは 本番モード か（Test data viewになっていないか）
  • 期間が「今日」ではなく「直近1時間」になっているか（時差/集計遅延/フィルタ誤りを潰す）
  • 通貨/国/プロダクトなどのフィルタが残っていないか
  • 過去に似た落ち方がないか（同じ曜日・時間帯に偏りがないか）

2) “購入開始”が起きているかを確認する（Checkout/支払いの試行）

ここが0なら、問題はStripeではなく「流入/導線/アプリ側の開始地点」にあります。

  • Checkout Sessionの作成（またはPaymentIntent作成）が増えているか
  • アプリ側の「購入ボタン→Checkout開始」までのログが動いているか
  • 直近の変更（デプロイ/機能フラグ/環境変数/ルーティング）時刻と、0になった時刻が一致するか

判断の目安:

  • 試行が0 → まず /media/ga4-conversion-zero-first-30-minutes で「そもそも購入に来ていない/押されていない」を切る
  • 試行はあるが成功が0 → 次へ

3) 失敗の型を固定する（決済失敗 vs 認証 vs 連携）

「成功0」でも失敗の型で優先順位が変わります。まず“型”を1つに絞ります。

  • 失敗が特定の支払い方法に偏っていないか（カード/Apple Pay/Link など）
  • insufficient_funds / do_not_honor 等のカード拒否が急増していないか
  • 3Dセキュア/認証（SCA）が途中で落ちていないか
  • 直近で 支払い方法の追加/削除、地域制限、税/請求先住所必須化 などを入れていないか

同じテーマの切り分け:

  • 失敗が急増した: /media/stripe-payment-failures-spike-first-30-minutes
  • CheckoutのCVRが落ちた: /media/stripe-checkout-cvr-drop-first-30-minutes

4) 成功はあるのに“売上/提供が止まっている”場合（Webhookと提供）

このパターンは「Stripeは成功しているのに、アプリ側が反映できていない」状態です。

  • Webhookの配信失敗が増えていないか（再試行が溜まっていないか）
  • 署名検証の失敗が出ていないか
  • Cloudflare WAFがWebhookを弾いていないか（403/401/1020 など）

該当チェックリスト:

  • /media/stripe-webhook-delivery-failure-first-30-minutes
  • /media/stripe-webhook-signature-verification-failed-first-30-minutes
  • /media/stripe-webhook-blocked-by-waf-first-30-minutes
  • 決済は成功したのに提供されない: /media/stripe-payment-succeeded-but-access-not-granted-first-30-minutes

5) 次の1時間でやることを1つに絞る（復旧ルートを確定）

30分で「原因の層」を固定したら、次の1時間は“復旧手段が一番速い1つ”に絞ります。

  • 試行が0 → ルーティング/導線/購入開始（Checkout作成）を復旧する
  • 試行はあるが失敗が増えている → 失敗型に応じて支払い方法/認証/制限の当たりを付け、最小の変更で復旧する
  • 成功はあるが提供/計上が止まっている → Webhook（配信/署名/受信）と提供処理の復旧に集中する

参考（一次情報）

  • Stripe Docs: Webhooks（配信/再試行/署名検証の前提）: https://stripe.com/docs/webhooks

SiteOpsで最短にする

複数サイト運営では、同じ「売上0」でも原因は毎回違います。SiteOpsは「異常（何が起きたか）」と「変更（何を変えたか）」を時刻で並べて、最初の30分の切り分けを短縮します。

相談する（SiteOps）

  • いま起きている症状を整理して、復旧の最短ルートを作りたい場合は、SiteOpsで「いつから/どのプラン/どの支払い経路/直前の変更」を並べて確認できます。
  • 料金: /#pricing
  • 相談: /contact

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

AdSenseのCPC（単価）が急落したとき、最初の30分でやること収益改善更新: 2026-05-17CSP強化でAdSenseが出なくなったとき、最初の30分でやること収益改善更新: 2026-05-17AdSenseのdata-ad-slot未設定で広告が出ないとき、最初の30分でやること収益改善更新: 2026-05-16
前の記事料金ページで離脱される前に潰す「よくある誤解」チェックリスト次の記事Cloudflare WAFでStripe webhookが届かないとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ