transaction：交易，这对应着一次购买，或者是一次自动续费
苹果的接口最基本的就是收据的验证接口，服务端在拿到客户端提交的收据后，调用收据验证接口验证该收据，如果收据有效，会返回该收据关联的交易信息
这个接口的设计我觉得是有问题的，首先是返回了太多无意义的字段，其次是跟交易相关的两个字段 in_app 和 lastest_receipt_info，我觉得完全应该合并成一个
理论上来说，一个用户的收据，只应返回该用户的交易，但实际上我遇到过收据校验成功，但是不返回任何交易，也遇到过返回了其他用户（甚至不止一个其他用户）的交易
实际上问题还不止这些，这涉及到我们对苹果的定位，我们希望它仅仅是个支付工具，就像支付宝一样，但苹果自己的定位却不是一个支付工具，而是一个订单系统，我想这也是 IAP 对接很容易掉坑里的主要原因
此外，苹果还有服务端的通知，这也是本文将会涉及的内容
IAP 交易和验证基本流程
客户端从 AppStore 获取商品信息用户选择商品并完成购买客户端从 AppStore 获得一个收据客户端把收据发送到服务端服务端调用 AppStore 的收据验证接口进行验证验证通过，服务端根据收据里的交易信息，进行订单的发货处理服务端向客户端返回收据处理结果客户端调用 AppStore 的接口通知收据已处理这是一次购买的基本处理流程，如果是自动续费成功，客户端会从 AppStore 获得一个收据，直接将该收据提交给服务端进行验证即可
这里建议客户端同时提交收据和交易 id，即 transaction_id 到服务端，这样可以简化服务端处理逻辑
如果客户端未提交交易 id，服务端需要自行判断需要处理的是哪一笔交易，我建议如下处理
将 in_app 和 lastest_receipt_info 里的交易合并去重，去重的逻辑是相同的 product_id+original_transaction_id+transaction_id 则视为同一笔交易按商品类型分组取每一组的购买时间最近的一笔交易按苹果的文档，我们应该对所有交易进行处理，但实际业务中遇到过收据关联了其他用户的交易的情况，所以我建议还是找到最新的交易进行处理
要注意的是，不要认为 in_app 和 lastest_receipt_info 里的交易是有序的，应该按 purchase_date_ms 字段进行排序
订阅类商品基本上 IAP 的坑都是订阅类商品的坑，较普遍的情况是自动续费到哪个用户账户的问题
从前面的流程里我们可以发现，只有交易完成，服务器才能接收到客户端发送的收据，这时，收据是否一定归属于当前提交收据的用户呢？答案是不一定
比如以下场景
用户 A 购买了自动续费类订阅，比如视频网站的按月付费的 Vip在 Vip 到期前 1 天，苹果自动从该用户绑定的信用卡扣费成功A 用户这段时间一直未登陆帐号A 的 Vip 自动续费成功后，其使用同一部手机，登陆了 B 帐号此时，App 端获取到 AppStore 的收据并以 B 的身份提交收据到服务端，服务端到底该给 A 增加 Vip 有效期还是给 B 增加？又比如
A 购买了自动续费的月付 Vip第二个月 Vip 还未到期时，A 取消了自动续费该用户在同一部手机登录了 B 帐号，并用 B 帐号购买了自动续费的 季付 Vip在 该 季付的 Vip 到期前一天，苹果扣费成功此时该用户登录了 A 帐号，客户端获取了季付 Vip 成功的收据并提交服务端可见，这里有一个关键信息是服务端不具备的，就是一笔已发生的交易，到底是归属那个帐号？
我想，这也是 IAP 容易掉坑的主要原因
苹果的处理逻辑苹果并没有把自己当做一个第三方支付服务提供商，它实际上既做了支付服务，也实现了订单服务，我们可以在苹果查询到自己购买过的所有 App，以及 App 内交易
本来这样也没有问题，但问题是苹果的交易是基于 Apple Id 来的，同一个 Apple Id，在同一个应用就是一个用户，这样就有问题了
大多数 App，其实都允许同一个 Apple Id 注册多个帐号，这样在苹果的订单系统看来是同一个用户的订单，在我们的 App 里其实是不同用户的订单，而苹果的订单信息里是不包含 App 内帐号信息的
如果是购买消耗品类型商品，很少能触发收据被其他登录帐号提交的场景；但是在自动续费类商品上就很容易发生，如何确定交易的归属，其实是个复杂的问题
我的解决方案：根据交易的 original_transaction_id 找到该收据对应的用户账号，如果该账号还在自动续费中，则该交易归属此用户；如果找不到或者不在自动续费中，则交易属于当前提交收据的用户
苹果后台通知在接入苹果后台通知前，自动续费类商品续期成功，我们有两种方式来触发服务端的处理
客户端从 AppStore 获得交易成功的收据，并发送到服务端服务端定时轮询收据验证接口，将快要到期的收据拿去验证这样的缺点就是不够及时，影响用户体验此外，如果用户退款，是不能依赖服务端轮询的，此时苹果后台通知可以说是唯一的触发手段。
那么，如何判断交易已退款？可以根据 cancellation_date_ms 字段是否有值来判断
