前言：
近期，项目中用到应用内支付，随之在无任何参考资料的情形下，独上高楼，望尽天涯路！开始应用内支付资料收集，文档阅读，和源码Demo分析等。
应用内支付网上资料甚少，且特老，需总体汇总后准备做一系列文章学习，愿与各位大神切磋技术点滴。
好了，废话不多说了，本篇重点为对应用内支付进行前期的理解，策略为有前人做好的技术分享，能用则用，不能用则参考修改后自己总结学习。
目录：
一.各种支付方式学习以及对应用内支付理解
二.支付申请准备工作
三.苹果三种账户设计学习
四.应用内支付文字版流程梳理
一.各种支付方式学习以及对应用内支付理解
1.各种支付方式有哪些
平时接触比较多的微信支付，支付宝支付，银联支付等；
在iOS平台支付主要分为二类：第三方支付和应用内支付
第三方支付：支付宝，微信支付，京东（包含其他App内的支付等），银联支付等；
应用内支付：包含苹果支付和IAP（内购）。
其中第三方支付之前集成学习过微信和支付宝支付详见下面文章：
应用内支付中的苹果支付和内购支付最大的区别在于购买的物品是真实物品还是虚拟物品：
如人们平时网上购物的衣食电器类的为真实物品，采用苹果支付；而形如，会员，游戏币，订阅网络杂志等虚拟物品采用内购支付IAP。
注意：本系列文章主要讨论IAP内购支付方式。
2.应用内支付理解
IAP全称为In-App Purchase,即为应用内支付方式，苹果设立的目的即因为人家提供平台，我们各位技术人员用技术开发产品，对一些虚拟产品（如会员）抽成30%，不然不让审核通过，霸道的吸血鬼吧！
苹果对虚拟产品定义如上面支付分类，对虚拟产品本身细分为以下四类，解释也很详细，这里就不多说了！
二.支付申请准备工作
1.第一个参考对象如下：
该Demo主要参考到如下第一部分即蓝色区间即可，因为第二部分不是最新的参考无用，第三部分可参考也可不参考，第四部分本篇之后的下篇会封装完整Demo学习。
2.创建内购项目：
进入我们的项目后，按照以下步骤依次点击添加内购产品，注意下面红色框框在第一次还没添加项目时实际是空的哦！
进入下面的界面，注意这里的自动续期订阅请谨慎选择，站在用户的角度考虑是不太合理的哦！
点击创建后来到下图所示页面，依次填上蓝色箭头所指的地方，红色箭头往下的内容暂时可不填，之后点击存储，即完成商品的创建；需要注意的是，上线审核前需要和产品经理沟通以下内容如何填的问题，切记，不然苹果可能无法过审，且不能有测试的字样。
3.添加内购项目测试账号
回到我的App界面，如下图所示：点击对应的用户和职能
进入下面的界面，按照如图顺序点击对应的+号添加
进入下图所示界面，之后全部填写完毕，点击存储即可。
其中如上所示的：
电子邮件可填一个假邮件，
密码一定要复杂些，和AppId的密码设置一样，含有数字，大小写字母和下划线，不然就会出现下面的问题，实测挺坑的。
AppStore地区本来没什么可说的，可是关于游戏分区问题，中国区和其他地方的区就不能是同样的沙盒测试账号，注意！
同理AppStorre Connect 用户创建如下，之后点击下一步按照提示一步步走下去即可，唯一注意的是，这里的邮箱是真实邮箱，切必须是绑定AppId的邮箱，因为添加完成后，邮箱会收到一个验证链接加入
至此，准备工作已全部完毕。
三.苹果三种账户设计学习
原本在很早研究苹果推送时第一次知道苹果为了避免测试环境数据污染线上数据，专门设置了所谓的二种开发模式，开发中的为开发模式，上线后为生产模式；
本次开发中，苹果虽号称是2种模式，实际研究中发现为3种模式，
3.1即上面用户和职能说的比较详细的沙箱技术测试员模式；
3.2即同样为上面用户和职能中的AppStoreConnect用户模式；
3.2为真正通过苹果审核后的线上普通用户模式；
这三种模式有什么注意事项呢？3.1模式一切为假的，如邮箱账号为假，付款金额为假，可以自行测试学习；3.2模式则账号必须为真的，且打包通过ad Hoc模式打包，之后通过TestFlight下载使用，但所付金额依然是假的。嘿嘿，以上2种模式可以好好装土豪了哈！
3.3模式则是面对我们真正的用户，一步步的真金白银付出，当然是在苹果抽走30%后的剩余部分。
四.应用内支付文字版流程梳理
1.支付流程
1.1.支付前
（1）.创建对应的商品，并告诉后台对应的商品Id
（2）.App从后台获取商品列表，埋伏对应的ProductId在每个应用中
（3）.通过ProductId去苹果服务器获取苹果对每个商品的的下单请求
1.2.支付中
（4）.用户点击购买按钮时，调出苹果的支付AppId输入账号密码窗口，输入密码后
（5）.把对应已经下单好的请求数据发送支付到AppStore
（6）.苹果处理支付请求后返回对应的transaction信息
（7）.客户端确认后开始验证
1.3.支付后
（8）.首先拿到transaction信息中的productId是否存在，之后获取本地的receipt字符串去苹果服务器验证
（9）.验证成功后再去我们的服务器验证（本地服务器拿到此信息到苹果服务器验证），此即为双重验证
（10）.最后根据我们的服务器返回结果决定用户是否购买成功，同时我们的服务端要更改对应的字段，比方变成会员或者给用户充对应的游戏币等
2.注意事项：
1.其实第一次研究该支付时，是在用户点击了购买之后才开始下单，支付，双重认证的流程，之后经过具体改进，把下单放在用户点击购买按钮之前就会减少用户等待时间，但又有一个问题，用户假如第一次进来就点击购买，此时还未下单成功，则还会出现下单失败的问题，故而，详情见下篇解决办法。
2.双重认证时，客户端发苹果服务端时返回为0说明是正常支付成功信息，但是返回21002，也要注意是支付成功的信息，只是因为本次支付成功距离上次太近了，有刷单嫌疑而已，故而需要把这种情况考虑进去，都发给后台，其他则按照苹果后台返回的码作相关逻辑即可。
详见以下链接，直接拉到最后即可。
3.支付成功后，用户有时还未来得及验证是否成功，此时网络失败该如何！
这个问题，下面2.4已经描述了对应的解决办法。
4.下单，支付等用delegate（block）回调好还是用通知好些
个人倾向于通知，原因有二：
其一，支付成功后，要更改的地方可能不止该界面，有更多页面涉及，一对多当然用通知；
其二，解决2.3的问题，在遇到支付问题时，下次启动的时候只要设置Appdelegate为观察者，可以在任意页面把比方进入的首页或者登陆页继续验证支付双重认证问题，直到有结果，避免漏单，错单问题。
本篇啰里啰嗦，好像没说到什么重点，原谅好久没写技术文章了，适应下，下篇等待干货支付流程和Demo吧！
