In-App Purchase 总结

商品类型

1. 消耗型
2. 非消耗性
3. 自动订阅
4. 非自动订阅

类似“会员”功能, 有明显有效期特征的, 必须使用 非自动订阅 / 自动订阅, 否则审核会被拒

Receipt (回执)

receipt 是用户购买成功后的回执单, 其自身是一段被加密的数据. iTunesConnect后台可以生成 SharedSecret (共享密钥), 通过 SharedSecret + receipt 对 Apple 服务器发起验证, 可以取到明文.

当且仅当 用户付款成功, 才会获取到 receipt .

通用购买流程

购买流程

处理漏单

漏单是指 用户在付费成功后, 但 未校验/上传 成功.

IAP在每一次付款成功后, 都会生成一个 `SKPaymentTransaction`, 需要开发者在完成购买的业务流程后, 手动调用 `[SKPaymentQueue finishTransaction]` 将 transaction 标记为成功.

漏单即是 存在未被 finish 的 SKPaymentTransaction.

通常在 `application:didFinishLaunchingWithOptions:`时, 检查当前是否存在漏单, 并对漏单进行处理.

防伪造

Validating Receipts With the App Store

客户端校验

客户端校验通常用于 无服务端/轻服务端 的App. 在购买成功, 收到 receipt 之后, 由客户端向Apple发送请求, 校验receipt. 在校验成功后, finish transaction.

服务端校验

在涉及服务端校验购买结果时, 通常在购买成功后上传receipt到服务端, 服务端对收到的 receipt 发到Apple的服务器进行校验. 所以流程上, 购买成功后, 拿到receipt, 需要上传到业务服务端, 在上传成功后 finish transaction.

关于服务端对收到 receipt 的校验, 因为涉及到对Apple服务发送请求. 所以通常有两种处理方案: 

1. 将 校验receipt 的工作加入消息队列, 异步进行处理.
2. 同步处理receipt的校验, 在遇到Apple服务请求超时等网络原因的情况下, 返回重试. 客户端在接收到重试状态时, 不去 finish transaction, 而是走漏单流程, 在用户下一次打开app时, 当漏单处理, 重新上传receipt到服务端去校验.

双重校验

即客户端在收到receipt之后, 先进行客户端校验, 通过后再进行服务端校验.

考虑一下双重校验的必要性, 一般服务端校验, 就已经足够, 额外的客户端校验会使购买流程以及用户等待的时间变长.

发布前检查

检查 “功能” 中的 “App 内购买项目”, 查看各个商品的状态是否是等待审核.