【iOS开发】IAP开发的那些坑

最近正在做的项目,涉及到了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

推荐阅读更多精彩内容