一、两种内购模式

（1）内置模式：

1.app从app store 获取产品信息
2.用户选择需要购买的产品
3.app发送支付请求到AppStore
4.AppStore处理支付请求,返回transaction信息
5.app将购买的内容展示给用户

（2）服务器模式：

1.app从服务器获取产品标识列表
2.app从app store 获取产品信息
3.用户选择需要购买的产品
4.app 发送支付请求到AppStore
5.AppStore处理支付请求,返回transaction信息
6.app将 transaction receipt 发送到服务器
7.服务器收到收据后发送到app stroe验证收据的有效性
8.app store 返回收据的验证结果
9.根据app store 返回的结果决定用户是否购买成功
上述两种模式的不同之处主要在于：交易的收据验证，内建模式没有专门去验证交易收据，而服务器模式会使用独立的服务器去验证交易收据。内建模式简单快捷，但容易被破解。服务器模式流程相对复杂，但相对安全。

上述两种模式的不同之处主要在于：交易的收据验证，内建模式没有专门去验证交易收据，而服务器模式会使用独立的服务器去验证交易收据。内建模式简单快捷，但容易被破解。服务器模式流程相对复杂，但相对安全。

开发之初，苹果官方就很负责的告知:我们的服务器不稳定。真正开发之后，发现苹果方果然是很负责的，不仅是不稳定，而且足够慢。app store server验证一个收据需要3-6s时间
1.用户能否忍受3-6s的等待时间
2.如果app store server 宕机，如何确保成功付费的用户能够得到正常服务。
对于第一个问题，我们有理由相信用户完全无法忍受，所以采用异步验证的方式，服务器收到客户端的请求后，就将请求放到MCQ中去处理。
对于第二个问题，由于苹果人员很负责人的告知：我们的服务器不稳定，所以不排除收据验证超时的情况。对于验证超时的收据，保存到数据库中并标记为验证超时，定时任务每隔一定的时间去app store验证，确保能够获取收据的验证结果（针对这做好在哪里finish掉订单）

二、注意事项:

Ios内购防漏单、刷单、订单重复

漏单：

以上流程中可能会出现漏单的情况：当客户端向苹果支付成功后，准备向服务端发起验证，此时若网络发生抖动或者人为退出app等情况，就会出现用户充值成功，但是没加金币的情况。
解决方案：在paymentQueue:updatedTransactions:代理方法中获取到支付成功的回调，此时马上缓存订单信息（包括支付凭证、订单号、用户id等；担心用户卸载app的，可以直接缓存到钥匙串），然后再向服务端验证订单。若订单验证成功，则删除该项订单缓存；否则不做处理。另外，每次app启动的时候，可以延时几秒钟，去检测本地是否有未验证成功的苹果订单；如果有，就一个个重新验证。

刷单：

我们公司的app最早的时候，服务端还是用的Http请求，也没有考虑到刷单这一块，然后被某些用户钻了空子；他们先发起苹果支付，获取一个订单号，然后拿这个订单号和之前支付成功的凭证，向服务端发起验证；然后服务端发现订单号也对得上，凭证也验证有效，就给用户加金币了；用户用同一个凭证不断的换订单号。。。。。
解决方案：首先服务端每次生成的订单号都缓存起来，客户端在请求完订单号后，将该订单号记录在内购订单对象里（赋值给SKPayment的applicationUsername属性）；然后当客户端支付成功后，把订单id和支付凭证传给服务端，服务端先拿凭证去苹果校验，苹果返回的结果中有一个transactionId（跟前面记录的applicationUsername是一致的），这时候服务端判断该transactionId和订单id是否一致，若一致，且该订单id是一个新id，之前没有缓存过；才算是完全的校验成功。

订单重复：

订单重复的情况就是支付成功后，从本地拿到了错误的支付凭证（之前的凭证），去校验的时候，会发现该订单已经完成了。
我这边发现这个问题的情况是这样的：客户端发起苹果支付的时候调用addPayment方法，在paymentQueue:updatedTransactions:回调中获取支付的状态，支付成功、支付失败和重复购买的状态下要结束订单finishTransaction。我当时是支付失败的情况，没有结束订单，然后下次支付成功的时候，获取的支付凭证是上次失败的凭证，然后不仅校验会失败，订单也是重复的

在监听购买结果后，一定要调用[[SKPaymentQueue defaultQueue] finishTransaction:tran];来允许你从支付队列中移除交易。

三、理解定义做好调试

SDK返回关键数据定义

订单号:transactionIdentifier(唯一的,可用作去重)
票据:transactionReceipt(这个就是和发票差不多,基本都是苹果验证通过的已经被舍弃建议使用二进制转义后的encodeStr)
商品信息:tran.payment.productIdentifier (ituns定义的产品名字如:product16_gold)

内购扣款完成点

(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray *)transaction {

for(SKPaymentTransaction *tran in transaction){
```
  switch (tran.transactionState) {
      case SKPaymentTransactionStatePurchased://交易完成
      {}}
```

本地校验地址及相关状态码

在sandbox中验证receipt:
https://sandbox.itunes.apple.com/verifyReceipt
在生产环境中验证receipt:
https://buy.itunes.apple.com/verifyReceipt

苹果反馈的状态码

·21000App Store无法读取你提供的JSON数据
·21002 收据数据不符合格式
·21003 收据无法被验证
·21004 你提供的共享密钥和账户的共享密钥不一致
·21005 收据服务器当前不可用
·21006 收据是有效的，但订阅服务已经过期。当收到这个信息时，解码后的收据信息也包含在返回内容中
·21007 收据信息是测试用（sandbox），但却被发送到产品环境中验证
·21008 收据信息是产品环境中使用，但却被发送到测试环境中验证

总结经验

在集成苹果内购的时候一定要多测试，多调试，我们要全方位考虑各种情况，如在app支付过程中崩溃，人为杀死，付款成功后服务器验证失败没有返回商品，等等。
不过总的原则是，无论您是保存到钥匙串还是通过定时器，还是完成finish的时机，总之只要你不完成finish苹果的支付消息就一直保持在队列里，等待你的finish 。不过要是你因为断点或者其他原因没有finish或者将苹果队列信息干死的话，不好意思，貌似以后你很难接到苹果内购的回调信息了！

苹果内购原理及注意事项,将薅羊毛者关到篱笆外!