最近在做内购功能， 内购的整个流程比较长，牵扯面很广，要签合同填银行账号税务等，要在后台填商品列表。前面的操作在网上都有很详细的步骤，按照网上的步骤来操作，这部分很快就能搞定，今天主要要说的是在这整个流程中踩到的坑。

1.协议未完全生效，而我未可知，导致调试浪费大量的时间。我做这个功能也是接盘的，别人把前面的配置都配置好了，然后代码层面由我实现，结果在测试的过程中，就是调用不起来内购弹框，可能有很多原因导致了这个问题，但是我从来没有往协议配置方面想过，最后是在无意中发现，原来第一部分就没有过，这部分改好了之后，遇到了下面的问题。

2.内购很经典的问题，掉单问题。为了解决这个问题，我上网搜索了很多资料，想要找到最好的方案去解决，结果是一把血泪史。关于这个问题，主要分了三个部分去解决：

1).将订单信息保存到本地，每次打开app时自动检测本地是否有未完成的订单。我这边为了保证尽量不掉单，所以在服务端未给我返回完成时，这笔订单是不会被finish的，所以每次打开app都会走一个支付未完成的代理，这个大家应该都知道。在每次打开app走这个代理时，会根据系统给到的订单信息匹配本地保存的未完成的订单信息，去服务端进行再次verify， 通过这种模式去保证不掉单。

2).上面那种方式如果遇到支付出问题时还卸载了app，那上面那种方式就没办法保证了，网上给了好几种方案，首先可以写到钥匙串中，好多人都是这种实现的，卸载了之后也不会被删除，但是个人不太喜欢这种方式，从内心一直拒绝。第二种是要服务端配合，在create order的时候透传appstore的商品id， 然后在合适的时机，根据appstore的商品id去请求有无该商品的未完成的订单，如果有，就获取该订单信息进行verify，这种方式总结来说，就是服务端能提供一个接口，让你通过苹果的商品id获取到该商品id下未完成的订单，获取到订单信息就能进行校验了。同时这里还有一个问题，如果有多个订单怎么弄，苹果有个机制，如果一笔相同商品id的订单未完成，下次再次支付不会生成新的订单，会把之前的订单恢复，我目前测试下来是这样，不知道是不是有异常没有考虑到。

   针对第2个case，当时还用了第三种方法，鉴于上面提到的方案都太复杂，我一直希望有一种更简便的方案能解决这个问题。在经过查询之后，发现一个让我踩坑了许久的方案。SKMutablePayment中有两个字段说是可以透传，applicationUsername和requestData。applicationUsername说是可能会丢失，但是requestData不会丢失，我当时看到这个很兴奋，这个发现不就意味着这个问题可能很优雅的解决掉了，我只要把orderId通过requestData透传过去，然后上面提到的方案都可以去掉了。然后我很开心的开始写了，由于我这边项目用了SwiftyStoreKit进行iap的开发，这个库中并没有把requestData暴露出来，为了实现这个功能，我把源码改了，暴露了requestData，然后测试发现真的把orderId透传出来了，我很开心，问题总算圆满解决了。但是，我测试的一直用的ios11.4的手机很正常，用了一个ios12.4的手机测试就一直提示无法连接上itunes connect，因为这个错误之前也经常报，我觉得肯定是其他原因引起的，当时也没有在意，然后就提审了，审核一直不通过，截的图是一直在转圈，转了很长时间提示无法连接。这个时候我感觉有问题了，然后加了很多账号到testflight中下载进行测试，部分手机可以，部分手机就不行，然后我再去仔细看了实现代码，发现SwiftyStoreKit官方给的demo中把大部分的errorcode给吃掉了，统一输出无法连接， 这部分代码当时也没认真看就直接移植过来了。然后通过打印出来的code发现，报的是unauthorizedRequestData，The app is attempting to use SKPayment's requestData property, but does not have the appropriate entitlement，说是非法使用了requestData字段，然后这个错误是从ios12.2才加入的，所以高版本的支付一直报错。估计是苹果发现好多人使用这个字段来透传，但是苹果设置这个字段本意不是如此，才禁了这个字段。

    最后我只能将requestData方案从代码中移除，还好我当时这3种方案都实现了，所以改动也不是太大，移除了requestData透传方案，使用本地保存和服务端配合的方式也能达到尽量不掉单，但是我觉得最好钥匙串中也存一份，做一层校验，这样更保险了，可能还有些未考虑到的case，待补充。主要是那个坑踩的我有点懵，谨以此记。