Stripe領収書を自動で送りたいなら、最初に必要な書類を決めます。一般消費者への支払い確認と、事業者への請求書では設定が違います。
メールを有効にするだけで済む場合もあります。取引先が適格請求書を求めるなら、請求書PDFまで設計する必要があります。
Stripe領収書と請求書PDFの違い
決済後に渡せる書類は一種類ではありません。用途を分けると、過剰な開発や問い合わせを減らせます。
- 通常のメール領収書
決済成功後に閲覧リンクをメールで届けます。リンク先は返金後の状態も反映します。 - 支払い済み請求書
商品明細や税の情報を含むPDFを渡せます。継続課金では請求書が自動で作られます。 - 独自の支払い明細
自社メールや会員画面へ情報を表示します。Webhookとデータ保存の実装が必要です。
少額の個人向け販売なら、通常の領収書で足りることがあります。法人取引や経理提出では、請求書PDFの要否を先に聞くと安全です。
領収書の現行仕様と費用
2026年8月26日にStripe公式情報を確認しました。標準決済の料金と、書類の扱いは分けて把握します。
- 国内カードの決済手数料
標準料金は決済成功一件あたり3.6％です。初期費用と月額料金はありません。 - メール送信の条件
成功した支払いの顧客メールを有効にします。購入者のメールアドレス取得も欠かせません。 - 閲覧リンクの有効性
通常の領収書はブラウザー表示向けです。リンクは30日以内に期限切れとなります。 - 支払い済み請求書
一回払いは作成設定を明示的に有効化します。完了後のメールからPDFへ進めます。
領収書メール自体を送るための月額契約は不要です。請求書や税計算などの追加製品は、利用前に料金を確認してください。
領収書の判断表
顧客が欲しい書類と、販売側が残したい記録を照合します。次の四つから最も近い運用を選びます。
- 個人向けの単発販売
通常の領収書メールから始めやすい形です。商品名と連絡先が伝わる状態に整えます。 - 法人向けの単発販売
請求書PDFの作成を候補にします。宛名や税情報を事前に集める設計が必要です。 - 月額サービスの継続課金
請求書と支払い記録を顧客単位で管理します。解約や返金の履歴も同じ流れにまとめます。 - 自社会員画面での再表示
APIから閲覧用URLを取得する構成です。期限切れ時の再送導線も用意します。
迷う場合は、購入者が経費精算へ出すかを確認します。提出先の要件が、書類選びの基準になります。
決済後メールを整える設定手順
まずテスト環境で購入から受信までを通します。本番決済の前に、表示内容と再送方法を確認します。
- 公開事業情報を登録する
事業者名と問い合わせ先を正しく設定します。購入者が支払先を識別できる表記にします。 - ブランド設定を整える
色や公開情報を確認して送信元を明確にします。装飾よりも事業者の識別を優先します。 - 顧客メールを有効にする
成功した支払いのメール送信をオンにします。返金メールが必要なら同時に方針を決めます。 - メールアドレスを取得する
Payment LinksやCheckoutで入力を受け取ります。誤入力に備えて再送窓口も案内します。 - テスト決済で内容を読む
購入者側の受信箱で文面を確認します。商品説明や問い合わせ先の不足を直します。
設定画面を見ただけでは受信状態まで分かりません。実際のメールとリンク先を一組として点検します。
領収書を自動送信する場合
Stripe領収書を使う場合は、成功した支払いのメールを有効にします。購入者が入力したメールへ閲覧リンクが届きます。
返金時は同じ宛先へ返金通知も送れます。支払い画面の説明欄には、提供内容や解約条件を簡潔に入れます。
請求書PDFも渡す場合
Payment Linksの支払い後設定で、請求書PDFの作成を選びます。一回払いでは自動作成が既定ではありません。
メールにはPDFと領収書へのリンクが届きます。メモ、フッター、税番号は請求書テンプレートで整えます。
支払い明細が向く条件と向かない条件
標準機能は短期間で始めたい事業に向きます。独自帳票が必要な場合は、別の構成を検討します。
- 向く条件：商品数が少ない
決済リンクごとに内容を管理しやすい状態です。少人数でもメール対応を標準化できます。 - 向く条件：再送を手動で支えられる
問い合わせ時にダッシュボードから再送できます。月数件なら運用負担を抑えられます。 - 向かない条件：独自様式が必須
社内指定の帳票レイアウトには合わない場合があります。会計システムとの連携を検討します。 - 向かない条件：複数サービスを横断する
現金や振込の記録は別に残ります。帳簿側で通し番号を管理する設計が必要です。
Stripe内で完結する取引だけなら、標準機能が扱いやすい選択です。販売経路が増えるほど、会計側の一元管理が重要になります。
請求書PDFとインボイス制度の注意
Stripeが書類を作ることと、法令要件を満たすことは同じではありません。販売者が必要項目を確認する責任を持ちます。
- 登録番号を確認する
適格請求書発行事業者は登録番号を設定します。対象外なら誤解を招く表示を避けます。 - 税率別の金額を整える
適用税率と税率ごとの消費税額を確認します。商品側の税設定も書類へ影響します。 - 宛名と取引内容を残す
顧客名や提供日、商品内容を追える形にします。決済の表示名だけで判断しない運用にします。 - 専門判断を切り分ける
具体的な税務処理は税理士へ確認します。決済サービスの設定だけで適法性を断定しません。
Stripe領収書だけでは、取引先の保存要件に足りない場合があります。法人向け販売では、受領側の経理条件も確認してください。
領収書発行の実装チェックリスト
公開前に購入者側と運営側の両方を点検します。テスト結果は日時と決済経路を添えて残します。
- 事業者情報を識別できる
名称と問い合わせ先が正しく表示されます。カード明細の表記も購入者へ案内します。 - 商品内容が分かる
何への支払いかを文面で確認できます。曖昧な商品名は問い合わせの原因になります。 - メールを実際に受信できる
迷惑メールフォルダーまで確認します。受信できない時の再送手順も決めます。 - 返金後の表示を確認する
返金通知とリンク先の状態を点検します。部分返金も想定して記録を残します。 - PDFの税項目を照合する
登録番号と税率別金額を読み合わせます。不明点は公開前に専門家へ相談します。
一度の成功だけで運用を確定しないことが大切です。商品追加や税設定変更の後も、同じ手順で再確認します。
領収書の確認に使った公式情報
以下は2026年8月26日に確認した一次情報です。料金や画面は変更されるため、導入時にも再確認してください。
- Stripe「領収書と支払い済み請求書」
自動送信と再送、閲覧リンクの仕様を確認しました。返金時の表示更新も参照しました。 - Stripe「Payment Linksの支払い後」
メール領収書と請求書PDFの設定を確認しました。一回払いでの請求書作成条件も参照しました。 - Stripe「請求書をカスタマイズ」
公開情報と税番号、メモの設定を確認しました。地域要件は販売者が確認する点も参照しました。 - Stripe「日本の適格請求書制度」
登録番号と税率別税額の項目を確認しました。Billingとの連携方針も参照しました。 - Stripe「料金体系」
国内カードの標準手数料を確認しました。初期費用と月額料金の扱いも参照しました。
記事ではAIを調査と構成の補助に使いました。公開前の内容は人が確認する運用方針です。
領収書設計で迷った時の相談先
メール領収書と請求書PDFの選択は、顧客属性で変わります。Literamentでは決済からメール、会計連携まで整理します。