iapreceiptphp技巧_苹果应用内购IAP做事端开拓心得

transaction：交易，这对应着一次购买，或者是一次自动续费

最基本的便是收据的验证接口，做事端在拿到客户端提交的收据后，调用收据验证接口验证该收据，如果收据有效，会返回该收据关联的交易信息

这个接口的设计我以为是有问题的，首先是返回了太多无意义的字段，其次是跟交易干系的两个字段 in_app 和 lastest_receipt_info，我以为完备该当合并成一个

理论上来说，一个用户的收据，只应返回该用户的交易，但实际上我碰着过收据校验成功，但是不返回任何交易，也碰着过返回了其他用户（乃至不止一个其他用户）的交易

实际上问题还不止这些，这涉及到我们对苹果的定位，我们希望它仅仅是个支付工具，就像支付宝一样，但苹果自己的定位却不是一个支付工具，而是一个订单系统，我想这也是 IAP 对接很随意马虎掉坑里的紧张缘故原由

此外，苹果还有做事真个关照，这也是本文将会涉及的内容

基本流程

这是一次购买的基本处理流程，如果是自动续费成功，客户端会从 AppStore 得到一个收据，直接将该收据提交给做事端进行验证即可

这里建议客户端同时提交收据和交易 id，即 transaction_id 到做事端，这样可以简化做事端处理逻辑

如果客户端未提交交易 id，做事端须要自行判断须要处理的是哪一笔交易，我建议如下处理

按苹果的文档，我们该当对所有交易进行处理，但实际业务中碰着过收据关联了其他用户的交易的情形，以是我建议还是找到最新的交易进行处理

要把稳的是，不要认为 in_app 和 lastest_receipt_info 里的交易是有序的，该当按 purchase_date_ms 字段进行排序

基本上 IAP 的坑都是订阅类商品的坑，较普遍的情形是自动续费到哪个用户账户的问题

从前面的流程里我们可以创造，只有交易完成，做事器才能吸收到客户端发送的收据，这时，收据是否一定归属于当条件交收据的用户呢？答案是不一定

比如以了局景

又比如

可见，这里有一个关键信息是做事端不具备的，便是一笔已发生的交易，到底是归属那个帐号？

我想，这也是 IAP 随意马虎掉坑的紧张缘故原由

苹果并没有把自己当做一个第三方支付做事供应商，它实际上既做了支付做事，也实现了订单做事，我们可以在苹果查询到自己购买过的所有 App，以及 App 内交易

本来这样也没有问题，但问题是苹果的交易是基于 Apple Id 来的，同一个 Apple Id，在同一个运用便是一个用户，这样就有问题了

大多数 App，实在都许可同一个 Apple Id 注册多个帐号，这样在苹果的订单系统看来是同一个用户的订单，在我们的 App 里实在是不同用户的订单，而苹果的订单信息里是不包含 App 内帐号信息的

如果是购买花费品类型商品，很少能触发收据被其他登录帐号提交的场景；但是在自动续费类商品上就很随意马虎发生，如何确定交易的归属，实在是个繁芜的问题

我的办理方案：根据交易的 original_transaction_id 找到该收据对应的用户账号，如果该账号还在自动续费中，则该交易归属此用户；如果找不到或者不在自动续费中，则交易属于当条件交收据的用户

在接入苹果后台关照前，自动续费类商品续期成功，我们有两种办法来触发做事真个处理

此外，如果用户退款，是不能依赖做事端轮询的，此时苹果后台关照可以说是唯一的触发手段。

那么，如何判断交易已退款？可以根据 cancellation_date_ms 字段是否有值来判断