内购上线已经一个多月了，一直没有时间做一个总结，因为之后立马又有两个项目要做，现在闲下来，回忆一下内购路上的一些错误认识，避免其他人进坑。关于iap的文章一搜一大把，这里推荐走在路上的小菜鸟 《iOS Apple内购及掉单问题》的一片文章，算是比较到位的，demo的话推荐YZQ_Nine的IAPDemo，所以下面的内容就是以这个demo和《iOS Apple内购及掉单问题》为出发点慢慢说来，关于文章中没有提到的以及demo中的优缺点我下面会讲，陋识拙见，姑且言之，姑且听之。
为什么要做内购
因为博主做的是直播APP，第一版上架是没打算做充值的，打算先上了再说，然而由于是虚拟货币交易，苹果告知必须走内购路线否则不能上架，你有什么办法呢，默默听话叫爸爸，还得30%过路费。
划重点
注意，看本文之前，先看完开头提的那篇文章，本文所写内容是对《iOS Apple内购及掉单问题》的补充，为避免文字啰嗦 以下以《内购》代之，所以不会对《内购》内已经指明的内容有所重复，也就是说你所看到的都是干货。
协议、税务和银行业务
关于协议的填写按照开头提到的那篇文章里的流程走就是了，基本没有问题，这里需要提到的是填写Bank Account Number的时候这个卡号也支持企业名下账号，同样 Account Holder Name 也要填写企业名。
创建APP内购买项目
参考《内购》，
在“我的APP”中把创建好的APP购买项目添加进来，在这个地方有些文章说，它们说要等到APP审核过了之后才能进行测试，其实不用，在“我的APP”中添加成功之后就可以申请sandBox账户进行测试了。
代码集成
这块是重点，在这里我最初的做法是按照demo的思想，也就是下图的流程，见谅一些细节没有体现，
下面的这张流程图是我们在项目中的流程
这两者的区别从图中明显可以看出来，我们在做的时候是没有把交易凭证储存在本地沙河的。因为考虑到用户可能存在的一个情况，在一个设备上使用充值苹果那边成功了，而我们服务端验证没有成功，这个时候，若按照第一种方案，app会把验证凭证存在本地沙河中并且告诉苹果结束这一订单，待下次重新启动的时候，app检测到本地沙河中有交易凭证就会把交易凭证发给自己的服务端。但是，若是用户卸载了app或者使用了其他设备，那么保存在本地的交易凭证就会丢失，用户就无法在我们的服务端验证成功，就需要人工服务介入查询，为了避免这个问题，我们采用第二种方案。
第二种方案做法是我们服务端没有验证充值成功的，就不告诉苹果服务器结束这一订单的状态，也就是不去调用[[SKPaymentQueue defaultQueue] finishTransaction: transaction];
那么在下次启动的时候，苹果会主动告诉你这一单没有结束并且回调给你这一单的状态，我们就可以继续处理这一订单。等于说把有问题的订单交给苹果来帮你保存，这种云端保存省事不少。
《内购》中提到要是想把自己后台这边的交易单号和苹果的交易单号一一对应起来，可以把自己的单号放在交易类SKMutablePayment的applicationUsername属性中，
1 | SK_EXTERN_CLASS_AVAILABLE(3_0) @interface SKMutablePayment : SKPayment |
这样做是没有问题的，但是后来的使用过程中出现过一个问题，那就是，我虽然在请求交易的时候把applicationUsername传了进去，但是会出现某些时候苹果返回给我的交易没有了这个属性，这就比较尴尬了，是个坑，后来我们就不去管这个对应关系了，发起购买的时候我会向服务端请求一个订单，购买结束的时候把交易凭证传到后台，而后台无需去对应，只要这个人有待付款的订单而且productId对的上的话那么当苹果后台验证成功的时候我们就给他充值成功。
添加测试账号
参考《内购》，
有些文章说这些测试账号千万不要在正式环境登录，否则会被注销，bullshit，你根本就登不上好吗。测试之前只需在AppStore中将你的正式账号退出就行，然后在你的app点击充值按钮，会有弹框提示你登录。
另外，使用development证书打包的app都是无法使用正式App Store账号的，也就是说你想测试一下线上的内购就必须审核通过，从App Store下载下来才能测。
测试遇到的问题及解决
前两天测试环境突然验证不了了，苹果付款成功，但是自己的服务端却无法验证成功，原来是苹果默默把字段改掉，之前测试环境返回的类型是“SandBox”，突然变成了“ProductionSandBox”…，所以验证是失败的，无语，不过相信线上不会这么做的。
当有未结束订单的时候，重启APP会走订单监听回调，在这里千万不要APP有问题，比如崩溃😖。。一旦崩溃那么这个用户就再也进不来了，陷入崩溃的死循环中。
欢迎访问我的微博留言：肚子吃撑的杜
