「キャンセルが多くて困っている」という話を聞いたのは、予約システムを公開して少し経った頃だった。予約は来る。しかし当日になって連絡なしでキャンセルになることがある。
前払い制にすれば減る。払ったお金は戻りにくいからだ。
「決済を入れましょう」という話をオーナーと始めた。
最初に聞くべきことを聞いた
決済を実装すると決まったとき、コードを書く前に確認すべきことがある。
「誰が決済を受け取るのか」だ。
オーナーのサービスの売上は、オーナーに入らなければならない。私のStripeアカウントを使って決済を受け取り、後から送金するという方法は、実務上も会計上も、そしてStripeの規約上も問題がある。
したがって、オーナー自身がStripeアカウントを開設する必要がある。個人事業主として本人確認を行えば、開設できる。
アカウントの開設をお願いして、待つことにした。
Stripe Payment Linksという機能
Stripeには「Payment Links」という機能がある。Stripeのダッシュボード上で商品名と金額を設定すると、決済専用のURLが生成される。そのURLにアクセスしたお客さんは、Stripeが提供するホスト型の決済ページでカード情報を入力して支払いを完了できる。
開発者がコードを書く必要がない。オーナーが自分でダッシュボードを操作してURLを生成できる。サービスが増えたときも自分で追加できる。
技術的な複雑さを最小化する選択だ。
前払いか後払いか
決済フローは2つ考えた。
前払い型は「決済→予約確定」の順序だ。お客さんが料金を払ったことをシステムが確認してから、予約を確定させる。払われなければ予約が完了しない。当日キャンセルのリスクを最も減らせる設計だが、StripeのWebhookをGASが受け取る仕組みが必要になり、実装が複雑になる。
後払い型は「予約→決済リンク送信」の順序だ。予約が確定した後、GASがLINEでPayment Linkを送る。シンプルだが、払われないまま予約枠が埋まるリスクが残る。
どちらが良いかは、オーナーのお客さんの性質にも依存する。信頼関係が先にある顧客層なら後払いでも機能するかもしれない。新規顧客が多いなら前払いの方が安全だ。
この判断は、オーナーのStripeアカウント開設後に一緒に話し合いながら決める。
決済がないサービスをどう扱うか
予約システムのサービスの中に「暮らしの作戦会議（無料相談）」がある。60分・無料だ。
このサービスには決済フローを通す必要がない。むしろ「無料なのに支払い画面が出てくる」という体験は混乱を生む。
設計としては、service_idごとに「決済あり・なし」フラグを持たせる。決済ありのサービスだけ、予約確定後にPayment Linkを送るロジックに分岐する。
const requiresPayment = { '1': false, '2': true, '3': true, '4': true, '5': true, '6': true };この1行を追加するだけで、無料相談の予約フローからは決済のステップが消える。
いま何も実装していない理由
この記事を書いている時点で、Stripe決済は未実装だ。オーナーのStripeアカウント開設が完了してから実装を始める。
システムは早く作るより、正しい順序で作る方が良いことがある。決済に関してはとりわけそうだ。誰かのお金の流れに関与するとき、「とりあえず動く」より「誰が何を受け取るか」を最初に決めることが重要だ。
それが決まれば、コードは後からついてくる。
*次回は「予約システムの本番運用から見えてきたもの」*
*シンプルシステム株式会社 代表 伊藤勝彦*