pay 支付服务 · 文档索引

把 pay 干净重设计成 pangolin/jiu/dudu/未来共用的支付层。三个正交关注点：pay 收款（本设计核心）/ codes 兑换（平级共享内核）/ entitlement 开通（各产品自留）。核心模型 Order+Attempt+Account（一单 N 渠道只一个成功·可取消·可退款·多账户路由）；6 个 render_type 多态（pay 下发数据不下发 UI，样式归业务方；加同形态新渠道零改 client）；Provider adapter（verify_callback 吸收渠道差异）；webhook v2 加 event_type（退款/订阅/拒付，断代 v2.0.0）；退款三向（业务/人工 crypto/平台 IAP）；促销折扣归业务、金额权威归 pay；多币种 + 配置驱动渠道 + 国内外同码双部署；crypto(USDT-TRC20 自托管)抗风控兜底；recurring 设计进模型暂不实现。含 SVG 架构图 + 设计决策知识点。

PC 网页支付（alipay.trade.page.pay）固定套餐收款页的设计说明：SVG 时序图讲清「下单→跳收银台→扫码付→异步回调验签入账→兜底查单」全链路（到账以异步通知为准）；对比「独立服务 vs 集成进 jiu」的区别；说明独立服务为何必须建库、要存哪些数据（orders / products / notify_logs 字段表）与安全红线。

沙箱 vs 生产两阶段各需什么；密钥怎么拿（沙箱 4 步 / 生产 5 步，APPID·应用私钥·支付宝公钥分别对应哪个配置）；「不用域名是否就不用备案」的结论与三处卡点（商户签约/HTTPS/微信）；含两线并行推进路线图（联调线 vs 上线线）。

让 jiu 门店在应用内购买/续费授权：付款走 pay 收款中枢，付成功后 pay 签名 webhook 回调 jiu、jiu 直接给该门店续期（方案 B，无感）。含总体架构与时序、pay/jiu 两侧数据模型改动（Order 加 biz 字段·Product 加 biz_code·Purchase·BizNotifyLog）、接口契约（下单扩展/webhook/购买/接收器）、HMAC 签名+防重放+幂等安全设计、套餐映射、失败重试对账、分阶段实施计划、开放问题清单。

支付宝当面付在阿里云的部署现状（systemd 守护、密钥走 Bitwarden→rbw→env、下单加签已验证、仅差支付宝审核）、部署架构图、服务器路径清单、运维常用命令（状态/重启/日志/更新密钥/更新程序/查订单）、上线检查清单；以及微信支付规划与硬前提（V3 回调强制 HTTPS→须先备案）。