前述：最近刚刚和后台的同事完成了IOS的内购项目功能开发，用以替换之前的支付宝、微信支付功能。这里，梳理出大体的步骤，已经其中踩过的坑。我只梳理了什么事IAP、为什么要用IAP、IAP功能的架构设计、IAP的具体实现代码以及IAP的一些问题

一》 In-App Purchase的相关知识 这里我就不罗列大量的理论了，只谈谈我自己的认识。首先，In-App Purchase功能是用来在IOS生态内，购买App相关产品的功能。每一笔交易，它都会从中提取30%的手续费，也就是说别人为你内购项目支付1元，它要收取0.3元钱。其实，将App Store理解为一个百货商场，那么各家App就是一个个品牌的柜台，而我们的In-App Purchase Products就是柜台里的商品了。这也就解释了，为什么每一笔交易App Store会收取30%的资金：商场提供给你场地、支付渠道，那最终他肯定会有“手续费”要收。个人猜测，最近闹的沸沸扬扬的微信“打赏”功能，估计也与此有关吧，那么庞大的流动资金，无限制的抽取30%，谁也受不了啊。 In-App Purchase功能的开发，既费神也要蒙受收入损失，那么所有涉及支付功能的都需要它么？不尽然。我只说，完全不能绕开它的情况：那就是你的产品是虚拟的，并购买该产品是在使用你的App的一定情境下的必然环节，或者说购买的产品是App环境内使用的，那么你就必须使用In-App Purchase功能。举个例子：我的App里有一篇付费文章，那么我就必须花钱才能在App内看这篇文章，那么这个商品就是必须使用In-App Purchase功能来支付的。那么反过来说，比如“百度外卖”、“膜拜单车”等一系列产品，为什么可以使用非In-App Purchase功能来付费、充值呢？因为外卖也好、自行车也好、金融理财类产品也好，他们或实体商品、或购买的商品，所使用的情景等是在App环境外的，所产生的资金不在平台内，那么这时也就可以使用支付宝、微信、银行卡等第三方API直接开发支付功能了。 更为官方性的内容可以在这里查看：https://developer.apple.com/in-app-purchase/

二》 In-App Purchase开发的准备工作 这里我只说明全过程，重点在架构的设计和开发部分，政策性的过程可以参考以下文章： http://www.jianshu.com/p/86ac7d3b593a 简要来说答题步骤如下： 第一步：创建一个APP ID，注意需要勾选In-App Purchase功能。 第二步：在iTunes Connect的“我的App”里，创建一个App，所使用的APP ID就是刚刚创建的APP ID。 第二步：完善开发者账号的协议、税务和银行业务相关资料。这里网上有很多资料，不再赘述，唯一提醒：把所有资料都要填写，包括联系方式等等。只为什么，后边会说。 第三步：在iTunes Connect的“我的App”里，创建几项App的内购项目，注意地区选择：中国。 第四步：在刚刚创建的App中，内购项目中添加刚刚创建的几项购买项目。 --------------至此，开发前的准备工作就差不多了------------

三》 In-App Purchase功能的架构设计 首先看看Xcode给出的一个开发过程的流程图：

下来，看看Xcode里给出的功能框架图：

大体的过程就是：从我们的Service获取到商品ID ——> 用商品ID向苹果市场请求产品相关信息 ——> 用获取到的商品信息购买商品——>购买成功后获取购买凭证——>讲凭证发回Service验证——>购买成功 总体来说，可归结为下图的详细流程：

*** 如上图所示，已经是一个相当完善的IAP支付流程图了。只是在这里我希望做一点补充：在第9步至14步返回结果的中间，应该先讲App Store返回给客户端的支付凭证做本地保存，然后待14步完成服务端的校验后，再将本地保存的改凭证删除。这样做的好处是，10～13步中间任何校验的环节出现问题，可以重新发送未校验的凭证，这样可更大化的保证用户资金凭证的安全，避免出现误差。至于保存的方式，可以使用单例、本地化持久等等。我的方式是本地单例存储了一个设计的队列，验证成功一条，队列出一条。至于二次校验触发的环节，因人而异，自行设计。如下图：

另注：就像集成AVPlayer一样，我还是倾向于功能模块化，封装起来，做成单独的功能类。这样做的益处非常大，利于日后的维护、扩展等等。加上相应的注解，日后也好维护，自己看着整齐的代码也很舒服啊。我的主要功能如下：

四》代码实现 首先，我们需要在类里引入，并且执行该类的代理

然后集成的步骤就像上边我们梳理的那样，首先我们要根据商品ID向App Store发送请求，用来验证商品是否存在已经它的详细信息

返回结果会呈现在StoreKit代理的函数里

获取到了商品的详细信息，就可以根据该详细信息发起对商品的购买请求了

同样的，查询不存在或网络通信失败等一系列查询失败的函数执行如下代理

发起购买请求，就会开始客户端与App Store之间的往来通信，此时在测试阶段需要使用沙箱测试账号来测试！ 购买的结果，Ios会统一在下边的函数中反馈，状态通过枚举获得：

接下来就是最终交易凭证的验证了，我们的步骤是：获取凭证——>保存——>校验——>删除

接下来的服务端与客户端的校验，就是我们本地的事情了。苹果的功能集成大致如此了。

五》所遇见的问题以及解决办法 1.沙箱测试账号无法登陆App Store的问题 解决方案： a.手机操作系统不可以是越狱版本的 b.手机退出原有账号以后，在测试的过程中直至点击IAP内购按钮以后，等它自己弹出提示框登陆 c.删除测试App，重启手机后重新安装，发起购买请求，填写沙箱账号登陆 d.沙箱账号在创建时的购买区域选中国 e.银行税务账户信息未填写完全 f.沙箱账号是在税务信息填写完整前创建的，无法登陆链接。在完善税务信息后重新创建一个沙箱账号登陆（这一条，很诡异，但是我创建的10个账号，确实是信息完善前的两个没用，其他都可以）。 g.沙箱账号和真实账号冲突

2.调用- (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response时查不到商品信息，或者说产品标识符在invalidProductIdentifiers数组中被退返 解决方案： a.App的App ID和内购项目的App的App ID不对应，请检查 b.App ID没有开启IAP功能。登陆IOS开发者后台，找到改App ID，重新edit，选择上IAP功能后保存 c.在iTunes Connect中，苹果拒绝了你最新向iTunes Connect提交的二进制码。 d.你没有清除iTunes Connect中在售的IAP产品。 e.可能修改了商品，但是这些修改没有在所有App Store的服务器中生效。有时候会有延时，等等再说 f.你的商品由苹果托管上，内容尚未上传至iTunes Connect上。 g.商品的标识符不对。检查传给苹果的标识符和创建的是否完全一致。 h.没有向即将提交的新版本的内购项目中添加已经创建的内购项目。 i.没有填完税务信息。这一条重点说明下，税务信息中，所有的信息都要填写，包括联系方式等等。只要你的信息有一点不完善，IAP的功能就无法测试，你也获取不到商品的信息。

以上就是这次开发的心得了，还是欢迎一起讨论，共同进步涨姿势哈～