使用billingclient:billing:4.0.0时应在哪个步骤记录已验证的内购订阅购买信息

直接在onPurchasesUpdated回调中执行数据库写入操作不是完整的规范方案，该回调仅作为购买完成的触发入口之一，完整的落地流程需要覆盖客户端、服务端双端逻辑，同时补充异常场景的补漏机制，具体步骤如下：

1. 触发入口统一处理逻辑 #

所有购买行为的处理统一覆盖两个触发场景，避免丢单：

• 实时触发：onPurchasesUpdated回调
• 补漏触发：每次APP启动、进入支付页时主动调用BillingClient.queryPurchasesAsync(BillingClient.SkuType.SUBS)（订阅）/BillingClient.SkuType.INAPP（内购）拉取用户所有未确认的购买记录

2. 单条购买记录校验流程 #

对每一条拿到的Purchase数据，按顺序执行以下校验：

• 校验购买状态：必须为Purchase.PurchaseState.PURCHASED才继续处理，状态为PENDING的订单仅做标记，等后续状态更新后再处理，此时不可写入数据库
• 校验确认状态：如果isAcknowledged()返回true，说明该订单已经处理过，直接跳过避免重复入库
• 后端验签：将Purchase的originalJson和signature字段一并传给你的后端，后端使用Google Play Console下载的公钥做签名校验，同时校验商品ID（比如你列的sub_1/sub_2/sub_3）、订单号、购买时间是否合法，是否已经存在入库记录

3. 订单确认与入库 #

后端验签通过后，按商品类型执行对应流程：

订阅/非消耗型内购 #

• 后端先写入购买记录到数据库，标记为「待确认」状态
• 客户端收到后端验签通过的响应后，调用BillingClient.acknowledgePurchase()接口提交订单确认
• 确认成功后客户端通知后端，后端将订单状态修改为「已生效」，触发提醒消息推送、开通对应权益

消耗型内购 #

• 后端先写入购买记录到数据库，标记为「待确认」状态
• 客户端收到后端验签通过的响应后，调用BillingClient.consumeAsync()接口消耗订单
• 消耗成功后客户端通知后端，后端将订单状态修改为「已生效」，触发提醒消息推送、发放对应权益

4. 服务端兜底校验 #

为了避免客户端异常（闪退、杀进程、网络中断）导致的订单遗漏，服务端需要额外对接Google Play实时开发者通知，接收购买完成、订阅状态变更的官方推送，收到推送后再调用Google Play Developer API查询订单状态，做最终的状态同步和补录。

注意：所有签名校验、订单状态判定逻辑必须放在服务端执行，禁止在客户端做验签和权益发放判定，避免被逆向破解产生假单。

内容的提问来源于stack exchange，提问作者Mahmut