最近正在做的项目，涉及到了IAP（In-App Purchase），即苹果的应用内购买。在开发过程中遇到了各种各样的状况，IAP的开发步骤在网上有很多十分详尽的教程，不需赘述，本文重点介绍说明在IAP开发过程中遇到的坑，并探讨相对合理的解决办法。

一、IAP类型与用户系统

绝�大部分iOS应用，都会维护一套自己的用户系统，然而IAP是使用苹果的用户系统（Apple ID）来进行购买的，因此就会产生一个问题：

通过苹果的用户系统（Apple ID）的购买结果或行为，如何与应用本身的用户系统进行关联？

很简单的�情况就是，应用内的不同用户使用同一个Apple ID进行IAP，或者是应用内同一个用户使用不同Apple ID进行IAP，要如何处理。

解决这个问题之前，首先要明确IAP的类型，以及每种类型的特性。下面是在iTunes Connect创建IAP时的提示：

可以看到IAP总共有5种类型，虽然苹果对每种类型的说明很详细，并且都加上了举例说明，但仍然没有明确的信息解决之前的问题。在查阅了苹果IAP的开发文档后，我发现了下面的表格：

这个表格中表明了不同类型IAP的在使用同一Apple ID购买时的次数限制，经过测试总结如下：

• 非消耗型

同一Apple ID只能购买一次，再次购买会提示已购买。

无法与应用的用户系统关联，因为同一Apple ID无法为多个应用用户购买。

• 消耗型

同一Apple ID可以购买多次，�每次购买流程几乎完全相同。

可以与应用的用户系统关联，因为每次购买与Apple ID几乎无关系。

• 自动续订订阅

同一Apple ID可以购买多次，但在购买时会检查是否购买过，如果购买过并且权限未过期，系统会提示已购买而无法再购买。

无法与应用的用户系统关联，因为同一Apple ID购买时会检查购买纪录并校验权限，未过期用户无法重新购买。

• 非续订订阅

同一Apple ID可以购买多次，但在购买时会检查是否购买过，如果购买过并且权限未过期，系统会提示续期而可以再次购买。

可以与应用的用户系统关联，但同一Apple ID在购买时会检查购买纪录�并校验权限，未过期用户会有续订提示，这种系统提示在一些场景下是不合适的。

• 免费订阅

同一Apple ID只能购买一次，再次购买会提示已购买。

无法与应用的用户系统关联，因为同一Apple ID无法为多个应用用户购买。

p.s. 有一种比较暴力的做法，就是将应用的用户系统与Apple ID的用户系统进行关联，一个应用用户对应一个Apple ID。这种方法实质上是将两个用户系统进行统一，但这种方法会产生很多副作用，建议尽量不要使用。

�二、IAP流程与receipt校验

在选取了合适的类型之后，就是实现IAP的基本流程，客户端和应用后台的主要任务是处理购买成功后，如何校验用户购买结果：

按上图的流程，主要是处理逻辑是在最后一步Delivering Products的Observer is Called，即购买之后系统回调之后的处理。这里最核心的部分就是购买结果的校验，即receipt校验。

在用户IAP成功后，客户端或服务器可以使用receipt向appstore请求，获取用户的购买记录，得到一份json格式的数据，通过数据解析来�校验用户购买的产品类型、权限、期限等信息。

• IAP是否可用判断

这里主要注意的是对越狱用户要添加额外的判断，因为越狱用户是无法进行IAP的，因此在入口就要进行判断，其次调用canMakePayments函数，判断IAP是否可用，再次校验product是否合法。

当然也可以加上应用的一些判断，如登录状态，是否已经购买等。

• finishTransaction的调用时机

所有的教程都会说在购买完成回调时，要调用finishTransaction函数，但这个函数具体会产生哪些作用并没有具体说明。

(1) 问：如果不调用finishTransaction会有什么影响？
答：appstore会认为购买流程未完成，如果应用启动时就注册了IAP的observer，那么会出现应用每次启动时，都会调到回调，传说中的Apple ID密码的频繁弹框大部分是这个原因造成的。

(2) 问：调用finishTransaction函数之后，对receipt有什么影响？
答：在上一节中的表格中，对于不同类型IAP的receipt的保存有差别的是消耗型，它只保存一次。保存一次的意思就是说，在购买成功后会有消耗型的receipt信息，但在调用finishTransaction函数之后，消耗型的购买信息就会被删除。因此对于消耗型IAP，建议在校验完成后再调用finishTransaction。

• transaction_id和original_transaction_id

在每一条购买信息数据中，有两个容易混淆的字段：transaction_id和original_transaction_id。

(1) transaction_id
每一次购买记录生成唯一标识，与SKPaymentTransaction类中的transactionIdentifier相对应

(2) original_transaction_id
在restore时使用，与SKPaymentTransaction类中的originalTransaction�相对应
自动续订订阅类型，所有的购买记录都相同

• in_app与latest_receipt_info

测试时发现，这两个字段的数值几乎相同，不过有几点需要注意：

（1）自动续订订阅类型，在到期后会再生成一条购买记录，这条记录会出现在last_receipt_info里，但不会出现在in_app里

（2）自动续订订阅类型可以配置试用，试用记录只有在latest_receipt_info里，is_trial_period字段才是true

（3）消耗型购买记录有可能不会出现在latest_receipt_info，因此需要检查in_app来确保校验正确

• restore的处理

如果应用中使用了非消耗型、自动续订订阅型、免费订阅型的IAP，需要提供restore的入口，并调用restoreCompletedTransactions函数进行恢复购买。

在恢复购买的时候，要注意�要使用originalTransaction的信息来做校验，特别是购买时的id，因为在restore的时候生成的transaction的id，与初始购买不相同

��三、IAP测试

IAP测试只要添加沙箱测试账号就可以进行测试了，不过在测试订阅类型时，要注意测试的时间长度与实际的时间长度的对应关系：

��四、IAP审核

在提交审核时，一定要注意在应用描述中添加IAP的具体说明，包括种类、价格、服务等，同时在应用描述及应用中添加服务条款。

[1]In-App Purchase Programming Guide
[2]Receipt Validation Programming Guide