FruitServer

42 Commits 10 Branches 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
Zhou Weidong	db897d50d6	feat(commerce): Google Play 票据校验闭环（校验→建单→发权益 + 幂等/防重放）为什么：风险清单 R-03 把支付票据校验列为上线阻塞项；/app/orders/verify 此前只有 disabled 占位，且 verifyAndDeliver 要求订单事先存在——而 IAP 没有下单接口，接了校验也走不通。 - 新增 GooglePlayStoreVerifier（校验 purchaseState/productId/orderId）+ StorePlatforms（平台归一化） - 新增 GooglePlayPurchaseClient 端口与 HttpGooglePlayPurchaseClient：JDK HttpClient + 服务账号 RS256 JWT 换 token，不引入 Google SDK 依赖；token 按过期缓存 - StoreVerifier 实现由 fruitshorts.commerce.store.verifier 选择，默认 disabled，无凭据时对外行为不变 - OrderService 补齐闭环：校验通过后按 (platform, storeProductId) 找商品建单、写 store_receipt 审计、发金币并推进到 DELIVERED；幂等键 (platform, storeTransactionId) 与唯一索引双保险 - 防重放：重复提交同用户返回既有订单且不再发币；票据已被他人使用返回 403；校验失败不写任何数据 - 凭据只走配置/环境变量（packageName + service account JSON），不入库不提交 - 契约同步 docs/api-phase1.md §1.8；金额微单位换算与回退价有单测覆盖 - 实测：mvn test 54 条全过（commerce 13 + app-api 41，M2 的 37 条未被打红）；两个入口 package 通过；默认 disabled 端到端返回 200003 且 orders 表零行	2026-10-16 11:03:33 +08:00
Zhou Weidong	35be37c193	style: 全量补充作者标识 // Author: fruit.com.cn	2026-10-16 00:01:53 +08:00
Vicky	7e730fbbca	feat: 08 订单与权益落地（金币解锁 / 权益判定生效 / 补发回收 / 对账）为什么： 1) 第一阶段要能真正收到钱，而收钱方式是金币解锁分集。本提交把钱包、金币流水、权益、订单四样打通，客户端可以解锁并立刻播放，不再只是展示。 2) 权益判定此前只是端口占位（一律视为未解锁）。交易模块用 @Primary 提供实现后，播放入口与下载入口的付费判定同时生效 —— 两条链路一行没改。 3) 钱的事必须可追溯、可幂等：所有金币变动都带幂等键并写 coin_ledger，余额与流水同事务；订单每次状态流转都写 order_event（月分区），支付争议可回溯。 4) 后台要能兜住线上问题：补发（重复提交幂等）、退款（回收权益 + 扣回金币，余额不足时留人工跟进备注）、人工补币（先校验用户存在，避免给不存在的用户建钱包）、手动对账（默认每天 04:20 自动跑前一天）。 5) 09 商店支付按约束只做端口预留：StoreVerifier 未接入时明确报"尚未配置"，宁可不收钱也不产生假订单。	2026-10-15 12:26:27 +08:00

Author

SHA1

Message

Date

Zhou Weidong

db897d50d6

feat(commerce): Google Play 票据校验闭环（校验→建单→发权益 + 幂等/防重放）

为什么：风险清单 R-03 把支付票据校验列为上线阻塞项；/app/orders/verify 此前只有 disabled
占位，且 verifyAndDeliver 要求订单事先存在——而 IAP 没有下单接口，接了校验也走不通。

- 新增 GooglePlayStoreVerifier（校验 purchaseState/productId/orderId）+ StorePlatforms（平台归一化）
- 新增 GooglePlayPurchaseClient 端口与 HttpGooglePlayPurchaseClient：JDK HttpClient + 服务账号
  RS256 JWT 换 token，不引入 Google SDK 依赖；token 按过期缓存
- StoreVerifier 实现由 fruitshorts.commerce.store.verifier 选择，默认 disabled，无凭据时对外行为不变
- OrderService 补齐闭环：校验通过后按 (platform, storeProductId) 找商品建单、写 store_receipt 审计、
  发金币并推进到 DELIVERED；幂等键 (platform, storeTransactionId) 与唯一索引双保险
- 防重放：重复提交同用户返回既有订单且不再发币；票据已被他人使用返回 403；校验失败不写任何数据
- 凭据只走配置/环境变量（packageName + service account JSON），不入库不提交
- 契约同步 docs/api-phase1.md §1.8；金额微单位换算与回退价有单测覆盖
- 实测：mvn test 54 条全过（commerce 13 + app-api 41，M2 的 37 条未被打红）；
  两个入口 package 通过；默认 disabled 端到端返回 200003 且 orders 表零行

2026-10-16 11:03:33 +08:00

Zhou Weidong

35be37c193

style: 全量补充作者标识 // Author: fruit.com.cn

2026-10-16 00:01:53 +08:00

Vicky

7e730fbbca

feat: 08 订单与权益落地（金币解锁 / 权益判定生效 / 补发回收 / 对账）

为什么：
1) 第一阶段要能真正收到钱，而收钱方式是金币解锁分集。本提交把钱包、金币流水、
   权益、订单四样打通，客户端可以解锁并立刻播放，不再只是展示。
2) 权益判定此前只是端口占位（一律视为未解锁）。交易模块用 @Primary 提供实现后，
   播放入口与下载入口的付费判定同时生效 —— 两条链路一行没改。
3) 钱的事必须可追溯、可幂等：所有金币变动都带幂等键并写 coin_ledger，
   余额与流水同事务；订单每次状态流转都写 order_event（月分区），支付争议可回溯。
4) 后台要能兜住线上问题：补发（重复提交幂等）、退款（回收权益 + 扣回金币，
   余额不足时留人工跟进备注）、人工补币（先校验用户存在，避免给不存在的用户建钱包）、
   手动对账（默认每天 04:20 自动跑前一天）。
5) 09 商店支付按约束只做端口预留：StoreVerifier 未接入时明确报"尚未配置"，
   宁可不收钱也不产生假订单。

2026-10-15 12:26:27 +08:00