苹果商店自动订阅的回调，绝对不代表一定付款成功，App Store的服务端回调是订阅状态变更事件通知，仅代表订阅状态发生了变化，而非全部是付款成功，包含大量扣款失败、取消、退款类回调。
一、关键回调类型（V2版本）区分（直接决定是否付款成功）
1. ✅ 代表付款成功的回调- SUBSCRIBED ：首次订阅购买成功
- DID_RENEW ：自动续订扣款成功
- DID_RECOVER ：之前扣款失败，重试后成功续订 2. ❌ 代表付款失败/无扣款的回调（最易踩坑）- DID_FAIL_TO_RENEW ：核心！因银行卡过期、余额不足等计费问题，扣款失败，苹果会进入60天重试期，期间持续发送该回调
- DID_CHANGE_RENEWAL_STATUS ：用户关闭/开启自动续订，无扣款
- EXPIRED ：订阅到期、扣款失败后过期
- REFUND ：用户申请退款，已扣款但被追回
- REVOKE ：苹果撤销订阅权益（退款/违规）
- CONSUMPTION_REQUEST ：用户发起退款申请，等待商家确认
二、为什么回调≠付款成功？
1. 回调本质：App Store的Server-to-Server通知是全生命周期状态推送，覆盖订阅从购买、续订、失败、取消、退款的所有状态，不是仅推送成功事件； 2. 扣费重试机制：扣款失败后，苹果会持续60天重试，期间反复推送 DID_FAIL_TO_RENEW ，属于高频无效扣款回调； 3. 延迟退款：即使收到成功回调（如 DID_RENEW ），后续用户仍可申请退款，触发 REFUND 回调，权益会被回收。
三、生产环境必做的校验逻辑（避免发错权益）
1. 优先判断 notificationType ：仅 SUBSCRIBED / DID_RENEW / DID_RECOVER 可初步判定成功； 2. 二次校验收据（核心！）：解析回调中的 signedTransactionInfo / latest_receipt ，调用苹果App Store Server API验证交易状态：- 校验 transactionStatus ：仅 1 （成功）为有效付款；
- 校验 expiresDate ：确认订阅有效期；
- 校验 revocationDate ：排除已退款/撤销的订单； 3. 幂等处理：用 transactionId 去重，避免重复发放权益； 4. 兜底轮询：定时调用苹果订阅状态接口，同步用户最新订阅状态，防止回调丢失/延迟。
四、开发避坑要点
- 绝对不能只依赖回调通知发放权益，必须二次校验；
- 沙盒环境测试时，扣款失败回调、退款回调都需覆盖；
- 区分生产/沙盒环境，避免测试数据污染正式权益。
