処理の流れと項目の対応
- テストイベント
- イベントIDを照合
- イベント台帳へ保存
- 元イベントと照合
実際の請求や返金を作る構成ではありません。受信成功と台帳保存の完了は別に確認します。
| 項目 | 用途・保存先 |
|---|---|
| event.id | 同じイベントの再配信を識別 |
| data.object.id | 対象の決済などを識別 |
| amount / currency / livemode | 元の金額・通貨・環境を保持 |
実際の請求を作らない練習構成にする
対象はStripeのテスト環境で発生したpayment_intent.succeededなどのイベントを管理表へ保存する流れです。請求、返金、送金を実行するモジュールは使いません。本番とテストの接続に分かる名前を付け、保存先も分離します。実際のお金を動かさずに、受信から記録までを確かめるための構成例です。
テスト用接続とトリガーを選ぶ
MakeのStripe接続ではAPIキーまたはOAuthが案内されています。テスト環境と利用するモジュールで必要な権限を確認し、秘密鍵を表や説明文へ貼り付けないようにします。イベントを受け取るトリガーで必要な種類だけを選び、送信先を増やす前に接続先アカウントと環境を照合します。
イベントIDと決済IDを別々に保存する
event.idは届いたイベントの識別子、data.object.idは対象オブジェクトの識別子です。同じイベントの再配信と、同じ決済に関する別イベントを区別するため両方を記録します。最低限、event_id、event_type、object_id、created、livemode、amount、currencyを保存します。顧客情報を必要以上に転記しない構成にします。
通貨と金額の単位を確認する
金額を表示用へ直す場合は対象フィールドと通貨の最小単位を確認します。すべての通貨を100で割る方法は使えません。元の整数値と通貨を保持し、表示用の値は別列に作ります。payment_intent.succeededの記録は会計上の売上確定や銀行への入金をそのまま意味しないため、目的を「イベント台帳」に限定します。
同じイベントを二回保存しない
保存済みevent_idを確認し、同じIDの再配信では新規行を増やさないようにします。検索後の追加だけでは同時到着に弱いため、入口の直列化や一意性を保証する保存先を検討します。Stripeでは順序通りに届く前提を置けません。順番に依存する状態更新が必要なら現在のオブジェクトを照会し、イベント台帳と分けます。
テストイベントと保存内容を照合する
Stripe側で用意したテストイベントのIDを控え、Makeの実行履歴、保存先の行と比較します。同じイベントの再配信、別イベント、書き込み権限の不足を試してください。受信が成功しても表への保存が失敗する場合があるため、イベントの配信状態だけで業務処理の完了とは判断しません。
復旧と本番への移行を別作業にする
保存先に行があるのにMakeが失敗と表示する場合は、保存後の処理で止まった可能性を調べます。event_idから既存行を確認してから再実行してください。本番へ移すときは接続、対象イベント、権限、保存先、通知先を再確認し、テスト鍵を本番鍵へ機械的に置き換えるだけで済ませません。Makeの利用量は受信・検索・保存・再試行で確認します。
Makeで小さな自動化から始める
まず練習用データで必要な処理を確認し、利用量と機能に合うプランを選んでください。登録時の料金・特典・適用条件は公式画面で確認できます。
Make公式サイトで登録する広告リンク利用量から費用を確かめる
月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。
費用を試算する参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- Stripe connections and modules — Make情報確認日: 2026-10-30
- Handle duplicate events — Stripe情報確認日: 2026-10-30
- Make pricing — Core at 10,000 monthly credits情報確認日: 2026-10-28
- Make credits情報確認日: 2026-10-26
- Make scenario settings情報確認日: 2026-10-26
