苹果内购 IAP内购 遇到的坑

首先明确 苹果商店IAP与苹果支付ApplePay不是一回事。

怎么开启App的IAP功能，就不赘述了，网上一大堆。

我现在这个开发已经接近尾声，但是，开发过程中对这个模块越来越熟悉，也就发现越来越多的问题。最头疼的就是在商品类型为non-renewable subscription（非自动更新订阅）类型时 in_app[] 里面返回的记录太多，而类型为consumable （消耗型）的时 in_app[]里的记录可以做到只有一条，但都是没有App内的对应关系。

比方场景如下 

1、A设备上的App1，登录CountA使用AppleId1进行内购Product1，向Appsotre付款成功，但是在与自己的Sever交互过程中失败(包括Server失败以及Server与Appstore交互失败)，我们客户端认为 此次交易失败，商品不发放给CountA。而实际上Appstore扣费成功，并且可能把对应的账款已经转入Server的卡号里。复杂一点如下
2、A设备上的App1，登录CountA使用AppleId1进行内购Product1，向Appsotre付款成功，但是在与自己的Sever交互过程中失败(包括Server失败以及Server与Appstore交互失败)，我们客户端认为 此次交易失败，商品不发放给CountA。然后这个账号，重复购买，重复出现这个情况多次。而实际上Appstore扣费成功多次，并且可能把对应的多次账款已经转入Server的卡号里。再复杂一点如下

3、相同的2场景，此时，他登出CountA，登录CountB，仍然使用AppleId1购买Product1，出现相同情况多次后，偶然一次与Server交互成功，此时，Server端在Appstore那里能拿到这个AppleId购买这个App的内购商品的所有记录，但是这些记录仅仅是 这个AppleId的扣款记录，至于这些记录都是分别是CountA，CountB，CountX之中谁的，苹果不知道，就不会告诉我们，那么，我们就不知道这些所有的扣款记录到底要发放给CountA，CountB，CountX之中的谁？发多少次？

那么就会出现 支付成功的游离订单。收到钱了，不知道是谁支付的？

解决1和2，我们客户端本地存储，账号的信息以及支付信息都保存，直到成功之前都不停尝试。

4、在场景2下，用户删除了App那么本地的存储都不见了，再次安装App，登录账号CountC,使用AppleId1购买Product1，扣费成功，与Server交互验证，此时Server在Appstore拿回所有的交易记录，那么此时这些成功记录，都发放给CountC吗？如果Sever有机制对其中记录过的交易不重复发放，那么未记录过的的呢？都发放给CountC？也不合适，毕竟我们知道CountA应该被发放。但是程序是不知道的。

这些都是在AppleId不变的情况下的场景，那如果在这些操作里 几个AppleId换来换去，几个CountX换来换去，App删掉装，装了删，再装。这么复杂情况，你怎么对账？怎么核对交易记录？我们仅仅凭借 客户端和自己的服务器  靠程序猿的技术已经无法解决了，那没办法，只能让财务自己去跟客户沟通，去AppstoreConnect拉取财务报表 自己去核对吧。

 

这个不考虑黑客的IAP攻击，服务器端逻辑就有点复杂了，考虑到防攻击(欺骗等)逻辑会更复杂。