Thanks Mail for Stripe 導入ガイド｜Stripe Payment Linksの決済後にサンクスメールを自動送信

WordPress.org：Thanks Mail for Stripe（無料 / GPLv2ライセンス / 日本語対応）

Stripe Payment Linksで商品やサービスを販売していると、決済後に「ご購入ありがとうございます」というメールを送りたくなります。

ただ、実際にやろうとすると、これが意外と面倒です。Stripeの標準メールは領収書としては便利ですが、自分のブランド名で、購入者に合わせた案内を送るには少し物足りません。ダウンロードリンクを入れたい。次の手順を案内したい。日本語の購入者には日本語、英語の購入者には英語で送りたい。そう考え始めると、単なる「決済完了メール」では足りなくなります。

最初に思いつくのは、ZapierやMakeのような自動化サービスです。もちろん、それで組める場面もあります。ただ、毎月の利用料、タスク数の上限、外部サービス側の停止、メール配信の安定性を考えると、「サンクスメール1通のために、ここまで外に依存する必要があるのだろうか」と感じました。

そこで作ったのが、Thanks Mail for Stripeです。Stripe Payment Linksの決済完了をWebhookで受け取り、WordPress側からサンクスメールを送るだけの小さなプラグインです。

この記事では、公式プラグインページのような機能の網羅ではなく、実際に導入する人が迷いやすい順番で書いていきます。なぜ作ったのか、どういう仕組みで動くのか、Stripe側で何を設定するのか、メールが届かないときはどこを見るのか。本番公開前に確認しておきたいところまで、自分が触ってきた感覚に近いところでまとめています。

このプラグインが向いている人

Thanks Mail for Stripeは、Stripe Payment Linksを使っている人向けに作っています。WooCommerceの注文メールを置き換えるものではなく、あくまでスタンドアロン決済の後のサンクスメールに集中したプラグインです。

たとえば、Stripe Payment Linksでデジタル商品を販売していて、決済後にダウンロード案内や利用開始の手順を送りたい。Stripeの領収書ではなく、自分のブランド名で「ありがとうございます」を伝えたい。ZapierやMakeを使わずに、WordPress内で完結させたい。日本語用と英語用でテンプレートを使い分けたい。サービス予約や寄付の後に、簡単な確認メールを送りたい。こうした用途に向いています。

逆に、WooCommerceで本格的なECサイトを運営している場合は、WooCommerce標準の注文メール機能を使うほうが自然です。Thanks Mail for Stripeは、その代わりに使うものではありません。

サンクスメール送信方法の比較表（Zapier / Make / Thanks Mail for Stripe）

なぜ作ったのか：メール1通を、できるだけシンプルに送りたかった

きっかけは、自分のデジタル商品をStripe Payment Linksで販売し始めたことでした。

StripeのPayment Linksはとても便利です。商品ページを作り込みすぎなくても、Stripe側で決済リンクを作り、サイトやメールに貼れば販売を始められます。小さなデジタル商品や単発サービスにはかなり相性がいいです。

ただ、購入後のフォローで困りました。

Stripeの領収書メールは送れます。でも、領収書は領収書です。「ご購入ありがとうございます。こちらからダウンロードしてください」「設定手順はこちらです」「不明点があればこのメールに返信してください」といった、自分のサービスに合わせた案内とは少し違います。

Zapierで「Stripe → Gmail」を組む方法もあります。Makeでシナリオを作る方法もあります。けれど、メール1通のために外部サービスを通すと、管理する場所が増えます。無料枠やタスク数も気になります。なにより、フローが止まったときに気づきにくいのが怖いところです。

それなら、StripeからWordPressへWebhookを送ってもらい、WordPress側でメールを送ればいい。そう考えて作り始めました。

このプラグインは、多機能なメールマーケティングツールではありません。ステップメールも、会員管理も、CRM連携もありません。目的は、Stripe Payment Linksで決済が完了したら、購入者にサンクスメールを送ることです。あえてそこに絞っています。

仕組み：Stripe WebhookをWordPressで受け取る

仕組みは、できるだけ単純にしました。流れは次のようになっています。

1. お客さんがStripe Payment Linkで決済する
2. Stripeが決済完了イベントをWebhookでWordPressへ送る
3. プラグインがWebhook署名を検証する
4. Payment Link IDやlocaleからテンプレートを判定する
5. WordPressのメール送信機能でサンクスメールを送る
6. Checkout Session IDを保存して、同じ決済への二重送信を防ぐ

ここで大事にしたのは、StripeとWordPressの間にZapierやMakeを挟まないことです。もちろん外部自動化サービスには外部自動化サービスの良さがあります。ただ、この用途では「Stripeから来た通知を受けてメールを送る」だけなので、経路が短いほうが管理しやすいと考えました。

動作フロー図（お客さん→Stripe→WordPress→メール送信）

本番運用で気をつけたいこと

サンクスメール自体はシンプルな機能です。ただ、決済後のメールなので、軽く扱うとトラブルになります。実際に開発しながら「ここは外せない」と感じたところを、いくつか書いておきます。

Webhookは必ず署名検証する

Webhook URLは外部からアクセスできる場所にあります。そのため、「Stripeから来たリクエストかどうか」を確認する必要があります。

Thanks Mail for Stripeでは、Stripeの署名シークレットを使ってWebhook署名を検証しています。署名が正しくないリクエストは処理しません。決済系のプラグインではここがかなり重要なので、最初から組み込んでいます。

同じ決済で二重送信しない

StripeのWebhookは、ネットワークの遅延や一時的な失敗があると再送されることがあります。これはStripe側の正常な仕組みです。

これは机上の話ではなく、開発中に実際に何度か遭遇しました。テストモードでWebhookを投げて動作確認していたら、同じCheckout Sessionに対してメールが2通、3通と届いてしまったんですよね。プラグイン側で対策していないと、本番でも同じことが起きます。購入直後に同じメールが何通も届くのは、購入者にとってかなり印象が悪い。

そこで、Checkout Session IDをデータベースに記録して、すでに処理済みの決済ならメールを再送しないようにしました。テストでメールが二重に届いたあの瞬間が、この実装を組み込むきっかけになっています。

メールのFromは独自ドメインにする

これは本当に大事です。送信元メールアドレスにGmailやYahooメールを設定すると、メールが届かない原因になります。

WordPressサーバーからGmailアドレスを名乗って送ると、受信側は「このサーバーはGmailの送信元として許可されていない」と判断します。SPF、DKIM、DMARCのチェックで弾かれやすくなります。

Fromには、必ず自分のドメインのメールアドレスを使ってください。たとえば info@example.com や support@example.com のような形です。Gmailを使いたい場合は、Reply-Toに設定するほうが安全です。

NG（Gmail）vs OK（自ドメイン）の比較図

インストール方法

インストールは、通常のWordPressプラグインと同じ流れです。管理画面から検索して入れられます。

プラグインの新規追加画面を開く

WordPress管理画面の左メニューから「プラグイン」→「新規プラグインを追加」をクリックします。

管理画面の左メニュー「プラグイン」→「新規プラグインを追加」

Thanks Mail for Stripeを検索する

検索欄に「Thanks Mail for Stripe」と入力します。検索結果に表示されたら、作者名が「rapls」であることを確認してください。

検索欄に「Thanks Mail for Stripe」と入力した状態。作者名「rapls」のプラグインが表示される

検索で見つからない場合は、「Thanks Mail Stripe」のように少し短いキーワードでも試してみてください。

インストールして有効化する

「今すぐインストール」をクリックし、完了後に「有効化」をクリックします。

「今すぐインストール」をクリック。数秒でインストールが完了する

設定画面を開く

有効化後、プラグイン一覧の「Thanks Mail for Stripe」に「設定」リンクが表示されます。ここから設定画面へ移動できます。

有効化後のプラグイン一覧。「設定」リンクからすぐに設定画面に移動できる

Stripe側でWebhookを登録する

プラグインを入れただけでは、まだメールは送られません。StripeからWordPressへ決済完了イベントを送ってもらう必要があります。

StripeダッシュボードでWebhookエンドポイントを作成します。

Webhook登録の概要図

登録するWebhook URL

Webhook URLは、基本的にこの形になります。

必ずHTTPSのURLを使います。Stripe Webhookは決済に関わる通信なので、SSL証明書がないサイトでは本番運用しないほうが安全です。

選択するイベント

Stripe側で選ぶイベントは、主に2つあります。

• checkout.session.completed
• checkout.session.async_payment_succeeded

通常のカード決済では checkout.session.completed が中心になります。非同期決済を使う場合は、checkout.session.async_payment_succeeded も確認しておきます。

Stripeダッシュボードの Developers → Webhooks 画面

Add endpointでURL入力＋イベント選択している画面

Signing secretをコピーする

Webhookを作成すると、whsec_... で始まるSigning secretが表示されます。これをWordPress側のプラグイン設定へ貼り付けます。

この値はパスワードのようなものです。ブログ記事、スクリーンショット、GitHub、問い合わせフォームなどに公開しないでください。

Signing secret（whsec_…）が表示されている画面

WordPress側の設定

次に、WordPress管理画面の「設定」→「Thanks Mail for Stripe」を開きます。

プラグインの設定画面全体

Webhook署名シークレット

Stripeでコピーした whsec_... を貼り付けます。テストモードと本番モードでは、この値が別です。本番切り替え時に、テスト用のまま残さないよう注意してください。

ブランド名

メール本文内の {brand} に入る名前です。サービス名、ショップ名、サイト名など、購入者に伝わりやすい名前を入れます。

送信元メールアドレス

ここは独自ドメインのメールアドレスを入れます。GmailやYahooメールをFromにするのは避けてください。

たとえば、サイトが example.com なら、info@example.com や support@example.com のようなアドレスが向いています。

返信先メールアドレス

返信先はGmailなどでも構いません。Fromは独自ドメイン、Reply-Toは普段確認しやすいメールアドレス、という分け方ができます。

メールテンプレートを設定する

v1.1.0から、メールテンプレートを最大10個まで動的に追加・削除できるようになりました。

初期バージョンではテンプレート数を固定にしていました。ただ、自分で使っているうちに足りないと感じる場面が出てきました。Payment Linkを増やすたびにテンプレートも増やしたい、日本語と英語で分けたい、商品ジャンルごとにメール文面を切り替えたい——そう考えていくと、固定の数では足りなかったんですね。

そこで、v1.1.0から1〜10個まで自由に増減できる仕組みに作り変えました。たとえば、日本語商品用、英語商品用、デジタル商品用、サービス予約用、寄付用のように、Payment Linkごとにメール内容を変えられます。

テンプレート編集画面。各テンプレートに名前・locale・Payment Link ID・件名・本文を個別設定できる

テンプレートで設定する内容

テンプレートを作るときは、長文にしすぎないほうが読みやすいです。決済直後のメールなので、まずは「購入のお礼」「購入内容に関する案内」「困ったときの連絡先」を分かりやすく書くのがおすすめです。

使えるプレースホルダー

メール本文で使えるプレースホルダーは、こんな感じです。

• {brand}：設定したブランド名
• {email}：購入者のメールアドレス
• {session_id}：Stripe Checkout Session ID

{session_id} は、お問い合わせ時の照合に便利です。ただし、購入者にとっては見慣れない文字列なので、本文に入れる場合は「お問い合わせ時の確認番号」のように説明を添えると親切です。

テストメールで先に確認する

本番決済の前に、まずテストメールを送ってみるのがおすすめです。

テストメールが届かない状態でStripe決済のテストに進むと、メールが届かなかったときに「Stripeの問題なのか、メール送信環境の問題なのか」が切り分けにくくなります。先にWordPressからメールが送れるかどうかだけ確認しておくと、後の検証がぐっとラクになります。

テストメール送信ボタンと「送信成功」の表示

テストメールが実際に届いた受信箱

テストメールが届かない場合は、Stripeではなくメール送信環境の問題です。Fromアドレス、迷惑メールフォルダ、SMTP設定を確認してください。

Stripeのテスト決済で確認する

テストメールが届いたら、次はStripeのテストモードで実際の決済フローを通します。流れはおおよそこんな感じです。

1. Stripeをテストモードに切り替える
2. テストモード用のPayment Linkを用意する
3. テストモード用のWebhookを登録する
4. テスト用のSigning secretをプラグインに設定する
5. Stripeのテストカードで決済してみる
6. StripeのWebhookログで200レスポンスを確認する
7. WordPress側の「最近の送信履歴」も確認する
8. 実際にメールが届いているかを目視で確認する

ここまでテストモードで通ったら、本番モードでも同じようにWebhookとPayment Link IDを設定します。一番やりがちなミスは、テスト用の whsec_... や plink_... を本番に貼ったまま忘れてしまうことです。テストと本番は別物として扱ってください。

XserverでWebhookが403になる場合

開発中につまずいたのが、XserverでのWebhook 403エラーです。2026年1月頃、テストモードでWebhookを設定して動作確認していたら、StripeダッシュボードのWebhookログがすべて403で失敗していました。

403というステータスコードを見た時点で、コードのバグというより「サーバーかセキュリティ系で何かが弾いている」のはほぼ確信していました。なので、Xserverのサーバーパネルにある各種セキュリティ設定と、WordPress側のセキュリティプラグインを、ひとつずつオン/オフしながら切り分けていきました。

そうやって辿り着いたのが、Xserverの「REST APIアクセス制限」でした。これが有効になっていると、海外IPからのREST APIアクセスがブロックされる場合があります。StripeのWebhookは海外のサーバーから飛んでくるので、ここでブロックされていたわけです。

トラブルシューティング・フローチャート

Xserverサーバーパネルの「REST APIアクセス制限」設定画面

対処としては、Xserverのサーバーパネルで該当サイトのWordPressセキュリティ設定を開き、REST APIアクセス制限をOFFにします。

ただし、セキュリティ設定を変える作業なので、必要な範囲を理解したうえで行ってください。Wordfenceなどのセキュリティプラグインを使っている場合は、Webhook URLを許可リストに追加する方法も検討します。

Webhookは200なのにメールが届かない場合

StripeのWebhookログでは200 OKになっているのに、メールが届かないことがあります。この場合、Webhook受信自体は成功している可能性が高いです。

Stripeダッシュボードの Webhook ログ画面（200 OK + sent: true の表示）

確認する順番は、だいたいこんな流れになります。

最近の送信履歴を見る

プラグインの管理画面で「最近の送信履歴」を確認します。履歴に残っていれば、プラグイン側では送信処理まで進んでいます。

Fromが独自ドメインか確認する

FromがGmailやYahooメールになっていると、受信側で弾かれることがあります。独自ドメインのメールアドレスに変更してください。

SMTPプラグインを検討する

WordPress標準の wp_mail() はサーバー環境に左右されます。私のXserver環境では、SMTPプラグインを使わずに wp_mail() の素のままで問題なくメールが届いています。これはサーバー側のメール送信環境が比較的整っているからだと思います。

ただ、環境によっては、メールが届かない、迷惑メールに振り分けられる、といった症状が出ることがあります。そのときは、WP Mail SMTP、Post SMTP、FluentSMTPなどのSMTPプラグインを使うと改善する場合があります。

データベースと送信履歴

Thanks Mail for Stripeは、送信履歴をWordPressのデータベースに保存します。これはメールの二重送信を防ぐためでもあり、管理画面で送信状況を確認するためでもあります。

データベーステーブル構造の図解

保存される主な情報は、Checkout Session ID、送信先メールアドレス、テンプレート情報、商品名、金額、送信日時などです。

これは「メールが送られたかどうか」を確認するために必要な情報ですが、購入者のメールアドレスを扱う以上、プライバシーポリシーで説明しておくべきです。特に、決済・メール送信・送信履歴の保存を行う場合は、サイト側のプライバシーポリシーに明記してください。

管理画面の「最近の送信履歴」一覧

本番公開前のチェックリスト

決済後メールは、失敗するとすぐにお客さんの不安につながります。本番公開前に、最低限ここまでは確認しておくと安心です。

このプラグインでやらないこと

誤解を避けるために、対応していない領域も書いておきます。WooCommerceの注文メールを置き換えるものではありませんし、Stripeのサブスクリプション管理ツールでもありません。ステップメールやメルマガ配信、ライセンスキーの自動発行、購入者管理CRMといった機能も持っていません。

あくまで、Stripe Payment Linksの決済完了後に、WordPressからサンクスメールを送る、その1点に絞っています。広げすぎず、決済直後のフォローに集中する。そういう作り方です。

開発者向けのカスタマイズ

メール内容をさらに細かく制御したい場合は、フィルターフックを使えます。

CCを追加する例

メールアドレスのドメインでテンプレートを切り替える例

v1.1.0から、tmfs_detect_language の戻り値は言語コードではなくテンプレートインデックスになっています。古いコードを使っている場合は注意してください。

その他のフィルターフック一覧、REST APIエンドポイント、データベース構造などの詳細は、Thanks Mail for Stripe プラグイン技術リファレンスにまとめています。本格的にカスタマイズする場合はこちらも参照してください。

WordPress.org公開時に直したこと

WordPress.orgへのプラグイン公開には、レビューチームによる審査があります。Thanks Mail for Stripeも例外ではなく、初回提出時にいくつか指摘を受けました。記事の本筋からはやや脇道ですが、これからプラグインを公開する人にも参考になりそうな部分なので、書いておきます。

主な指摘と、それに対して対応した内容を整理すると、こんな感じです。

• Plugin URI が404になっていた：プラグインヘッダーで宣言した公式ページのURLが、当時まだサイトに存在しなかったんですね。レビューチームは実際にURLを開いて確認するので、ヘッダーで宣言する以上は対応するページを公開しておく必要があります。
• プレフィックスの統一（stm_ → tmfs_）：WordPress.orgでは、プラグイン間の名前衝突を避けるため、関数名・オプション名・テーブル名などに4文字以上のユニークなプレフィックスを付けることが要求されます。最初は stm_（3文字）と tmfs_ が混在していたので、すべて tmfs_ に統一しました。
• 外部リソース（CDN）の削除：外部CDNから読み込んでいたスクリプトを、自前で同梱する形に変更（v1.0.2）。
• JavaScriptの正しいエンキュー：wp_enqueue_script() 経由で正しく登録するように修正（v1.0.2）。
• 送信失敗時の記録の扱い：メール送信に失敗したのに「送信済み」として記録してしまうバグがあったので修正（v1.0.1）。
• Webhookのレート制限とメールアドレス検証：セキュリティ強化のため、Webhookエンドポイントへのレート制限と、送信先メールアドレスの妥当性チェックを追加（v1.0.1）。

初回提出で全部一発OKになるプラグインは、たぶん少ないと思います。レビューチームのメッセージは具体的なので、指摘どおりに直して再提出すれば、たいていは通ります。むしろ「公式に通すための最低ライン」を学べる場として、ありがたい仕組みだなと感じました。

更新履歴を読むときの見方

このプラグインは、サンクスメール自動送信というひとつの用途に絞って開発しています。更新履歴を見るときは、新機能だけでなく、WordPress.org公開に必要な命名規則、外部リソース削除、レート制限、メール送信失敗時の扱いなども確認しておくと安心です。

特にv1.1.0では、テンプレートを1〜10個まで動的に追加・削除できるようになり、Payment Link IDごとのテンプレート判定が使いやすくなりました。複数商品や複数言語で運用する場合は、v1.1.0以降を前提に設定したほうがよいです。

最後に

大きなECサイトなら、WooCommerceや専用の販売システムを使う選択肢があります。ただ、小さなデジタル商品、単発サービス、寄付、予約確認のような用途では、Stripe Payment Linksだけで十分なこともあります。そのときに足りなくなりやすいのが、購入後の「ひとこと」だなと、自分で販売してみて気づきました。

「ご購入ありがとうございます」「こちらからダウンロードしてください」「困ったらこのメールに返信してください」。このメールが届くかどうかで、購入者の安心感はかなり変わります。Thanks Mail for Stripeは、その1通をWordPressだけで送るためのプラグインです。Webhook、署名検証、二重送信防止、テンプレート切り替え、送信履歴など、本番運用で必要になりそうな部分はできるだけシンプルにまとめてあります。

まずはテストモードでWebhookを設定して、テストメールが届くところまで確認してみてください。そこまで動けば、本番運用への不安はだいぶ減るはずです。

バグ報告や機能リクエストはWordPress.orgのサポートフォーラムからお願いします。使ってみての感想なども、こちらで受け付けています。

Rapls works のその他のプラグイン

• Rapls AI Chatbot ガイド｜WordPress AIチャットボットの導入から運用まで ── WordPress に AI チャットボットを設置できるプラグイン。
• Rapls PDF Image Creator｜WordPress PDFサムネイル生成プラグイン ── PDF をアップロードすると、自動でサムネイル画像を生成するプラグイン。