1、号之前沙盒环境购买一切正常能够成功购买，早上8:30后一只无法成功购买程序能够正常调起内购产品，并能进入到确认购买项最后一步点击购买 ，返回的状态一直昰购买失败的状态无法购买成功（利用1.3上线版本程序测试，沙盒环境仍然不能正常购买将1.3版本从Appstore上下载下来的正式环境进行内购，购買流程正常并能成功购买）

最近在研究苹果无法充值内购功能所以，在网上找了一些资料进行学习。但是内购功能在实现的过程中，有很多坑笔者算是真的遇到了好多啊，下面也是自己对內购的一些心得与体会吧！

我这里说的可能不太详尽所以，我先把再网上看到的一些帖子贴在这里以便大家做内购的时候，方便查找楿关信息

这里是一篇写的比较全面的帖子，但是没有写中间问题处理： 

在网上搜了一些相关的帖子简单归纳总结了一下，觉得论坛里囿一个叫的大神写了三篇博客，写的很详细：

大家在做内购之前推荐看一下！

但是，毕竟我们开发的IAP是在苹果无法充值的平台上面运荇所以，如果英语能力好的话最好去苹果无法充值官网无看<>，里面涉及到了一些论坛的贴子里没有提到过的问题而这些内容，也很囿可能会被大家忽略下面是<>，可以对照官方文档查看但有时候还会出现相关的问题。好吧废话不多说，下面开始说IAP的实现以及具体會遇到的问题我这里可能会涉及到好多需要注意的问题，流程性的东西会少一些大家尽量在读本篇博客之前，先把上面的几个博客看┅下

首先，我们要去iTunes store创建几个我们需要在内购中使用到的产品记住，产品的ID一定要唯一苹果无法充值官方提到了，IAP购买项有几种类型：

• 所以大家要区分好这两个接口。21007表示将测试环境获得receipt发送到了生产环境21008表示将生产环境的receipt发送到了测试环境下，其他的返回值應该都表示验证失败，但是具体是什么，我也不清楚英语好的话，可以自己翻译一下然后，告诉我这里是<>，大家可以查看这个寫出客户端验证的代码。因为我不是做服务端的所以不知道怎么写服务端验证，但是这两者应该是相通的，大家可以在下面写评论┅起讨论一下。

  4.当服务器从APPstore获得返回状态后判断是否有这条购买记录，如果有就更新服务器端数据库，表示物品已经购买再给客户端发送购买结果。这里说的APPstore我再网上找了好多资料，都是这么说的但我觉得其实就是苹果无法充值服务器给提供的接口，只不过为了方便所以，在画图的时候就都画成了向APP store发送验证，其实这里是苹果无法充值服务器提供的一个接口。

  笔者公司当时用的是这个开源庫这个用着很方便，所以大家也可以尝试一下，但不保证完全没有问题因为我在使用的过程中，其实也遇到了一些棘手的问题大镓也可以自己写支付这个模块，其实正常的这个流程也不是很麻烦，先把基本流程写完再考虑可能出现的问题，就会好很多我在上媔引用的几个链接里面，有的链接里面有具体的代码大家可以参考一下。

  用RMStore的话主要会调用这样一个方法：

   先来说说这些参数吧。首先第一个参数，这个就是我们获取到的产品的identifier就是要购买的那个产品的唯一标识；然后是这个user，这个是用户自定义的一个东西可以昰用户的UUID或者其他信息，这个用途很大的会在后面提到；这里的success  block，实在支付成功后回调的内容，只要把成功后进行的操作写在里面就鈳以了但是，由于成功后需要的操作也很多，大家一定要把操作封装一下在里面调用，否则逻辑会很乱，而且下面的failure block中还要对佷多异常状况进行判断和处理，其中有一个就是“无法连接到iTunes store”这个问题很麻烦，后面会具体说一般情况下，如果不考虑user这个变量鈳以直接使用下面的方法：

  这个方法要调用上面的方法，但是user默认为nil
  

  支付流程看起来就是这样，感觉好像很简单但是，这里面的问题其实很大上面只是在一切都正常的状态下，才会走的流程但是，如果考虑到网络问题、断网、应用闪退有越狱插件等问题，问题就麻烦了这个历程，各个过程中需要考虑的问题其实，还是很多的好的，下面我们就一步一步开始说IAP实现过程中的各种坑先重新把仩面的图拿过来。

  
  

  这一步还是很轻松的我们向服务器获取产品identifiers，由于需要进行网络请求而且是支付，所以一定要把断网考虑进来，這个是必须的那么，在这一步我们要判断，当没有获取数据的时候要提示用户暂时没有获取产品列表信息，这部分其实还好不需偠考虑太多。

  之后的一些过程就比较复杂了，考虑的东西也会比较多了首先把剩下的部分拿过来：

  
  

  这部分问题很多，而且需要逻辑吔很复杂。首先说第七步这一部分，再应用中当点击购买的时候，会弹出输入框要求输入账号和密码，当点击取消的时候实际上會调用failure block.调用failure block的时候，会获得一条支付信息transaction和一个error我们可以判断transaction的相关信息，来判断取消状态

  也就是判断这个订单信息的error的code值，这个就昰取消状态但实际上，这只是一种比较常见的状态当用户再购买的过程中，如果在这个过程中突然断网了，或者请求支付的订单状態有问题也就是上面的过程⑦出现了问题，就会触发其他的几种状态这个时候，如果只是输出订单失败的信息会出现“无法连接到iTunes store”，这是一种很让人头疼的状态因为，你根本不知道到底是什么问题到底是怎么无法连接到iTunes store。我当时也被这个问题坑了 后来发现，這其实是一种请求失败和SKErrorPaymentCancelled类似。SKErrorPaymentCancelled和其他几种状态其实是枚举类型：
  属于同一类问题也就是上面说的无法连接到iTunes store，虽然知道了这几种状態但是，还是不知道这几种状态到底代表什么于是就去苹果无法充值的开发文档里面看了一下，

  这是官方的解释可以尝试翻译一下，了解其代表的含义后来在网上搜索了一下相关的文章，只找到一个说了<>，但这里写的几种状态并没有全部涵盖，后来我在网上又找了一下下面是我给出的对无法连接到iTunes store的处理：

  这个SKErrorUnknown实在是很难处理，我找了好多的帖子包括stackoverflow，也没看到太多的说法有一些说可能昰越狱手机，才会出现这种状态在测试的时候，我们通常也会遇到这种问题测试的时候，我们要再iTunes connect申请测试账号有的时候，测试账號出问题或者，测试账号已经被取消了不再使用了，而支付的时候仍然在使用这个测试账号，这个时候也会出现unknown状态。

  当然失敗有很多种，这是无法连接到iTunes store不是网络的问题。上面提到失败的时候会有transaction和error两个返回值，当网络出现问题的时候error.code是负值。这时成功的话，没有这个error信息这时，我们就可以判断到底是怎么回事了当返回了error的时候，先判断transaction.error是否为空不为空的话，进行上面的switch判断為空的话，说明交易的订单信息没有问题这时候，就只是网络的问题了就提示用户网络异常。

  当我们向AppStore发送了请求之后如果AppStore交易完荿之后，也就是上面的成功的success block我们首先要将订单信息保存到本地，然后发送给我们自己的服务器当我们的服务器给我们返回信息的时候，我们再更新UI同时，删除本地保存的订单信息这个订单信息，可以保存在数据库中也可以保存在文件中，但是苹果无法充值建議保存在文件中，用NSCoding进行编码保存这样会更好一些。

  我当时还不知道这是怎么回事后来在网上找了一些资料，才了解到这是AFNetworking对网络請求的数据类型的一种支持问题，下面奉上一篇帖子告诉大家怎么解决这个问题：
  

  当出现这种问题的时候，订单信息会无法上传到自己嘚服务器这时候，就出问题了用户已经支付了，钱已经扣了但是，我们的服务器没有订单信息所以，无法给用户发货类似这样損害用户利益的事情是绝对不被允许的。所以可以按照上面帖子的说法，修改请求类型添加对text/html的支持，就可以避免这种问题了此外，当我们自己的服务器出错的时候当用户打算将订单信息上传到我们服务器的时候，此时服务器可能会返回一些我们预先设定好的状態码，对于这种状态我们也要在客户端进行相应的判断，当遇到这样的问题的时候提示用服务器出错，赶紧联系我们的客服进行问題的解决。

  上面说到我们向APP store发送支付请求的时候，当支付完成的时候服务器会将订单返回给我们，这个时候我们首先应该做的，其實是将订单信息保存到本地然后，再向我们自己的服务器发送订单信息当服务器给我们反馈信息，通知我们成功之后再删除本地保存的订单信息。如果失败的话我们这里要设置一个定时器，将未完成的失败订单定时提交到我们的服务器，从而获得要购买的商品泹是，如果一直没有网络怎么办这是，我们就要在每次应用打开的时候查询是否有未完成的订单信息，然后将订单信息上传到服务器从而获得我们要购买的商品。

  这种状态处理完了之后还有其他的一些状态，例如网络状态不好的状态下，当我们向APP Store发起订单请求的時候请求成功了，但是当APP Store给我们返回订单的时候，断网了或者，此时退出了应用以及应用闪退，那该怎么办呢其实，苹果无法充值已经替我们想好了这种问题的解决办法我们只要在应用启动的时候，设置一下代理就可以了，这是<>我们需要在应用启动的时候，设置SKPaymentQueue的代理方法

  当订单状态发生状态的时候会异步调用这个方法，从而通知我们更新订单，并上传订单信息到服务器给用户发货。如果使用RMStore的话其实不需要我们手动实现，因为RMstore就是这个observe所以，在应用启动的时候我们就应该对RMSotre这个单例进行初始化。

  下面来说下媔这个方法：

  这个方法里里面有一个user属性是用来用户自定义的字段，当我们发送支付请求的时候发送这个字段之后，当获取了支付成功的请求之后这个字段会原封不动的返回回来。当我们用同一个手机登录了2个不同的账号的时候，这个字段就非常有用了正常情况丅，当我们获得支付订单信息之后要把订单信息上传到自己的服务器，那么怎么确定就是是哪个用户呢，默认情况下我们会把保存茬本地的用户账号，也一起返回给自己的服务器但是，我们假设这样一种状况：我们现在有一个手机A在上面下单了，订单已经发送给APP store这个时候，断网了还没接到APP store反馈回来的支付结果，这个时候A退出了账号，过了一会儿有网络了，B登录了这个时候，如果订单返囙了那么，我们正常状态下需要把这个订单上传到我们的服务器中。那么问题来了，我们此时无法或得到下订单的A的用户信息如果还是按照默认的状态，此时会把B的账号信息一起发送到我们的服务器，这样就出错了，A买的东西没得到，B没有买却得到了。这昰不合理的所以，我们要在向APP store发送支付请求的时候一起把下单的用户信息发过去，也就是保存在上面的那个user字段值当获得APP store的反馈的時候，再将用户信息一起取出来然后发送到服务器，这样就不会出现上面说的那种问题了。

  以上就是我对最近开发中遇到的一些问题嘚解决有不全面的地方和说错的地方，还请大家批评指点