2026 Stripeテストモードで領収書メールが届かない？開発者はどう検収する？

決済は成功したのに、Stripeから領収書メールが届かない。
テストモードでは、Stripe自身の領収書や請求書メールが送信されない場合があります。未着だけで連携失敗と判断せず、Stripeのイベント、自社アプリの通知、実際の受信を分けて確認してください。

独立開発者：テスト環境で決済後の通知を検証したい方。
QAエンジニア：決済イベントの成功とメール受信を区別したい方。
全スタック開発者：支払い成功後に受信箱が空になる原因を調べている方。

送信前に、今回確認するメールを決める

まず、確認対象を「Stripeが生成する領収書・請求書メール」と「自社アプリが送る支払い通知」に分けます。送信元も処理経路も異なるため、Stripeの領収書を待ちながら自社通知の動作まで判定すると、原因の切り分けを誤ります。

テスト記録には、テスト環境で実行した操作、確認したいメールの種類、宛先、注文や決済を識別できる情報を残します。宛先には、チームで管理できるテスト受信アドレスを使い、個人の主メールをテストデータに混ぜないようにします。メールアドレスと注文情報の扱いを分ける考え方は、テストデータで個人情報を混在させない方法も参考になります。

Stripeの領収書は、Chargeオブジェクトの領収書関連フィールドやアカウント設定に関係します。ただし、フィールドに値があることと、メールが相手の受信箱に届いたことは同じ証拠ではありません。対象となるChargeの仕様は、StripeのChargeオブジェクトにある領収書フィールドの説明で確認してください。

支払い成功後に領収書メールが届かないのはなぜですか？

Stripeテストモードでは、特定の領収書や請求書メールが実際には送信されないことがあります。Stripeのテスト環境におけるメールの説明と請求書送信APIのテストモードに関する記載を、今回のメール種別に合わせて確認してください。これは「テストモードではすべてのメールが送信されない」という意味ではありません。Stripe自身が送るメールと、自社のメール基盤から送る通知を一括りにしないことが重要です。

このため、テストモードで決済が成功したのにStripeの領収書が届かなくても、それだけでは決済連携の故障を示しません。反対に、自社アプリの通知を検証したいなら、Stripeからの領収書を待つのではなく、自社の送信処理を追ってください。

決済イベントと自社通知を順に追う

次の順で記録を突き合わせます。イベントが作られたこと、Webhookを受け取ったこと、メール送信を要求したこと、実際に受信したことは、それぞれ別の確認段階です。

1. テスト環境で決済を実行し、ダッシュボード上の決済オブジェクトと状態を確認します。
2. 対象イベントを開き、イベントの種類と環境を確認します。StripeのEventオブジェクトではlivemodeなどの情報を確認できます。判定に使うフィールドはStripe Eventオブジェクトの仕様に照らしてください。
3. 自社のWebhook受信ログで、イベントID、受信結果、処理結果を照合します。イベントの種類はStripeのイベントタイプ一覧で確認し、使っている決済フローに合ったものを追います。
4. Webhookから注文更新、通知生成、メール送信要求までのアプリ側ログを追跡します。宛先、件名、本文の主要項目、注文状態を記録してください。
5. メール送信サービス側の記録で、送信要求の受付や拒否などを確認します。送信要求が成功した記録は、受信箱への到達を証明しません。
6. 管理されたテスト受信アドレスでメールを開き、宛先、件名、注文情報、金額や支払い状態の表示をアプリ側の注文と照合します。

Webhookの配信記録は、Stripeから自社のエンドポイントへのイベント伝達を調べるためのものです。イベントの発生やWebhook受信だけを根拠に、通知メールの送信や受信まで完了したと判断しないでください。イベントと配信の関係はStripeのEventsに関する説明で確認できます。

invoice.sentイベントはメール到達を示す？

いいえ。invoice.sentは請求書に関するイベントとして扱い、受信者の受信箱にメールが届いた証拠とは分けてください。イベント記録で確かめられるのはStripe側のイベント情報や、そのイベントが自社に配信されたかどうかです。受信箱に到達したことは、受信側での確認やメール基盤の配信記録など、別の証拠で検証します。

同じ考え方は自社通知にも当てはまります。アプリがメール送信APIを呼び出しても、宛先の誤り、送信サービス側の拒否、受信側の迷惑メール判定などで、期待した場所に見つからない可能性があります。送信要求の記録と、実際にメールを確認した記録を別々に残してください。自社メールの到達経路を調べるときは、メール配信の確認ポイントも役立ちます。

自社通知は受信箱だけで合否を決めない

テスト環境で自社通知を確認するときは、メール本文だけでなく、アプリ側の注文状態も照合します。メールが届いても注文が未確定なら、支払い後の業務処理が正しいとは限りません。逆に注文状態が正しくても通知が送られていないなら、通知処理は未完了です。

検収結果を本番の投函結果と混同しない

テストモードで確認できるのは、テスト決済の状態、イベント処理、自社アプリの通知生成、管理された受信先でのメール内容と受信です。これらの成功から、本番環境での迷惑メール判定や実際の投函まで推定することはできません。本番の受信性を確認する場合は、本番環境の設定と許可された検証手順を使い、テスト目的で無断の実決済を行わないでください。Stripeのテストに使う支払い方法と実カード情報に関する案内も事前に確認しましょう。

判断に迷ったら、次の条件で進めます。

• テストしたいのがStripe自身の領収書で、対象のメールがテストモードでは送信されない仕様なら、未着を障害判定に使わず、決済状態とイベントを確認します。
• テストしたいのが自社の支払い通知なら、自社のWebhook処理と送信記録を追い、テスト受信アドレスで内容と受信を確認します。
• 本番の投函品質を確認したいなら、テストモードの結果を合格根拠にせず、許可された本番検証を別に計画します。
• 銀行、決済、行政など、長期的な受信やアカウント復旧が必要な宛先には、一時的な受信先を使わず、管理可能なメールアドレスを選びます。

自社通知の検証だけなら、テスト受信アドレスを使うと個人の主メールにテストデータを残さずに済みます。短期の登録や通知確認にMsgMaskを使う場合は、実行前に現在の利用条件と受信機能を確認し、Stripe自身が送らないメールまで受け取れると想定しないでください。