okinawan_eats

概要¶

QR コード（印刷物）を使わずに、ユーザーがカタログをクレジットカードで直接購入できるようにする。
決済が終わると、ギフトの URL とパスワードが LINE メッセージで届く。
受け取り後にギフトを選ぶ流れは、既存の QR コードのフローと同じ。

想定フロー¶

1. ユーザー（LINE ログイン済み）が「直接購入」フラグの付いたカタログ一覧を開く
2. カタログを選び、カタログの金額をクレジットカードで決済する
3. 決済が終わると、チケット（URL・パスワード）が発行され、LINE メッセージで届く
4. 届いた URL を開いてパスワードを入力し、ギフトを選ぶ（既存のフローと同じ）
5. 購入したチケットは #721 の機能で友人に譲ることもできる

実装メモ（現状のスキーマから見た論点）¶

• catalogues に「直接購入」フラグ（boolean）と金額のカラムを追加する（今は price カラムがない）
• tickets は contract（distributor_id / story_id / expired_at が必須）に属している。 直接購入のチケットをどの contract にひもづけるか決める必要がある （例: 直接購入用の distributor / contract を用意する、購入 1 件ごとに contract を作る）
• 購入履歴（決済）を記録するモデルが必要（決済 ID、金額、購入者、発行したチケット）
• admin で購入履歴を確認できるようにするか

検討事項¶

• 決済サービス: Stripe / PAY.JP / GMO など、どれを使うか（今は決済用の gem が入っていない）
• LINE メッセージの送り方: Messaging API の push メッセージを使う（公式アカウントとの友だち登録が必要か確認する）
• 有効期限: 直接購入したチケットの有効期限（contract.expired_at に当たるもの）をどうするか
• キャンセル・返金: ギフトを選ぶ前ならキャンセルできるようにするか
• 特定商取引法に基づく表記など、ネット販売に必要なページの整備
• 規模が大きいので、着手時に分割する（例: カタログの金額・フラグ追加 / 決済 / LINE 送信）

工数見積¶

合計 12.5〜20 人日（内訳は子チケット）

• カタログに直接購入フラグ・金額を追加（モデル・admin）: 1〜1.5 人日
• 直接購入用の contract・チケット発行の仕組み: 2〜3 人日
• 決済サービス連携（チェックアウト・webhook・購入履歴モデル）: 4〜6 人日
• 直接購入カタログの一覧・購入画面: 1.5〜2.5 人日
• 決済完了後に LINE で URL・パスワードを送信: 1〜1.5 人日
• admin で購入履歴の確認・返金対応: 1.5〜3 人日
• 特商法表記・利用規約など販売に必要なページ: 0.5〜1 人日
• 本番設定（決済のキー・webhook）と結合テスト: 1〜1.5 人日