开发者接入 IAP 时，需要按照苹果提供的规范，根据 App 提供商品的功能和类型来选择不同的内购项目类型，进行创建商品。相当于在我们业务服务端有一份商品列表，苹果 AppStoreConnect 也有一份商品列表与之对应。目前 IAP 中内购项目分为四类：
选择商品类型后，AppStore Connect 中创建商品，以消耗型商品创建为例，需要提供如下信息：
开发者需要接入系统库 StoreKit，苹果在 WWDC21 推出新的 StoreKit2 支持购买，但其需要 iOS15 及以上才支持，目前我们项目中还是使用老的 StoreKit 。
对于 IAP 购买支付的过程是苹果系统处理，只是在交易完成之后，更新本地的交易票据信息并回调 App （票据可以理解为包含交易支付相关信息的加密数据），而对于这份数据是可能会重复或者伪造；需要对其进行验证，苹果提供两种方式：本地验证和服务端验证；一般出于安全性和功能考虑会选用服务端验证。服务端会拿着这份票据再去请求苹果服务端，获取交易支付的详细信息，根据信息判断处理履约情况。
自动订阅类型的商品因为涉及到下个周期代扣履约的情况，会多一些处理，一是服务端可以通过App Store Server Notifications接收订阅续期的情况；二是 App 在启动时收到苹果关于续期成功的票据更新回调。
IAP Product 是在 AppStoreConnect 中配置，是与我们的App对应。特别需要注意的是在测试包App被重签名时，将会获取不到对应的 IAP 商品信息。
沙盒环境不需要真实购买，在 AppStoreConnect 创建沙盒测试账号，可以模拟支付无人用的苹果id美国。
正式环境是针对 AppStore 上架的应用内购买，如果将沙盒环境小票发送到正式环境验证，会收到 21007 的 Status Code
可以看到验证请求接口没有过多限制，只要是真实的小票数据，就可以通过验证接口请求返回结果，这也对服务端对票据结果的真实可靠性需要做完备的校验
可以看到返回结果中包含交易的详细信息，但没有和我们 App 内部相关的，需要服务端解析这些信息处理，将权益发放给用户，因此也会产生较多的问题
从上述流程中发现，IAP 商品交易支付是在系统内部流转，对于 App 只有发起和交易结果回调的感知，而最终交易结果需要依托客户端像服务端发起票据验证请求，获取到结果再和自身服务做匹配履约；服务端无法主动向苹果请求订单结果。
客户端会本地记录 IAP 商品和订单号的数据，当收到回调时，根据交易中 ProductId 获取对应的订单号，一并带到服务端请求验证
如果因为某些原因未获取到订单号，服务端可以根据票据交易信息在订单系统中向前回溯适用的订单进行履约
网络抖动、客户端票据丢失无法向服务端发起请求验证等情况都有可能导致该问题
客户端获取到小票交易信息存储本地，如果验证未完成，定时向服务端发起验证
服务端可以通过 Apple Server-To-Server Notification 接收消息
客户端收到 StoreKit 扣款成功回调，带上本地票据信息请求服务端处理
但因为服务端回调有时不稳定以及依赖设备开启状态，还有一种方式是服务端保存已签约用户的小票数据，在到期前通过这批旧小票向苹果服务端请求续费状态
针对上述提到的问题进行解决，也伴随着云音乐多个产品线开发上线，接入 IAP 需求也在增加，因此我们开发了基础库 NEStoreKit，对业务流程进行抽象，方便各团队快速接入；保障支付履约完成，完善交易场景，记录各个阶段交易日志，对问题有效排查。
将 IAP 交易处理逻辑封装在内部，回调的交易信息包装成 Task，放入队列中，依次交由 Verifier 请求服务端进行验证。
StoreKit2 提供的 API 使用更为简单，对于客户端来说可以用 appAccountToken 替换 applicationUserName ，将 AppleId 和 App 中账户对应，不会像之前容易丢失；同时服务端也可以通过这个标识将用户的消费行为发给苹果，协助苹果处理用户对消费型商品退款的情况。目前较大问题是iOS版本的限制。
IAP的使用一直为开发者诟病，包括创建商品的流程繁琐苹果美国id的expires怎么填，以及刚开始接入自动续费时，踩了不少坑，在和苹果开发人员交流和反馈中，苹果逐渐为开发者提供了更多更全面的API，诸如调用接口管理 IAP 商品Create an In-App Purchase，服务端通过App Store Server API自主查询交易信息。作为iOS开发人员需要持续关注 StoreKit 的发展，与服务端交流，不断完善交易系统的可靠和安全性。
