a.支付失败。比如手动取消支付、卡里没钱了等。即SKPaymentTransactionStateFailed状态下。
b.支付成功。票据上传给服务器去做校验后，校验返回结果失败。
c.支付成功。票据上传给服务器去做校验后，校验成功。
但是，一般情况下，请求苹果的票据校验接口，都是由App服务端完成的。加密的原始票据，上传给服务器后，服务器再去请求对应的苹果票据校验接口，拿到解密的票据数据。之后，再解析票据合法性，合法后才告知前端并下发道具。这个校验合法性的逻辑，只有前端通过延迟轮询，才能够获得结果。
理想情况下，我们需要在确保商品已经成功发放到用户手中再调用finishTransaction。但因为服务端的校验结果，前端不能马上知道，有些时候因为网络问题，甚至会校验失败。所以我们可以在请求服务器并且回调结果后，就finishTransaction。这样不至于导致充值队列卡住，但却很容易导致掉单。有利有弊。
在发起充值之前，我们会创建SKMutablePayment对象，并添加到支付队列中。
swift复制代码SKMutablePayment*payment=[[SKMutablePaymentalloc]init];payment.applicationUsername=orderId;//透传参数payment.productIdentifier=_productId;payment.quantity=count;[[SKPaymentQueuedefaultQueue]addPayment:payment];其中，有个applicationUsername参数，是一个透传参数。在你添加支付到支付完成获得SKPaymentTransaction后，这个参数都会存在于transaction.payment.applicationUsername中。在开发的实际应用中，我们往往需要将我们自己服务器的订单号、或者用户ID跟苹果的订单关联。我们可以通过缓存读写的形式，但也可以通过applicationUsername这个透传字段来传递参数。比如我们把orderID(订单号)写入透传字段中。我们在创建订单发起支付，到完成支付后，我们都能关联到这个订单。
这个透传字段，看似是非常方便地解决了我们的关联问题。但是，实践中我们却发现，applicationName这个参数在支付完成的回调的时候有可能为nil。以下场景是已经发现的情况：
所以我们可以采用“透传字段+双重keychain”的多重策略。如下所示：
a.尝试从transaction.payment.applicationUsername中读取orderId，如果uid为orderId，则继续下一步；
c.再次尝试从keyChain中恢复orderId，而这个keyChain的值是创建订单时缓存的。
d.在每次启动App和每次发起充值之前，都检查交易队列里是否有没有finished的交易（非订阅的）。如果有则处理这笔交易，重新上传票据给服务器校验。
比如一个商品按钮，被飞速连续点击多次。这时也会调起多次IAP购买。如果不涉及到APP自身的订单的逻辑，充值然后拿到票据校验，苹果一整套逻辑下来是没什么问题的。但是，基本每个APP都会让IAP订单跟自身服务器的订单系统做关联。
如果本地只缓存一个订单号，然后在校验订单请求的时候作为请求参数，在当前情况下，就会导致订单号与实际的receipt_data关联错误的情况；
如果本地通过队列缓存订单，或许能避免上面的情况，但队列的计算也会考验开发者的计算能力，队列内订单判断失误也会导致掉单；
如果通过透传参数applicationUsername传递订单号或者其他信息，又会遇到applicationUsername为空的情况。
当然，办法总是有的，我这里暂时没想出一个完美的处理连续购买商品且能不掉单的方案。相对地，本人更提倡的是，避免“连续购买多个商品”的情况，不让用户触发这种情况。
方法一：一次支付完成之前，只允许一笔订单在支付队列中操作。订单支付完成后，才能发起新的支付。
最简单的方法，就是将按钮enable。但前提是UIKit控件直接触发支付。如果是SDK，或者unity、cocos游戏则不行。
swift复制代码-(IBAction)clickBtn:(UIbutton*)sender{sender.enabled=NO;[[PayKitshareKit]startPay:^(BOOLresult){sender.enabled=YES;}];}也可以采用属性标记，BOOL值。
swift复制代码if(isOrdering){NSLog(@"订单正在支付中...");return;}isOrdering=YES;[[PayKitshareKit]startPay:^(BOOLresult){if(支付完成){isOrdering=NO}}];方法二：用户一点击按钮后就展示蒙版。防止用户再次点击按钮。订单支付完成后，再关闭蒙版。
方法三：设置在1s内，只能调起一笔支付（需搭配方法二使用）
swift复制代码[selfperformSelector:@selector(payPlatformWithModel:)withObject:payModelafterDelay:1.0];-(void)payPlatformWithModel:(id)payModel{[[MaskViewshareView]showView];[[PayKitshareKit]startPay:^(BOOLresult){if(支付完成){[[MaskViewshareView]hideView];}}];}个人建议：防止支付多次触发，建议所有方法都用上。多多益善。
如果开发者并没有采用“屏蔽多次触发支付”的方法，而是支持多笔订单连续调起，通过支付队列去正确匹配订单号与苹果票据的形式（这的确是技术上的正统方法），你就很可能踩到苹果爸爸给你埋的另一个坑。线上环境下可能触发，多笔订单合并付款的情况。比如你点击了6元商品和30元商品购买，苹果会让你输入密码付款36元。付款成功后，苹果只会回调你一个transaction，然后receipt_data解析后in_app内会有两笔支付数据。但对于服务器而言，6元和30元是两笔订单，因为是分别创建的订单。那我到底用那个订单号去匹配票据呢？或许能匹配上其中一个订单，但却很难匹配上两个订单（苹果将app服务器的两笔订单当成1比订单处理了），那势必会导致其中一个订单掉单。你或许可以通过下次启动[SKPaymentQueuedefaultQueue]时去重新校验订单进行补单，或者直接等用户联系客服后进行服务器手动补单。
这个问题没有一个很好的解决办法。所以个人建议还是采用“屏蔽多次触发支付”的方法。
苹果的接口，在线上环境下，即使网络不错的情况，也会出现回调很慢、甚至请求失败的情况。在以下几个情况下，我们会涉及到跟苹果请求：
场景一：通过SKProductsRequest获取商品的时候，请求失败。
建议不通过SKProductsRequest去获取SKPayment对象，而是手动创建，绕过这一步。
swift复制代码SKMutablePayment*payment=[[SKMutablePaymentalloc]init];payment.applicationUsername=orderId;//透传参数payment.productIdentifier=_productId;//商品ID直接传字符串payment.quantity=count;[[SKPaymentQueuedefaultQueue]addPayment:payment];场景二：支付队列addPayment后，并没有调起充值而直接回调"充值失败"；或者在输入密码后由于网络问题回调“充值失败”（实际并没有扣款）。
因为这个时候，这笔订单实际并没有发生任何扣款，所以不用继续这笔订单，可以直接finishTransaction。
场景三：请求苹果接口校验票据失败。
因为票据校验逻辑，是由服务端异步完成的。由上所说，充值成功后最好的finishTransaction的时机，应该是在票据校验成功并且道具（权益）已经下发了，再finish。但有些时候为了避免等待，我们也会在请求服务端去校验，服务端返回receipt_data上传成功时，就会finishTransaction。但后者的情况下，如果在服务器都请求苹果校验接口失败，而客户端已经finishTransaction了，就会导致掉单。这种情况下，服务端应该给这笔订单加上“已付款，未到账”的标识，前端也可以上报一个自定义的日志告诉服务器“这笔订单异常”。在客户端因为提前finishTransaction导致已经无法再次发起校验时，等用户找上客服后，服务端需要根据订单的这个状态进行手动补单。
当我们调用[[SKPaymentQueuedefaultQueue]addTransactionObserver:self]开启支付队列时，支付队列会自动检查是否有没有finish的transaction，并回调给我们。那在哪儿开启这个队列监听合适呢？
swift复制代码[[SKPaymentQueuedefaultQueue]addTransactionObserver:**self**];注意这里是调用addTransactionObserver而不是restoreCompletedTransactions。因为这时候支付队列还没有初始化，直接调用restoreCompletedTransactions是没效果的。
如果有个未结束的交易，会回调这笔交易最新的状态。如果是Pruchasing状态，则输入密码，成功后继续走校验逻辑；如果是Pruchased状态，则上传票据给服务器校验。注意：上面提到的applicationUserName这个透传参数有可能在这种有未结束的交易的情况下为空值，所以注意订单数据要匹配。
swift复制代码[[SKPaymentQueuedefaultQueue]restoreCompletedTransactions];描述同上。
以上的办法，都只是尽量减少掉单的发生，并不能完全解决掉单问题。每个app的逻辑不同，坑也各不相同。掉单之后如何补单？补给那个账号？补给哪个订单？很多问题都需要结合具体问题具体分析。