服务端权益：appAccountToken、通知与幂等
当付费功能涉及你自己的 API、点数或多端账号时，需要把 Apple 交易可靠关联到业务账号。
用你的前端经验理解
很像 Web 支付的 webhook 与订单账本，但事件是带签名的数据。浏览器或 App 告诉服务端“我买了”不能直接成为付费授权依据。
为什么需要它
当会员解锁服务端 API 或消耗额度时，权益需要在后端可信地维护。客户端上报“我买了”不够，后端应验证交易来源与应用、环境、商品等关键字段，再关联业务用户。appAccountToken 可把交易与服务用户联系起来，但它是关联标识，不是秘密密码或单独的认证证明。
它是怎样工作的
服务端通知可能重复、延迟和乱序，应先验证签名并持久化可信事件，再幂等更新账本。交易 ID 适合避免同笔交易重复发放，订阅链还需要合适的关联标识追踪生命周期。不能按“最后收到的通知”直接覆盖全部状态，必要时向 App Store Server API 查询可信现状并补偿遗漏。
把关键概念连起来
账号关联
购买时可传 appAccountToken（UUID）关联你的业务账号，服务端保存映射，不填真实邮箱。它是关联线索，不是授权证明；仍需验证交易及其所属应用、环境和商品。
服务端事件
App Store Server Notifications V2 用于接收订阅/交易变化，Server API 用于查询与补偿。验证 signedPayload/JWS、bundle ID、environment 等；Apple 提供官方 Node.js 服务端库辅助验证与调用。
可靠账本
通知可能重复、迟到或乱序。先可靠接收/记录，再幂等处理，用 transaction ID 防重复发放，结合 original transaction 追踪订阅链；必要时查询权威状态补齐事件。服务端保护付费 API，客户端负责及时反馈。
100 点数只发放一次
服务器验证交易后，以 transactionId 作为唯一键，在事务中记录交易并增加余额。相同交易重放时返回已处理结果。退款、消耗与补偿另记账，不靠覆盖一个客户端余额解决。
购买成功与服务端通知同时到达
- 客户端上报交易，后台通知也到达，两者进入同一规范化验证与记账路径。
- 数据库用可信交易身份与业务唯一约束阻止重复发放；即使两个请求并发，额度也只增加一次。
- 通知处理失败时保留待重试事件，接口返回和队列确认需要与可靠持久化衔接，方便恢复与追踪。
这里需要你亲自判断
不能信任客户端传来的 isPro、productId 或交易 JSON；不要让重复通知重复充值，也别把沙盒测试交易当生产付款。
做一个小练习
为 Node/Hono 后端设计账号映射、交易表、通知接收和权益查询四个接口/模块，并写一个重复交易只发放一次的验收。
- 设计 user、external transaction、entitlement 或 credit ledger 的最小关联。
- 模拟旧到期事件晚于新续费事件到达，确认新权益不被错误清除。
展开参考思路与验收标准
appAccountToken 帮助映射用户，签名验证证明交易可信，幂等账本保证处理一次；三个职责缺一不可。业务账号切换时还要明确既有购买绑定和恢复策略。