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

Stripeがテストでは動くのに本番で動かないとき、最初の30分でやること

Stripeがテストでは動くのに本番で動かないときに、test/live混在（キー/Webhook/Price/戻りURL）を30分で切り分ける。

著者: 川原更新: 2026-05-18障害対応RSS
Xで共有FacebookLinkedIn
料金相談

Stripeがテストでは動くのに本番（live）で動かないとき、最初の30分でやるべきことは「モード（test/live）の混在」を疑い、キー・Webhook・Price/商品・許可ドメインを“同じモードで揃える”ことです。

この事故は、直し方が分かっていても「どれが混ざっているのか」を外すと延々とハマります。最初の30分は、原因の推測より 揃っている/揃っていない を潰す順番を固定します。

0. まずやらないこと（事故を拡大しやすい）

  • いきなりコードを大改修する（だいたい設定の取り違え）
  • いきなりWebhook Secretをローテーションする（混在の証拠が消える）
  • いきなり「テスト用のIDを本番に流用」しようとする（test/liveはデータが別）

1. 症状を1行で固定する（3分）

次を1行でメモします（あとで必ず使います）。

  • どこが「動かない」のか（例: Checkoutが開かない / 支払い成功後に権限付与されない / Webhookが届かない）
  • どの環境か（本番/ステージング、どのURLの話か）
  • いつからか（go-live / デプロイ / 環境変数変更）
  • エラー文言（そのまま保存）

2. “モード”の混在を最優先で潰す（8分）

最頻出の混在パターンはこの4つです。

  • フロントが pk_test_、サーバーが sk_live_（またはその逆）
  • Webhook endpoint は登録したが 別モード側 を見ている
  • Price / Product などのIDが 別モードのもの（test側の price_... をlive側で参照）
  • “見ているStripeアカウント”が違う（複数アカウント運用・Connect含む）

2-1. キーのモードを固定する（最短チェック）

  • クライアント側の公開鍵が pk_live_ になっているか（本番）
  • サーバー側の秘密鍵が sk_live_ になっているか（本番）
  • 逆に、テスト環境は pk_test_ / sk_test_ で揃っているか

ここが揃っていなければ、以降の調査はほぼ無駄になります。まず揃えます。

3. Price / Product / Plan が“live側に存在する”か（7分）

Checkoutや課金は、キーだけ合っていても 参照するIDがtest側 だと失敗します。

最初の30分は「コード側が参照しているID」を列挙して、Stripe Dashboard で 同じモード（live）に存在する かだけ確認します。

  • price_...（Price）
  • prod_...（Product）
  • coupon_...（Coupon）
  • txr_... / 税関連の参照（導入している場合）

結論が“存在しない”なら、原因は確定です。live側で作り直し、コードの参照を入れ替えます。

4. Webhookが“live側の設定”になっているか（7分）

テストで通っていたのに本番で「支払いは成功したのに、権限付与がされない」場合、Webhookがlive側で設定されていない・または別モードを見ているケースが多いです。

最短で潰すために、次だけ固定します。

  • Stripe Dashboard の Test mode / Live mode の切り替え を正しい側に合わせる
  • Webhook endpoint が live側に存在 するか
  • その endpoint の Signing secret（whsec_...） を、サーバーが参照しているか

同じURLでも、test/liveで Signing secret は別 なので「URLが同じだからOK」は危険です。

5. 戻りURL/許可ドメインの取り違えを潰す（3分）

Checkoutが開く/戻る周りで詰まるときは、モード混在というより 許可ドメイン/リダイレクト の不整合が原因のことがあります。

  • 本番の success_url / cancel_url が、意図したドメインになっているか
  • 本番環境で、不要なリダイレクト（wwwありなし、http→https）が混ざっていないか

6. 30分で出す“結論”の型（次の1時間を固定）

最初の30分で、結論を次のどれかに落とします。

  1. キー混在: pk_* / sk_* を同じモードに揃える（環境変数・デプロイ先の取り違えを解消）
  2. ID混在: price_ / prod_ 等をlive側で作り直し、参照を入れ替える
  3. Webhook混在: live側にendpointを作り、whsec_ を正しいものに固定する
  4. ドメイン/戻りURL不整合: 本番URLと許可設定を揃えて、リダイレクトを減らす

SiteOpsで初動を速くする（再発防止）

テスト→本番の切り替え事故は、「いつから」「何を切り替えたか」が曖昧だと長引きます。次からは、異常と変更点を並べて見られる状態にしておくと初動が速くなります。

  • まずは ダッシュボード で、Stripe系の異常と優先順位を固定します
  • 相談したい場合は お問い合わせ から状況を送ってください（混在ポイントの特定を一緒にやれます）
  • 料金と導入の流れは 料金ページ にまとめています

関連

  • /media/stripe-payment-succeeded-but-access-not-granted-first-30-minutes
  • /media/stripe-webhook-events-not-firing-first-30-minutes
  • /media/stripe-webhook-signature-verification-failed-first-30-minutes

参考にした一次情報

  • Stripe Docs: API keys（test/live modes）
  • Stripe Docs: Testing use cases（test mode）
  • Stripe Docs: Receive Stripe events in your webhook endpoint（test vs live）

この記事を書いた人

川原

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

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事Cloudflare 523（Origin is unreachable）が出たとき、最初の30分でやること次の記事AdSenseのCPC（単価）が急落したとき、最初の30分でやること

次にやること

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

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