套餐锁位金（押金式）设计方案

2026-10-08 ·义父提问：「锁位金理论上要给出不同的规则让 A 端配置。

住宿类可不可以考虑用类似住店押金的概念？退房后自动退？」

一、先纠正两个数

「55 个套餐」是我数错了。 真实数据：

packages 总数 85
  ├─ is_test=true   80 个（其中 50 个原本是 active，会污染统计）
  └─ is_test=false   5 个 ← 真正在售

已清理：UPDATE packages SET status='offline' WHERE is_test=true AND status='active'

⇒ active 从 55 → 5，全部真实（不删数据，只下架）。

真正的在售套餐只有 5 个：

id	名称	价格
7083	密钥酒店·拉萨往返住宿套餐（2晚+接送+双摆渡+四正餐）	¥4688
7082	密钥酒店·神山住宿套餐（2晚+双摆渡+四正餐）	¥1868
7081	密钥酒店·转山歇脚套餐（1晚+摆渡+双正餐）	¥798
7084	秘境打卡情报包	¥39
7085	芝达布日寺摆渡券（往返）	¥10

二、为什么用「押金」而不是「定金」——义父这个类比是对的

	定金	锁位金 / 押金
法律属性	有定金罚则（违约不退）	无，是预授权占位
客人心智	要看条款、易犹豫	住酒店交押金，退房退——人人懂
页面话术	容易写成"概不退款"	"退房后退"，一句话说完
退款触发	违约判定	服务结束就退，无争议

结论：对外一律叫「锁位金」，页面话术用押金心智（「退房后退」）。

不用"定金"这个词——它在法律上有罚则含义，写错了是真风险。

三、五种模式，A 端按套餐配（迁移 116 已落库）

字段：packages.deposit_mode / deposit_fallback / deposit_refund_rule / deposit_display

mode	含义	适用
`none`	不收线上款，全额到店付	小额即时服务（摆渡券 ¥10、情报包 ¥39）
`full`	线上全额付清	将来要接的场景
`fixed`	固定锁位金	住宿类（推荐）：¥300 之类
`percent`	按价格比例	需要按房价浮动的场景
`refundable`	可退锁位金（押金式）	住宿类的推荐形态

推荐给 3 个住宿套餐配：

deposit_mode      = refundable
deposit_fallback  = 30000          （¥300 固定额）
deposit_display   = '¥300 锁位，退房后退'
deposit_refund_rule = {"refundable":true, "freeCancelBeforeHours":72}

为什么是固定 ¥300 而不是「30% 订金」

	客人看到	反应
「30% 订金」	要算一下，心算 ¥1404	犹豫、觉得贵
「¥300 锁位」	一眼看完	知道很轻，愿意付

锁位金的作用是筛掉随手点的，不是赚钱。 金额越低，转化越高。

四、订单侧的押金流转（`package_orders`，迁移 116 已加）

字段	用途
`deposit_paid_fen`	线上已收金额
`balance_due_fen`	到店应付尾款（仅展示，不走线上支付）
`deposit_refundable_fen`	当前可退金额（不自动算，A 端或定时任务写入）
`deposit_refunded_fen`	已退金额
`deposit_state`	`none` / `held` / `refunded` / `partial_refunded` / `forfeited`

独立于订单 status —— 便于对账，且不污染已有状态机。

五、🔴 落地前必须解决的技术障碍

障碍：支付与退款链路写死在 `orders` 表

实测确认：

位置	现状
`miniapp_pay.prepay`	`POST /orders/{id}/prepay` —— 只能对`orders` 下单
`miniapp_pay.refund_notify`	走 `orders.pay_out_trade_no` 反查订单
退款发起	同样按 `orders` 查

⇒ 套餐想收真钱、退款，必须先解耦。

解法（与之前讨论的框架一致）

新增 payment_orders（唯一支付收口）
  biz_type（goods/package/route）· biz_order_id · amount_fen
  status · out_trade_no · prepay_id · paid_at · notify_raw

风物逻辑照搬，不重写。 这样：

退款回调只需 out_trade_no → payment_orders → biz_order_id，两种业务共用
将来线路要卖，直接接进同一套

六、流程（全程小程序内闭环，电话只兜底）

① 选套餐 → 填出发日期/人数/联系方式/接送需求
② 付锁位金 → 立刻占位（房、车、导向导当场扣）
③ 系统推「已锁位」+ 客服联系确认细节（接机时间、忌口）
④ 到店：付尾款（线下）→ 入住 → 服务
⑤ 退房：A 端点「退押金」→ 微信原路退 → deposit_state=refunded

关键：客人不打电话也能完成。 电话是"确认细节"，不是"收集信息"——

这正是义父担心的漏客点的解法。

七、需要义父确认的三件事

住宿类锁位金定多少？ 我建议 ¥300（固定）。
出发前多久内不退？ 我建议 72 小时（因为房和车要提前订，临近取消我们要赔）。
5 个套餐里，¥10摆渡券和 ¥39 情报包要不要收线上款？

我建议不收（小额、即时服务，线上收反而麻烦）。