イベント返金の対応表を作る｜受付・決済確認・完了を分ける

返金表は決済処理の代わりではない

イベントの返金依頼をフォームで受けた時点では、お金は戻っていません。台帳に「返金済み」と入力したことも決済サービスでの完了を証明しません。今回作るのは、主催者の条件確認と決済結果の照合を漏らさないための対応表です。返金可否や金額は、販売時の条件と実際の契約に基づき担当者が確認します。説明用の架空データを使い、決済サービスへの本番操作を自動化せず、まず依頼から完了確認までを見通せる状態にします。

申込み・決済・返金のIDを別々に残す

申込IDに加え、決済サービス名、決済ID、返金ID、対象人数、確認した金額と通貨を記録します。１つの支払に複数の参加者が含まれる場合や、一部だけを返す場合に、人数と金額を混同しないためです。金額を入力欄から受け取ってそのまま処理せず、元の決済を参照して確認します。カード番号などの決済情報を台帳に複製する必要はありません。問い合わせ内容と決済管理の権限を分け、受付担当者が必要以上の情報を持たない構成にします。

状態を依頼と結果に分ける

依頼側は受付、内容確認中、承認、見送りに分け、決済側は未操作、結果待ち、完了確認、要対応など別の列にします。Stripeには返金の状態や更新イベントがあるため、作成されたことと成功したことを同一視しません。実際の状態値を保存する場合はサービスの値をそのまま残し、内部の表示名へ対応付けます。承認者、操作担当、照合担当が同じでも、各日時を分けると途中で止まった場所が分かります。状態が不明なら完了扱いにせず、調査中として残してください。

重複依頼では新しい返金を作らない

同じ参加者がフォームとメールの両方から依頼したら、元の申込IDと決済IDで既存の対応を探します。既に結果待ちの返金がある場合はその状況を確認し、新しい処理を追加しません。処理中に通信が切れて結果が分からなくなった場合も、操作履歴と返金IDを調べてから判断します。Makeなどで通知を連携するなら、同じイベントの再送が台帳の重複行や別の決済操作につながらないようにします。担当者通知の自動化と、返金実行の権限は切り離してください。

参加者への案内は確認済みの範囲で書く

依頼を受け付けた案内には確認予定と窓口、承認後の案内には処理状況を示します。返金完了を確認できた場合も、参加者の口座や明細への反映時期を台帳だけで保証しないようにします。処理の所要期間は決済方法やサービスによって異なるため、必要な案内は現在の公式情報と照合します。失敗が判明した場合は要対応へ戻し、代替の対応を担当者が確認します。個人情報を含む決済画面の画像を、共有名簿や一般的なチャットへ添付しない運用にします。

件数が少ない場合の道具と費用

数件の返金なら、決済サービスの管理画面と既存の管理表を使い、週次または開催後に照合する方法から始められます。Airtableの自動化やMakeは依頼登録、担当者通知、未確認の抽出を助けますが、追加しただけで返金処理の正確性が保証されるわけではありません。サービス費用と、返金や決済に伴う費用は別々に確認します。返金時の手数料の扱いを一律に決めつけず、契約と現在の決済条件を見てください。自動化より先に、誰が金額を承認できるかを明確にします。

確認するケースと完了の条件

架空の決済IDで、全額、一部、対象不明、二重依頼、操作後の結果不明、失敗、通貨違いを台帳上で試します。本番の返金を発生させずに、状態の遷移と確認担当への通知を点検してください。完了の条件は対象申込み、承認金額、決済サービスの最終結果、参加者への案内が照合できたことです。申込み受付、Stripeのテストイベント記録、重複防止の記事も合わせて参照すると、受付から決済結果までの境界を分けたまま設計できます。

• MakeとStripeを連携する方法｜テスト決済イベントを表へ記録する
• Tallyで講座の参加申込みを受け付ける｜希望回・人数・受付後の確認
• Makeの重複登録を防ぐ｜受付ID・Data store・再実行の設計