iOS应用内支付(IAP)开发中后期的那些坑

一，Product ID无效？

好了，经过前面的准备后，就到了真正和IAP联通的步骤了。在输入一个Product ID向服务器发起request的时候，很有可能出现失败的情况，在request属性InvalidateIdentifier中，你会发现这个Product ID是无效的。

为什么呢？苹果是不会告诉你的，连个错误代码都没有，非常坑爹。

所以这里我们有一个Check List，需要大家逐条检查：

Have you enabled In-App Purchases for your App ID?

Have you checked Cleared for Sale for your product?

Have you submitted (and optionally rejected) your application binary?

Does your project’s .plist Bundle ID match your App ID?

Have you generated and installed a new provisioning profile for the new App ID?

Have you configured your project to code sign using this new provisioning profile?

Are you building for iPhone OS 3.0 or above?

Are you using the full product ID when when making an SKProductRequest?

Have you waited several hours since adding your product to iTunes Connect?

Are your bank details active on iTunes Connect? (via Mark)

Have you tried deleting the app from your device and reinstalling? (via Hector, S3B, Alex O, Joe, and Alberto)

Is your device jailbroken? If so, you need to revert the jailbreak for IAP to work. (via oh my god, Roman, and xfze)

If you answered “No” to any one of these questions, there’s your problem.

If you answered “Yes” for each of these questions and you still have an invalid product ID, then you have a problem I haven’t seen before. Check out the links in the next section, several of which are Developer Forum posts that were especially helpful in my hunt for debugging invalid product IDs.

PS：再使用别人提供的例子代码测试IAP完成以后，这里向你介绍一个别人封装好的类库：ECPurchase

二，验证是否购买成功？

苹果方就很负责的告知:我们的服务器不稳定。真正开发之后，发现苹果方果然是很负责的，不仅是不稳定，而且足够慢。app store server验证一个收据需要3-6s时间。

1.用户能否忍受3-6s的等待时间

2.如果app store server 宕机，如何确保成功付费的用户能够得到正常服务。

对于第一个问题，我们有理由相信用户完全无法忍受，所以采用异步验证的方式，服务器收到客户端的请求后，就将请求放到MCQ中去处理。

对于第二个问题，由于苹果人员很负责人的告知：我们的服务器不稳定，所以不排除收据验证超时的情况。对于验证超时的收据，保存到数据库中并标记为验证超时，定时任务每隔一定的时间去app store验证，确保能够获取收据的验证结果。

在开发过程中，需要测试应用是否能够正常的进行支付，但是又不能进行实际的支付，因此需要使用苹果提供的sandbox Store测试。Store Kit不能在iOS模拟器中使用，测试Store必须在真机上进行。

在sandbox中验证receipt

https://sandbox.itunes.apple.com/verifyReceipt

在生产环境中验证receipt

https://buy.itunes.apple.com/verifyReceipt

在实际开发过程中，服务器端通过issandbox字段标识客户端传递的收据是沙盒环境中的收据还是生产环境中的收据。在提交苹果审核前，沙盒测试均无问题。提交苹果审核后，被告知购买失败，审核未通过。通过查询日志发现，客户端发送的交易收据为沙盒收据，但是issandbox字段却标识为生产环境。

结论：苹果审核app时，仍然在沙盒环境下测试。但是客户端同事在app提交苹果审核时，将issandbox字段写死，设置为生产环境。这样就导致沙盒收据发送到https://buy.itunes.apple.com/verifyReceipt去验证。

那么如何自动的识别收据是否是sandbox receipt呢？

识别沙盒环境下收据的方法有两种：

1.根据收据字段 environment = sandbox。

2.根据收据验证接口返回的状态码

如果status=21007，则表示当前的收据为沙盒环境下收据， t进行验证。

苹果反馈的状态码；

21000App Store无法读取你提供的JSON数据
21002 收据数据不符合格式
21003 收据无法被验证
21004 你提供的共享密钥和账户的共享密钥不一致
21005 收据服务器当前不可用
21006 收据是有效的，但订阅服务已经过期。当收到这个信息时，解码后的收据信息也包含在返回内容中
21007 收据信息是测试用（sandbox），但却被发送到产品环境中验证
21008 收据信息是产品环境中使用，但却被发送到测试环境中验证

先生产验证后测试验证，可以避免来回切换接口的麻烦。测试验证只要用你自己申请的测试appid的时候才会用到，用户不会拥有测试appid，所以不会走到测试验证这一步。即使生产验证出错，应该也不回返回21007状态吗。测试验证通过的用户名，和充值金额最好用数据库记录下来，方便公司资金核对。

三，IAP 审核相关的坑

IAP类型错误

由于我们是按月付费的产品，所以在设置IAP类型时，我没有经验，只是简单设置成了可重复消费(Consumable)的IAP项目。但是我不知道，苹果对于这种按时间收费的产品，应该使用不可更新的定阅（Non-Renewing Subscription）类型。这个类型设置错误造成了我们app的一次审核被拒。

IAP验证逻辑

由于苹果在iOS5.0以下有IAP的bug，使得攻击者可以伪造支付成功的凭证。而iOS6.0的系统在越狱后同样可以伪造凭证，所以我们对于应用内支付，增加了服务器端的验证。 服务器端会将支付凭证发给苹果的服务器进行二次验证，以保证凭证是真实有效的。

在我们公司的测试服务器中，我们会连接苹果的测试服务器（https://sandbox.itunes.apple.com/verifyReceipt）验证。

在我们部署在线上的正式服务器中，我们会连接苹果的正式服务器（https://buy.itunes.apple.com/verifyReceipt ）验证。

我们提交给苹果审核的是正式版，我们以为苹果审核时，我们应该连接苹果的线上验证服务器来验证购买凭证。结果我理解错了，苹果在审核App时，只会在sandbox环境购买，其产生的购买凭证，也只能连接苹果的测试验证服务器。但是审核的app又是连接的我们的线上服务器。所以我们这边的服务器无法验证通过IAP购买，造成我们app的又一次审核被拒。

解决方法是判断苹果正式验证服务器的返回code，如果是21007，则再一次连接测试服务器进行验证即可。苹果的这一篇文档上有对返回的code的详细说明。

IAP上线后的遇到的情况

我们在服务器端增加了验证IAP是否有效的逻辑。在产品上线后，如我们所料，我们收到了大量的欺骗性购买，这些都被我们的服务器识别出来了，但是我们也遇到了以下这次没有想到的情况:

1、由于国内越狱用户的比例比较大(大概为50%),所以虽然我们服务器会验证购买凭证，但是每天有超过50%以上的凭证都是伪造的。同时由于苹果的验证服务器在美国，凭证验证请求响应的时间比较慢，大量的伪造凭证发给苹果服务器，不知道会不会被苹果认为我们是在恶意进行DDOS。至少我们发现有些时候，验证请求会超时。

2、由于国内有许多小白用户，他们的手机从购买时就被渠道商帮忙越狱过了并且安装了IAP free插件。所以对于这类用户，他们即使想付费购买，由于系统原有的IAP支付功能已经被破坏，所以他们是无法正常付费的。麻烦的是，他们会以为这是我们的app的问题，转而给我们的客服打电话投诉。这让我们非常郁闷。

3、苹果的验证服务器有时候会出问题，我们发现本来约定好返回的JSON数据在有几次返回的居然是一个XML格式的文件。造成我们将正常的付费IAP凭证验证失败。所以，在服务器记录下所有的验证凭证非常有必要，一来可以防止黑客多次提交同一个成功凭证的重放攻击，二来在需要时可以手工进行再验证。

越狱手机可能被黑客窃取购买凭证！！

我们发现有一部分用户反馈说已经收到苹果的扣费账单，但是我们从服务器的验证记录看，他上传的凭证却是虚假的。由于这些用户不太多，我们一开始以为是用户在恶意欺骗我们，后来我们让他将苹果的付费账单邮件转发给我们，以及将itunes的购买记录截图转发给我们，我们越来越怀疑这里面有一个黑色的产业链。越狱手机的正常购买凭证可能被黑客的恶意程序截获，具体的攻击方式我们讨论了一下，其实就是被中间人攻击，详细的过程如下:

1. 越狱手机的在被破解后，可能从一些破解渠道安装了黑客的恶意程序。
2. 黑客将越狱手机所有https请求都经过他的中间服务器。
3. 当有支付请求时，黑客先将请求发给苹果服务器，待苹果将成功的凭证返回后，黑客将这个凭证替换成假的凭证，完全支付凭证的偷取。

或许有人会问，这个凭证拿来有什么用呢?很简单 ，因为苹果为了保护用户的隐私，支付凭证中并不包含任何用户的apple id信息，所以我们的app和服务器无法知道这个凭证是谁买的，而只能知道这个凭证是真的还是假的。于是黑客就可以用这个凭证，在另外的账号中通知我们完成了购买，而发来的验证凭证又是真实的，所以我们的服务器就会误认为是黑客的账号完成了购买，继而把会员期算在黑客的账号上。

再举一个简单的例子，你拿500块钱买了顺风优选的500元购物券，由于这个购物券是不记名的，所以顺风优选无法知道是谁买的。如果这个购物券在发放过程中被人掉包，那么偷购物券的人就可以拿这个偷来的真购物券来购物，而顺风优选的卡因为是不记名的，所以也无法查证这件事情。在这个例子中，购物券的不记名和苹果的支付凭证无账号信息是同一个道理。

鉴于以上情况，考虑到越狱手机不但不能成功支付，还会有安全问题，所以我们在新版中取消了越狱手机中的IAP支付功能。

所以，请大家还是不要越狱自己的手机，iphone手机越狱后风险相当大。实在不值得为了免费玩几个游戏就丢掉安全性。

后记

中间人攻击的演示

iOS独立开发者王轲_IndieBros在他的博客文章《使用mitmproxy获取iTunes 11的Raw HTTPs Response》中演示了如何使用中间人攻击来修改Game Center游戏数据。王轲还把我的例子白话翻译了一下（可见我还是说得太绕了，囧）：

坏人在购买过程中插了一腿，换走了用户的无记名发票（购物小票形象些），然后手持无记名小票伪装成真实顾客或者转手出售获利。

关于越狱与盗版

不少细心的同学评论纠正我，指出越狱并不等同于使用盗版。确实，如果说严格的定义，越狱只是让iPhone获得root权限，进而可以做任何事情。如果越狱的同学在越狱后不安装IAP free插件，不使用app sync插件，不使用任何国内的和非bigboss的cydia源，不使用任何盗版软件，所有应用都是从app store官方网站上下载的话，被黑客攻击的可能性会降低一些。

即使这样，由于手机已经被root了，苹果的沙盒安全机制失效，所以风险还是很大的。

关于越狱用户的比例

有同学提出我文章中写的越狱手机比例太高了，想询问数据来源。这个比例主要来自我们自己的app的统计信息，以及结合国内的统计工具友盟的越狱手机比例统计，去年底国内的越狱比例是42%。