沼 健一郎

決済まわり

Stripe決済を本番公開する前の受け入れテスト8ステップ

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

決済を実装したあと、何をどこまで確認すれば「公開してよい」と言えるのか。基準がないと、公開後に客からの問い合わせで欠陥を知ることになります。

実案件で使っている検証手順を、そのまま公開します。8ステップです。全部通らなければ公開しません。

なぜ手順が要るか

決済まわりの不具合には共通の性質があります。

気づくのが客より遅い。 決済が失敗しても、こちらには何も通知が来ません。客が離脱するだけです。売上が立たない理由が「そもそも決済できていない」であることに、数週間気づかない例があります。

部分的に動く。 PCでは通るがスマホで止まる。カードは通るがコンビニ決済で止まる。成功は動くが失敗時の表示が壊れている。「一度通ったから大丈夫」が最も危険です。

だから手順にして、毎回同じことを確認します。

STEP 1: 入口から決済ページへの遷移

LPや商品ページの決済ボタンを押して、決済ページに到達するか。

確認するのは遷移だけではありません。

  • ボタンがスマートフォンで押せる位置にあるか（キーボード表示で隠れないか）
  • 遷移先がhttpsか
  • 別タブで開くのか同一タブか（別タブだと戻れなくなる客がいます）

STEP 2: 決済ページの内容確認

Stripeの決済ページに表示される内容が正しいか。ここは客が金額を確認する画面なので、間違いは致命的です。

  • 商品名が客に伝わる表記か（社内の管理名が出ていないか）
  • 金額が正しいか、税込か税別か明示されているか
  • サブスクの場合、請求サイクルが表示されているか（月額か年額か）
  • 利用規約への同意チェックボックスがあるか

商品名は要注意です。Stripe側に登録した名前がそのまま出るので、「テスト商品」「新規プラン」のまま公開されている例を何度も見ました。

STEP 3: テスト決済の実行

Stripeのテストカードで決済します。テストモードで実施してください。

成功:            4242 4242 4242 4242
3Dセキュア認証:   4000 0027 6000 3184
残高不足で失敗:   4000 0000 0000 9995
カード拒否:      4000 0000 0000 0002

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

成功パターンだけでなく、失敗パターンも必ず流してください。 失敗時に何が表示されるかを確認していない実装が非常に多い。客は失敗したときにこそ問い合わせてきます。「エラーが出ました」としか言えない客に、こちらが状況を聞けるようにしておく必要があります。

3Dセキュアのテストはスマートフォンの実機でやってください。PCでは通るのにスマホで戻ってこられない、という事故が実在します。

STEP 4: 決済処理の確認

決済が完了したあと、システム側で何が起きるべきかを確認します。

  • Stripeダッシュボードに取引が記録されているか
  • 金額・通貨が正しいか
  • サブスクの場合、サブスクリプションが作成されているか
  • 顧客（Customer）が作成されているか

ここで記録がなければ、決済がStripeまで届いていません。実装側の問題です。

STEP 5: リダイレクトの確認

決済後、自分のサイトの完了ページに戻ってくるか。

戻ってこない場合、success_url が設定されていません。Stripeの標準完了画面で止まると、客は「決済できたのか分からない」状態になり、二重決済を試みます。

完了ページには3つ入れてください。

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

キャンセル時の遷移先（cancel_url）も設定します。客が決済をやめたとき、404に飛ばさないためです。

STEP 6: 後続処理の確認

決済をトリガーに動くはずの処理が動いているか。

  • 会員登録・権限付与
  • データベースへの記録
  • 外部サービスへの連携

これらはWebhookで動いていることが多いので、Webhookが本番モードに登録されているかを確認します。テストモードにしか登録がないと、本番決済で何も起きません。

Stripeダッシュボードの「開発者 > Webhook」で、エンドポイントごとの成功・失敗が見られます。失敗が並んでいれば、受け側が落ちています。

STEP 7: メール到達確認

決済に関わるメールは複数あります。全部届くか確認してください。

Stripeから客への決済完了通知

ダッシュボードの設定で有効化しているか。無効なら客には何も届きません。

サイトからの自動返信

WordPressやフォームプラグインから送るメール。これが一番届きません。 詳しくは別記事に書きますが、レンタルサーバーの標準メール送信は Gmail に届かないことがあります。必ず実際のGmailアドレスで受信確認してください。

管理者への通知

注文が入ったことに気づけるか。ここが動いていないと、決済されているのに発送されない事故になります。

3通すべて、迷惑メールフォルダも確認してください。届いていても迷惑メール扱いなら、届いていないのと同じです。

STEP 8: ダッシュボードでの照合

最後に、Stripeダッシュボードとサイト側の記録を突き合わせます。

  • 取引件数が一致するか
  • 金額の合計が一致するか
  • 顧客情報が正しく紐づいているか

テスト段階で数件のうちは目視で足ります。ここでズレていれば、本番で必ず問題になります。

本番切り替え時のチェック

テストが全部通ったら、本番モードに切り替えます。切り替え時に見落としやすいのが以下です。

  • 公開キー・シークレットキーを本番のものに差し替えたか
  • 商品・価格を本番モードで作り直したか（テストモードのIDは本番では使えません）
  • Webhookエンドポイントを本番モードに登録したか
  • Payment Linkを使っている場合、本番モードで作り直したか

そして本番切り替え後、少額でいいので実際のカードで1回決済してください。 テストカードで通ることと、本物のカードで通ることは別です。

まとめ

8ステップは多く見えますが、慣れれば30分程度です。この30分を惜しむと、公開後に「売上が立たない理由が分からない」という何倍も高くつく状態になります。

とくにSTEP3の失敗パターンとSTEP7のメール到達は、飛ばされがちで、飛ばすと必ず後で問題になります。

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

Stripe決済の導入、決済トラブルの調査・復旧を承っています。テスト設計から本番切り替えまで、この手順で進めます。

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

決済まわり の他の記事