Project Docs · pay

pay 支付服务 · 文档索引

独立支付服务(Go·Gin·GORM),多业务 × 多渠道(支付宝先行,微信留接口)。新增文档请同步登记此处。

🎨 设计方案 / 技术方案

pay v2 · 多产品统一支付 + 履约网关设计 ⭐
把 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 架构图 + 设计决策知识点。
v2 · 2026-07-10 · 待评审 · 结合 pangolin/jiu 现有设计
支付宝收款页 · 支付时序图与架构
PC 网页支付(alipay.trade.page.pay)固定套餐收款页的设计说明:SVG 时序图讲清「下单→跳收银台→扫码付→异步回调验签入账→兜底查单」全链路(到账以异步通知为准);对比「独立服务 vs 集成进 jiu」的区别;说明独立服务为何必须建库、要存哪些数据(orders / products / notify_logs 字段表)与安全红线。
v1.0 · 2026-06-24 · Go(Gin)+GORM · 沙箱联调阶段
支付宝密钥申请与备案依赖关系
沙箱 vs 生产两阶段各需什么;密钥怎么拿(沙箱 4 步 / 生产 5 步,APPID·应用私钥·支付宝公钥分别对应哪个配置);「不用域名是否就不用备案」的结论与三处卡点(商户签约/HTTPS/微信);含两线并行推进路线图(联调线 vs 上线线)。
v1.0 · 2026-06-24 · onboarding · 含备案依赖路线图
pay × jiu · 授权续费对接方案
让 jiu 门店在应用内购买/续费授权:付款走 pay 收款中枢,付成功后 pay 签名 webhook 回调 jiu、jiu 直接给该门店续期(方案 B,无感)。含总体架构与时序、pay/jiu 两侧数据模型改动(Order 加 biz 字段·Product 加 biz_code·Purchase·BizNotifyLog)、接口契约(下单扩展/webhook/购买/接收器)、HMAC 签名+防重放+幂等安全设计、套餐映射、失败重试对账、分阶段实施计划、开放问题清单。
v1.0 · 2026-07-03 · 方案 B(付款直接续期)· server-to-server + 签名 webhook · 待评审

📋 实现计划

pay v2 · 执行总览与评审 ⭐
一页看全:P1 已完成 + 依赖 DAG + P2/P7 待审计划(任务清单)+ 4 个待拍决策点(是否开跑/新仓/延后取舍/资金链路)+ 波次建议。评审入口。
overview · 2026-07-10 · 评审入口
pay v2 · P1 核心数据模型 + 配置账户注册表(阅读版)⭐
阅读版;执行真相源 docs/superpowers/plans/2026-07-10-pay-v2-p1-core-model.md(含 checkbox)。pay v2 设计的首个落地阶段(8 阶段之 P1)。4 个 TDD 任务:money 包(int64 最小单位+币种)→ Order/Attempt/Account/Refund 模型+状态机+:memory: 测试约定 → OrderStore(幂等标付/取消/列表,条件UPDATE+RowsAffected)→ 账户配置注册表(凭证走 env)。沿用 GORM AutoMigrate/glebarez sqlite 惯例;金额从 string 元改 int64。P2-P8(Provider/收款管线/渠道 adapter/退款/路由/对账/codes 库/订阅)各自成计划、落地前细化。
P1 · 2026-07-10 · Go(Gin+GORM+sqlite) · 待执行
pay v2 · P2 收款管线 + Provider 抽象 + webhook v2(计划)
7 个 TDD 任务:Provider 接口(create/verify_callback/query 带 QueryRequest 上下文)+6 render_type+PaidEvent(含 PaidAt)+注册表 → fake provider → OrderStore 扩展 → 一次性收款管线 gateway → 统一入账/开通(先幂等入队再幂等翻转,崩溃安全 + Notifier 已付门禁)→ webhook v2 outbox+Notifier(event_type+HMAC)→ HTTP /api/v2 接线(与旧版统一 /api 前缀,P3 后删 /api/v1 收口)。复用 P1 全部类型、免 docker。含 2026-07-10 评审修订(D3/D4)。
P2 · 2026-07-10 · 评审修订已折入 · 真相源 .md
pay v2 · P2-P8 依赖 DAG 与并行执行
P1 已完成。P2-P8 的依赖关系图(SVG DAG)+ 关键路径 P2→P3→P4/P6 + 波次(P7 全程并行/P5∥P3/P4∥P6)+ 同仓并行的真实边界(先计划后实现、worktree 隔离防冲突)。
roadmap · 2026-07-10 · 8 阶段依赖分析
pay v2 · P7 codes 共享库(激活码兑换内核)(阅读版)
阅读版;执行真相源 docs/superpowers/plans/2026-07-10-pay-v2-p7-codes-lib.md(含 checkbox)。把 pangolin 现有码逻辑抽成独立仓库 github.com/wangjia/codes(与 pay 不同部署,方案 A:共享库嵌入各产品,不改 pay/pangolin/jiu 现有代码)。8 个 TDD 任务:通用权益描述符 Entitlement(duration/quota,不硬编码 plan+天数)→ Crockford Base32 生成器(移植 pangolin idgen)→ Dialect+内嵌 mysql/sqlite migrations+Store CRUD → Mint 批次生成 → Redeem[T] 兑换事务骨架(宿主本地事务+锁+CAS+幂等+grant 回调)→ RateLimiter/NonceChecker 接口+GuardedRedeem → redisx 可选子包(唯一 import Redis 处)→ webhook 灌码(pay-contract 式通用 HMAC 签名)。核心包零第三方依赖。
P7 · 2026-07-10 · Go(stdlib database/sql,可选 redis) · 待执行

运行与联调步骤见仓库根 README.md

🔧 排障 Runbook

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