###### tags: `設計`

# 後払い仕様

予約----N分前--(支払、キャンセル可能)--M分前--(支払可能、キャンセル不能)----セッション開始

- NとMの差は10分くらい
- NoShowは電話番号でブラックリストとか(いずれ)

## 支払い方式
- 通常便 現金
- 通常便 チケット
- 通常便 クレジット
- お得便 現金
- お得便 チケット
- お得便 クレジット
- お得便 Jチケット

## 後払い手順(通常便)
1. 予約受付
2. 時間経過で予約確定(cloud task)
3. 乗車時刻までにお支払い
4. 乗車

※ 予約確定後から支払い可能・キャンセル不可になる

- 乗車時刻までに支払いせずに乗車　→ 現金で徴収
- 支払いをしたが乗車しなかった　→ キャンセル（返金なし）
- 乗車時刻までに支払いせず乗車もしなかった　→ キャンセル（取りっぱぐれる）

## 後払い手順(お得便)
1. 予約受付
2. 予約確定（即時？　お得便確定時？　通常便と同じ？）
3. 乗車時刻までにお支払い
4. 乗車

※ 予約確定後は通常便と同じ

予約確定のタイミングを考える必要がある
- 即時予約確定　→ Jチケットの場合はこれ。確定後、キャンセル期間がない
- お得便確定時　→ 無難だが、Jチケットの場合はこれができない
- 通常便と同じ　→ 支払い期間が短くなる（もし「お得便確定後に割引」がある場合はこれ）

## Jチケット対応
1. 予約受付
2. 予約受付と同時に予約確定(即時)
3. ジョルダンサイトで決済
4. 乗車

※ 決済がされなかった場合は、時間経過(cloud task)でキャンセルされる

## 予約確定のスケジューリングを追加するタイミング(cloud task)

### ○ セッションアップデート時にスケジューリング
- セッションごとに作成
- 先にスケジュールがないか調べて、作成
- セッションごとに作成されるので、少ない数ですむ
- 予約確定時には、セッションに紐づいているそれぞれの予約に対して確定

### x 予約受付時にスケジューリング
- 予約ごとに作成
- 予約ごとに作成されるので、多くなる可能性がある
- 予約確定時には、その予約に対して確定処理

キャンセルは無視

## 予約確定のタイミング(cloud task)

### ○ セッション開始のN分前(国交省の通達ベースで考えるとこれ)
- セッション開始時刻からなので、実際の乗車時刻からばらつきがある
- 締め切り後にキャンセルされるのを防ぐとこができる

### x 乗車のN分前
- 乗車時刻からのばらつきがないが、締め切り後にキャンセルできてしまう
- 値段などが変化して混乱する可能性あり

## 「ユーザによる」キャンセル
- 予約受付 ~ 料金確定 → キャンセル可能、キャンセル料無料
- 料金確定 ~ 乗車時刻 → キャンセル可能、キャンセル料100%

※ 料金確定後にキャンセルすると、他の予約の料金に影響するため、キャンセル料を取る
※ キャンセル時返金は、それぞれの支払い方法に対応するのが大変なので、しない
※ 現金払いだとキャンセル料を徴収できない。ブラックリスト検討