沼 健一郎

決済まわり

Stripe決済が失敗するとき、どの順で疑うか

／Stripeの導入・審査・トラブル対応。実際の案件で潰した原因と、その切り分け手順。

「決済ボタンを押しても進まない」という相談を受けたとき、私はいつも同じ順番で切り分けます。原因の候補は多く見えますが、実務で遭遇する頻度には偏りがあります。頻度の高い順に潰していけば、たいてい30分以内に原因にたどり着きます。

この記事は、実際の案件で潰した順にそのまま並べたものです。

結論：この順で見る

  1. テストモードと本番モードの混在
  2. リダイレクトURLの設定漏れ
  3. 3Dセキュア認証で止まっている
  4. カスタマーポータルが有効化されていない
  5. Radar（不正検知）が正規の客を弾いている

上から順に確認してください。1と2で7割は解決します。

1. テストモードと本番モードの混在

最も多い原因です。そして最も気づきにくい。

Stripeはテスト環境と本番環境でキーが完全に分かれています。

テスト: pk_test_xxxxx / sk_test_xxxxx
本番:   pk_live_xxxxx / sk_live_xxxxx

混在の典型パターンは3つあります。

パターンA: 公開キーは本番、シークレットキーはテスト

決済フォームは表示されるのに、送信すると失敗します。エラーメッセージが「No such customer」や「No such price」になることが多い。テスト環境で作った顧客IDや価格IDを、本番環境で探しにいっているためです。

パターンB: Payment Link がテストモードのまま

Payment Link は作成したモードに紐づきます。テストモードで作ったリンクを本番サイトに貼ると、本番のカードでは決済できません。URLだけでは見分けがつかないので、ダッシュボードのモードを切り替えて、そのリンクが存在するか確認してください。

パターンC: Webhookエンドポイントがテスト側にしかない

決済自体は通るのに、その後の処理（会員登録、メール送信、DB更新）が動かない。ダッシュボードの「開発者 > Webhook」で、本番モードにエンドポイントが登録されているかを見ます。

確認手順

ダッシュボード左上のモード切替を本番にして、以下を1つずつ照合します。

  • サイトに埋め込まれている公開キーの接頭辞（pk_live_ か pk_test_ か）
  • サーバー側のシークレットキーの接頭辞
  • 商品・価格IDが本番モードに存在するか
  • Webhookエンドポイントが本番モードに登録されているか

4つ全部が本番で揃っていなければ、そこが原因です。

2. リダイレクトURLの設定漏れ

決済は成功しているのに、客が「決済できたか分からない」と言う場合です。Stripeダッシュボードには成功記録があるのに、サイト側では何も起きていない。

Checkout や Payment Link には、決済後の遷移先を設定する項目があります。ここが空だとStripeの標準完了画面で止まり、自分のサイトには戻ってきません。

設定すべきは2つです。

  • 成功時のURL（success_url）: 決済完了ページ
  • キャンセル時のURL（cancel_url）: 元の商品ページ

成功ページは必ず作ってください。「ありがとうございました」の1枚があるだけで、問い合わせが目に見えて減ります。決済したのに何も起きないと、客は二重に決済しようとします。

決済完了ページに入れるべきもの

  • 決済が完了した旨の明示
  • 次に何が起きるか（メールが届く、担当から連絡がある等）
  • 届かない場合の連絡先

3行で足ります。凝る必要はありません。

3. 3Dセキュア認証で止まっている

日本のカード会社は3Dセキュア（本人認証）を必須にしているところが増えています。認証画面が別ウィンドウで開き、そこで止まっているケースです。

とくにスマートフォンで起きます。ポップアップブロックや、カード会社アプリへの遷移で戻ってこられなくなる。

テスト方法

Stripeが用意しているテストカードで再現できます。

3Dセキュア認証あり: 4000 0027 6000 3184

有効期限は未来の任意の日付、CVCは任意の3桁で通ります。

このカードで決済すると認証画面が出るので、そこから正常に完了ページまで戻れるかを、必ずスマートフォンの実機で確認してください。PCでは問題なく通るのに、スマホで詰まる例が実際にあります。

比較用に、他のテストカードも挙げておきます。

成功:           4242 4242 4242 4242
残高不足で失敗:  4000 0000 0000 9995
カード拒否:      4000 0000 0000 0002

失敗パターンも必ずテストしてください。「失敗したときに何が表示されるか」を見ていない実装が非常に多い。客は失敗したときにこそ問い合わせてきます。

4. カスタマーポータルが有効化されていない

サブスクリプションを売っている場合に限った話です。

客が自分で解約やカード変更をする画面を「カスタマーポータル」と呼びます。これはダッシュボードで明示的に有効化する必要があり、初期状態では無効です。

有効化していないと、ポータルへのリンクを踏んだ瞬間にエラーになります。決済は通っているので気づきにくく、解約したい客からのクレームで初めて発覚します。

場所は「設定 > 請求 > カスタマーポータル」です。有効化したうえで、以下を決めます。

  • 客に解約を許可するか
  • 支払い方法の更新を許可するか
  • プラン変更を許可するか

解約をポータルで許可しない場合、特定商取引法の表示との整合に注意してください。「いつでも解約できます」と書いているのに解約導線がない状態は、審査でも指摘されます。

5. Radar（不正検知）が正規の客を弾いている

ここまでで解決しない場合に疑います。頻度は低いですが、当たると影響が大きい。

StripeにはRadarという不正検知機能があり、リスクスコアが高い決済を自動でブロックします。これが正規の客を弾いていることがあります。

確認方法

ダッシュボードの「決済」で、失敗した取引を開きます。ブロックされていれば以下が表示されます。

  • リスクスコア（0〜100）
  • 発動したルール
  • ブロック理由

正規の客が弾かれている場合、共通点があることが多いです。海外IPからのアクセス、同一IPからの連続注文、メールアドレスのドメインなど。

ルールはカスタマイズできますが、緩めるとチャージバックのリスクが上がります。安易に無効化せず、どのルールが何件弾いているかを実データで確認してから調整してください。

切り分けの前にやること

原因を探す前に、状況を確定させます。

「決済できない」の意味を確定する

  • 決済ボタンが表示されない
  • ボタンを押しても何も起きない
  • 決済画面までは行くが送信でエラー
  • 決済は完了するがその後が動かない

この4つは原因が全く違います。客の「決済できない」をそのまま受け取ると遠回りになります。

Stripeダッシュボードに記録があるか見る

記録があれば、問題はStripeに到達した後です。記録がなければ、そもそもStripeまで届いていません。この1点で調査範囲が半分になります。

失敗した取引のCSVを取る

ダッシュボードから失敗した決済をCSVでエクスポートできます。エラーコードごとの件数を見れば、単発の事故か構造的な問題かがすぐ分かります。1件だけならカード側の問題、同じエラーが並んでいれば実装側の問題です。

まとめ

Stripeの決済トラブルは、原因の種類自体は多くありません。多いのは「複数の原因が同時に起きている」ケースです。1つ直して直らないとき、最初の切り分けが間違っていたのではなく、2つ目が隠れているだけということがよくあります。

上から順に、1つずつ潰してください。

決済まわりで詰まっている方へ

原因の特定と修正を承っています。Stripe決済の導入、決済トラブルの調査・復旧、WooCommerce連携など。ココナラで受注しています。

販売実績58件・評価5.0・出品者ランク プラチナ（2026-09時点）

決済まわり の他の記事