4. 应用内购买（IAP）- 整体IAP生态理解

IAP 是移动商业闭环的关键一环。真正稳定的 IAP 系统不只在“能买”，而在“能验证、能恢复、能审计、能应对边界”。

会有三章内容，第一章讲述最基本IAP的概念，第二章讲Apple Play的支付/订阅体系，第三章讲Google Play的支付/订阅体系。

这三章我的考虑是这样的：业务上的后端实现会有很大差异化，所以不在本文讨论范围内，我会尽量聚焦在生态体系上，当理解整个生态体系之后后端仅仅就只是插哪张表、定时器处理哪个任务、幂等的支付怎么写这种纯代码逻辑问题。

我在真实开发这块内容时，最花费的时间点其实就在理解两大生态体系上，这部分的调试也是最痛苦的，跑通生态后的，代码实现其实并不复杂。

IAP 的地基

我想先回答三个问题：谁在买、买的是什么、这笔钱是怎么被认出来的。只要这三个点够清楚，后面的苹果和谷歌章节就不会显得像黑箱。

在做 IAP 时，我们很多人都会盯着客户端的购买入口，但真正的主体其实是三角关系：用户、平台商店、我们的服务端。客户端只是用户提交意图的工具。商店负责生成交易凭证，服务端需要用凭证解释和兑现权益。任何一个角的理解不够深，都会在发版后留下坑。

流程是先拿到票据，再去问商店，再让服务端记账，最后才给用户授权。这里的“问商店”指的是服务端拿着票据立刻去请求商店接口校验，客户端在 purchaseSuccess 的回调里第一时间把票据 POST 给服务端，然后等服务端返回验证结果。

要让这个三角关系真正跑得顺，权限管理和状态同步也得提前规划。服务端最好有一个“订单状态机”，而不是几个散落在各个表里的字段。

“能买”只是入口票

IAP 看上去是个按钮 + loading