宿泊予約のStripe決済設計 — 予約時に課金しないという選択

はじめに

ネットショップの決済は分かりやすい設計です。カートに入れて、カードで払って、商品が届く。ところが宿泊予約になると、話が一気に難しくなります。

泊まるのは半年先かもしれません。キャンセル料は日程が近づくにつれて段階的に発生します。「いつ、いくら請求するのか」を決めるだけで、何日も検討することになりました。この記事では、その検討の結果たどり着いた決済設計の全体像を紹介します。

宿泊予約の決済が難しい理由

「今すぐ全額」では予約が入らない

もっとも単純なのは、予約時に全額をカードで決済してしまう方法です。実装も簡単で、取りっぱぐれもありません。

しかし1年近く先の宿泊に対して、今日30万円を引き落とされることに抵抗を感じる方は多いはずです。予約のハードルが上がり、他のOTAで予約されてしまいます。宿側としても、キャンセルのたびに返金作業が発生します。

かといって「当日払い」にもできない

逆に何も取らずに予約を受けると、無断キャンセルのリスクを丸抱えすることになります。一棟貸しは1件あたりの金額が大きいので、繁忙期の無断キャンセル1件のダメージは深刻です。

検討して見送った案

「与信だけ確保」がなぜできなかったのか

クレジットカードには「与信（オーソリ）」という仕組みがあります。カードの利用枠だけを押さえておき、後から実際に請求する方法です。ホテルの保証金などでよく使われます。

これが使えれば理想的でした。しかし調べていくと、決定的な制約に突き当たりました。

この宿は365日先まで予約を受け付けます。与信が最長30日しか持たないなら、予約時に押さえた与信を14日前まで保持することは原理的に不可能でした。ここで与信案は完全に消えました。

前金・分割払いも見送った

「予約時に3割、直前に7割」という分割案も検討しましたが、2回の決済失敗リスクを抱えることになり、運用も複雑になります。一棟貸しで予約件数がそれほど多くないことを踏まえ、シンプルさを優先しました。

採用した設計：カード登録と後日自動課金

予約時にすることは「カードを預かる」だけ

最終的に選んだのは、予約時にはカードを登録するだけで課金せず、チェックイン14日前に自動で請求する方式です。

課金日をキャンセル料の発生日と一致させたことで、運用が明快になりました。課金日より前のキャンセルは「請求なし」、それ以降は「返金」で処理できます。「まだ請求していない状態でキャンセル料だけ請求する」という面倒な場面が発生しません。

本人認証を予約時に済ませておく

後日、お客様が画面の前にいない状態で請求する場合、カード会社によっては本人確認ができずに決済が拒否されることがあります。

そこで予約時のカード登録の段階で、本人認証（3Dセキュア）を必ず通す設定にしました。これにより「お客様の同意を得た上での継続的な請求」として扱われ、後日の自動課金がスムーズに通ります。

同意を記録に残す

「14日前に自動で請求されること」は、予約時にお客様へ明示し、チェックボックスで同意をいただいています。この同意は、いつ・どの版の文言に対して行われたかまでデータベースに記録しました。

後から「そんな説明は受けていない」となったときに、記録があるかどうかで話がまったく変わってきます。

3つのサブテーマ

決済設計は範囲が広いため、詳細は3本の記事に分けています。

• 課金タイミングの詳細 — なぜ与信ではなくカード登録なのか、自動課金はどう動くのかは「決済保留の正体」で解説します
• 状態管理 — 決済画面から戻ってきたことをどう扱うか、通知の重複をどう防ぐかは「Webhookとステータス管理で作る壊れない決済フロー」で解説します
• セキュリティ — 金額の改ざん防止、二重課金の防止、本番とテストの分離は「価格改ざん・二重課金を防ぐ決済セキュリティ」で解説します

まとめ

宿泊予約の決済設計で軸にしたのは、次の3点です。

1. 課金日をキャンセル料の発生日に合わせる — 運用が「請求なし」か「返金」の2択になり、単純になる
2. 与信ではなくカード登録を選ぶ — 与信には期限があり、遠い日程の予約には使えない
3. 同意を記録に残す — 後日課金の説明と同意を、文言の版まで含めて保存する