关于苹果内购(iap)的一些问题以及那些坑

_Unique_ _Unique_     2022-08-03     388

关键词:

最近在研究苹果内购功能,所以,在网上找了一些资料,进行学习。但是,内购功能在实现的过程中,有很多坑,笔者算是真的遇到了好多啊,下面也是自己对内购的一些心得与体会吧!

我这里说的可能不太详尽,所以,我先把再网上看到的一些帖子贴在这里,以便大家做内购的时候,方便查找相关信息。

这里是一篇写的比较全面的帖子,但是没有写中间问题处理: <iOS开发内购全套图文教程>

在网上搜了一些相关的帖子,简单归纳总结了一下,觉得论坛里有一个叫Teng的世界的大神,写了三篇博客,写的很详细:


 【IAP支付之一】In-App Purchase Walk Through 整个支付流程

 

【IAP支付之二】In app purchase 本地购买和服务器购买两种购买模式


 

【IAP支付之三】苹果IAP安全支付与防范 receipt收据验证

大家在做内购之前,推荐看一下!

但是,毕竟我们开发的IAP是在苹果的平台上面运行,所以,如果英语能力好的话,最好去苹果官网无看<官方指南>,里面涉及到了一些论坛的贴子里没有提到过的问题,而这些内容,也很有可能会被大家忽略。下面是<官方文档中文翻译>,可以对照官方文档查看。但有时候还会出现相关的问题。好吧,废话不多说,下面开始说IAP的实现以及具体会遇到的问题,我这里可能会涉及到好多需要注意的问题,流程性的东西会少一些。大家尽量在读本篇博客之前,先把上面的几个博客看一下。

首先,我们要去iTunes store创建几个我们需要在内购中使用到的产品,记住,产品的ID一定要唯一。苹果官方提到了,IAP购买项有几种类型:

  • Consumable products:消耗类产品 

  • Non-consumable products:非消耗类产品

  • Auto-renewable subscriptions:自动更新订阅产品 

  • Non-renewable subscriptions. 非自动更新订阅产品

  • Free subscriptions. 免费订阅产

我们通常再游戏中用到的游戏币属于消耗类产品,赛车轨道等属于非消耗类产品,通常这2种会比较常见。我当时用的是消耗类产品。

当完成产品创建之后,去iTunes store申请一个测试账号,就要开始编写代码了。在编写代码之前,最重要的,是要了解整个内购实现的流程。这里找到了一个比较好的对<流程解说的帖子>,下面是流程图:



归根结底,其实,我们一直在和APP store在打交道,而并不是和苹果的服务器进行打交道,所以,大家要避免这个误区,而APP store才和苹果服务器进行打交道,这一层,其实我们基本是不需要考虑的。

流程:

1.首先,从图上的第一步,客户端向自己的服务器发送了一个请求,请求产品列表,然后,我们自己的服务器会返回给客户端产品的identifiers,也就是我们在创建产品的时候,设置的产品ID,当获取之后,我们需要根据获得的identifiers向APP store请求产品的详细信息。但对于某些应用来说,可能产品种类没有什么变动,所以,就直接将identifiers集成在了应用中,有的是直接放在了plist文件中,需要的时候,直接调用,不需要向服务器发送请求,获得订单信息。但这样也有缺点,当产品发生变动的时候,需要发布新的版本,更新应用才行,所以,不推荐使用这种方案。

2.当获取了产品信息之后,要刷新UI,展示给用户,让用户选择需要购买那种产品,然后点击购买按钮。当用户购买某个产品的时候,我们的APP会向APP store发送购买请求,APP store接收到,购买请求之后,会进行订单的处理,然后,返回给我们购买的结果,同时,从上面的途中,我们还可以看到,返回到客户端有一个receipt data,这个东西其实是用来进行校验的证书(其实是很长的字符串,大概3000多个字符吧),防止有人使用越狱插件,从而反复获取我们的产品,尤其是类似金币这种。

3.当客户端获得购买结果之后,将支付信息(包括验证证书)发送到服务器,服务器向AppStore发起验证,这个验证必须是post请求,将数据以json格式发送过去,同时,receipt要进行base64编码,当苹果确认之后,会给我们返回状态码,告诉我们是否成功。


这是苹果官方给出的集中状态值,苹果返回回来的数据也是json格式的,会有一个state字段,当为0的时候,表示成功,我们测试的接口是:https://sandbox.itunes.apple.com/verifyReceipt,生产环境的接口是:https://buy.itunes.apple.com/verifyReceipt

,所以大家要区分好这两个接口。21007表示将测试环境获得receipt发送到了生产环境,21008表示将生产环境的receipt发送到了测试环境下,其他的返回值,应该都表示验证失败,但是,具体是什么,我也不清楚,英语好的话,可以自己翻译一下,然后,告诉我。这里是<苹果官方验证文档>,大家可以查看这个,写出客户端验证的代码。因为我不是做服务端的,所以不知道怎么写服务端验证,但是,这两者应该是相通的,大家可以在下面写评论,一起讨论一下。

4.当服务器从APPstore获得返回状态后,判断是否有这条购买记录,如果有,就更新服务器端数据库,表示物品已经购买,再给客户端发送购买结果。这里说的APPstore,我再网上找了好多资料,都是这么说的,但我觉得其实就是苹果服务器给提供的接口,只不过为了方便,所以,在画图的时候,就都画成了向APP store发送验证,其实,这里是苹果服务器提供的一个接口。

笔者公司当时用的是RMStore这个开源库,这个用着很方便,所以,大家也可以尝试一下,但不保证完全没有问题,因为我在使用的过程中,其实也遇到了一些棘手的问题。大家也可以自己写支付这个模块,其实,正常的这个流程也不是很麻烦,先把基本流程写完,再考虑可能出现的问题,就会好很多。我在上面引用的几个链接里面,有的链接里面有具体的代码,大家可以参考一下。

用RMStore的话,主要会调用这样一个方法:

- (void)addPayment:(NSString*)productIdentifier
              user:(NSString*)userIdentifier
           success:(void (^)(SKPaymentTransaction *transaction))successBlock
           failure:(void (^)(SKPaymentTransaction *transaction, NSError *error))failureBlock;

 先来说说这些参数吧。首先,第一个参数,这个就是我们获取到的产品的identifier,就是要购买的那个产品的唯一标识;然后是这个user,这个是用户自定义的一个东西,可以是用户的UUID或者其他信息,这个用途很大的。会在后面提到;这里的success  block,实在支付成功后,回调的内容,只要把成功后进行的操作写在里面就可以了,但是,由于成功后,需要的操作也很多,大家一定要把操作封装一下,在里面调用,否则,逻辑会很乱,而且,下面的failure block中还要对很多异常状况进行判断和处理,其中有一个就是“无法连接到iTunes store”,这个问题很麻烦,后面会具体说。一般情况下,如果不考虑user这个变量,可以直接使用下面的方法:

- (void)addPayment:(NSString*)productIdentifier
           success:(void (^)(SKPaymentTransaction *transaction))successBlock
           failure:(void (^)(SKPaymentTransaction *transaction, NSError *error))failureBlock;
这个方法要调用上面的方法,但是user默认为nil。


支付流程看起来就是这样,感觉好像很简单,但是,这里面的问题其实很大。上面只是在一切都正常的状态下,才会走的流程,但是,如果考虑到网络问题、断网、应用闪退,有越狱插件等问题,问题就麻烦了,这个历程,各个过程中需要考虑的问题,其实,还是很多的。好的,下面我们就一步一步开始说IAP实现过程中的各种坑。先重新把上面的图拿过来。

首先来说第一步:



这一步还是很轻松的,我们向服务器获取产品identifiers,由于需要进行网络请求,而且是支付,所以,一定要把断网考虑进来,这个是必须的,那么,在这一步,我们要判断,当没有获取数据的时候,要提示用户暂时没有获取产品列表信息,这部分其实还好,不需要考虑太多。

之后的一些过程,就比较复杂了,考虑的东西也会比较多了。首先把剩下的部分拿过来:


这部分问题很多,而且,需要逻辑也很复杂。首先说第七步,这一部分,再应用中,当点击购买的时候,会弹出输入框,要求输入账号和密码,当点击取消的时候,实际上会调用failure block.调用failure block的时候,会获得一条支付信息transaction和一个error,我们可以判断transaction的相关信息,来判断取消状态,

if (transaction.error.code == SKErrorPaymentCancelled)
也就是判断这个订单信息的error的code值,这个就是取消状态。但实际上,这只是一种比较常见的状态。当用户再购买的过程中,如果在这个过程中,突然断网了,或者请求支付的订单状态有问题,也就是上面的过程⑦出现了问题,就会触发其他的几种状态,这个时候,如果只是输出订单失败的信息,会出现“无法连接到iTunes store”,这是一种很让人头疼的状态,因为,你根本不知道到底是什么问题,到底是怎么无法连接到iTunes store。我当时也被这个问题坑了 ,后来发现,这其实是一种请求失败,和SKErrorPaymentCancelled类似。SKErrorPaymentCancelled和其他几种状态其实是枚举类型:

NS_ASSUME_NONNULL_BEGIN

SK_EXTERN NSString * const SKErrorDomain NS_AVAILABLE_IOS(3_0);

// error codes for the SKErrorDomain
enum {
    SKErrorUnknown,
    SKErrorClientInvalid,               // client is not allowed to issue the request, etc.
    SKErrorPaymentCancelled,            // user cancelled the request, etc.
    SKErrorPaymentInvalid,              // purchase identifier was invalid, etc.
    SKErrorPaymentNotAllowed,           // this device is not allowed to make the payment
    SKErrorStoreProductNotAvailable,    // Product is not available in the current storefront
};

NS_ASSUME_NONNULL_END

属于同一类问题,也就是上面说的无法连接到iTunes store,虽然知道了这几种状态,但是,还是不知道这几种状态到底代表什么。于是就去苹果的开发文档里面看了一下,

Constants
SKErrorUnknown
Indicates that an unknown or unexpected error occurred.

Available in iOS 3.0 and later.
SKErrorClientInvalid
Indicates that the client is not allowed to perform the attempted action.

Available in iOS 3.0 and later.
SKErrorPaymentCancelled
Indicates that the user cancelled a payment request.

Available in iOS 3.0 and later.
SKErrorPaymentInvalid
Indicates that one of the payment parameters was not recognized by the Apple App Store.

Available in iOS 3.0 and later.
SKErrorPaymentNotAllowed
Indicates that the user is not allowed to authorize payments.

Available in iOS 3.0 and later.
SKErrorStoreProductNotAvailable
Indicates that the requested product is not available in the store.

Available in iOS 6.0 and later.

这是官方的解释,可以尝试翻译一下,了解其代表的含义。后来在网上搜索了一下相关的文章,只找到一个,说了<无法连接到iTunes store>,但这里写的几种状态,并没有全部涵盖,后来我在网上又找了一下,下面是我给出的对无法连接到iTunes store的处理:

    if (transaction.error != nil) {
        switch (transaction.error.code) {
                
            case SKErrorUnknown:
                
                NSLog(@"SKErrorUnknown");
                detail = @"未知的错误,您可能正在使用越狱手机";
                break;
                
            case SKErrorClientInvalid:
                
                NSLog(@"SKErrorClientInvalid");
                detail = @"当前苹果账户无法购买商品(如有疑问,可以询问苹果客服)";
                break;
                
            case SKErrorPaymentCancelled:
                
                NSLog(@"SKErrorPaymentCancelled");
                detail = @"订单已取消";
                break;
            case SKErrorPaymentInvalid:
                NSLog(@"SKErrorPaymentInvalid");
                detail = @"订单无效(如有疑问,可以询问苹果客服)";
                break;
                
            case SKErrorPaymentNotAllowed:
                NSLog(@"SKErrorPaymentNotAllowed");
                detail = @"当前苹果设备无法购买商品(如有疑问,可以询问苹果客服)";
                break;
                
            case SKErrorStoreProductNotAvailable:
                NSLog(@"SKErrorStoreProductNotAvailable");
                detail = @"当前商品不可用";
                break;
                
            default:
                
                NSLog(@"No Match Found for error");
                detail = @"未知错误";
                break;
        }
    }


这个SKErrorUnknown实在是很难处理,我找了好多的帖子,包括stackoverflow,也没看到太多的说法,有一些说可能是越狱手机,才会出现这种状态,在测试的时候,我们通常也会遇到这种问题。测试的时候,我们要再iTunes connect申请测试账号,有的时候,测试账号出问题,或者,测试账号已经被取消了,不再使用了,而支付的时候,仍然在使用这个测试账号,这个时候,也会出现unknown状态。

当然,失败有很多种,这是无法连接到iTunes store,不是网络的问题。上面提到失败的时候,会有transaction和error两个返回值,当网络出现问题的时候,error.code是负值。这时,成功的话,没有这个error信息,这时,我们就可以判断到底是怎么回事了,当返回了error的时候,先判断transaction.error是否为空,不为空的话,进行上面的switch判断,为空的话,说明交易的订单信息没有问题,这时候,就只是网络的问题了,就提示用户网络异常。

当我们向AppStore发送了请求之后,如果AppStore交易完成之后,也就是上面的成功的success block,我们首先要将订单信息保存到本地,然后发送给我们自己的服务器,当我们的服务器给我们返回信息的时候,我们再更新UI,同时,删除本地保存的订单信息。这个订单信息,可以保存在数据库中,也可以保存在文件中,但是,苹果建议保存在文件中,用NSCoding进行编码保存,这样会更好一些。

向自己服务器发送消息的话,还要注意很多东西。这里面也包括AFNetworking的一些问题。但我不了解这是不是偶发的事情。当时出现的问题状况是这样的:Error Domain=com.alamofire.error.serialization.response Code=-1016 "Request failed: unacceptable content-type: text/html"

Error Domain=com.alamofire.error.serialization.response Code=-1016 "Request failed: unacceptable content-type: text/html"
我当时还不知道这是怎么回事,后来在网上找了一些资料,才了解到,这是AFNetworking对网络请求的数据类型的一种支持问题,下面奉上一篇帖子,告诉大家怎么解决这个问题:
 

Error Domain=com.alamofire.error.serialization.response Code=-1016 "Request failed: unacceptable con


当出现这种问题的时候,订单信息会无法上传到自己的服务器,这时候,就出问题了,用户已经支付了,钱已经扣了,但是,我们的服务器没有订单信息,所以,无法给用户发货,类似这样损害用户利益的事情是绝对不被允许的。所以,可以按照上面帖子的说法,修改请求类型,添加对text/html的支持,就可以避免这种问题了。此外,当我们自己的服务器出错的时候,当用户打算将订单信息上传到我们服务器的时候,此时,服务器可能会返回一些我们预先设定好的状态码,对于这种状态,我们也要在客户端进行相应的判断,当遇到这样的问题的时候,提示用服务器出错,赶紧联系我们的客服,进行问题的解决。


上面说到,我们向APP store发送支付请求的时候,当支付完成的时候,服务器会将订单返回给我们,这个时候,我们首先应该做的,其实是将订单信息保存到本地,然后,再向我们自己的服务器发送订单信息,当服务器给我们反馈信息,通知我们成功之后,再删除本地保存的订单信息。如果失败的话,我们这里要设置一个定时器,将未完成的失败订单,定时提交到我们的服务器,从而获得要购买的商品。但是,如果一直没有网络怎么办?这是,我们就要在每次应用打开的时候,查询是否有未完成的订单信息,然后将订单信息上传到服务器,从而获得我们要购买的商品。

这种状态处理完了之后,还有其他的一些状态,例如,网络状态不好的状态下,当我们向APP Store发起订单请求的时候,请求成功了,但是,当APP Store给我们返回订单的时候,断网了,或者,此时退出了应用,以及应用闪退,那该怎么办呢?其实,苹果已经替我们想好了这种问题的解决办法。我们只要在应用启动的时候,设置一下代理,就可以了,这是<官方文档>,我们需要在应用启动的时候,设置SKPaymentQueue的代理方法

 [[SKPaymentQueue defaultQueue] addTransactionObserver:self];
并实现代理方法
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Attach an observer to the payment queue
    [[SKPaymentQueue defaultQueue] addTransactionObserver:self];
    return YES;
}
 
// Called when the application is about to terminate
- (void)applicationWillTerminate:(UIApplication *)application
{
     // Remove the observer
    [[SKPaymentQueue defaultQueue] removeTransactionObserver:self];
}
当订单状态发生状态的时候,会异步调用这个方法,从而,通知我们更新订单,并上传订单信息到服务器,给用户发货。如果使用RMStore的话,其实不需要我们手动实现,因为RMstore就是这个observe,所以,在应用启动的时候,我们就应该对RMSotre这个单例进行初始化。

下面来说下面这个方法:

- (void)addPayment:(NSString*)productIdentifier
              user:(NSString*)userIdentifier
           success:(void (^)(SKPaymentTransaction *transaction))successBlock
           failure:(void (^)(SKPaymentTransaction *transaction, NSError *error))failureBlock;
这个方法里里面有一个user属性,是用来用户自定义的字段,当我们发送支付请求的时候,发送这个字段之后,当获取了支付成功的请求之后,这个字段会原封不动的返回回来。当我们用同一个手机,登录了2个不同的账号的时候,这个字段就非常有用了。正常情况下,当我们获得支付订单信息之后,要把订单信息上传到自己的服务器,那么,怎么确定就是是哪个用户呢,默认情况下,我们会把保存在本地的用户账号,也一起返回给自己的服务器。但是,我们假设这样一种状况:我们现在有一个手机,A在上面下单了,订单已经发送给APP store,这个时候,断网了,还没接到APP store反馈回来的支付结果,这个时候,A退出了账号,过了一会儿,有网络了,B登录了,这个时候,如果订单返回了,那么,我们正常状态下,需要把这个订单上传到我们的服务器中。那么,问题来了,我们此时无法或得到下订单的A的用户信息。如果还是按照默认的状态,此时,会把B的账号信息一起发送到我们的服务器,这样,就出错了,A买的东西,没得到,B没有买,却得到了。这是不合理的。所以,我们要在向APP store发送支付请求的时候,一起把下单的用户信息发过去,也就是保存在上面的那个user字段值,当获得APP store的反馈的时候,再将用户信息一起取出来,然后发送到服务器,这样,就不会出现上面说的那种问题了。

以上就是我对最近开发中遇到的一些问题的解决,有不全面的地方和说错的地方,还请大家批评指点。






keep客户端in-apppurchase掉单踩坑指南

简介In-AppPurchase(以下简称IAP)是苹果为开发者提供的应用内购服务。Keep于17年初接入In-AppPurchase,功能上线后暴漏出严重的丢单问题,丢单概率大概在百分之一。丢单问题在多人多次优化后仍未能解决,成为K... 查看详情

uniapp实现ios支付苹果内购支付踩过的坑以及具体操作步骤(代码片段)

由于我们app会员属于虚拟产品,所以苹果商店要求我们必须选择苹果内购,否则就勒令下架。无奈,于是就又开始了踩坑之旅~uniapp可以直接使用uni-pay的插件去进行苹果内购。但是,在对接自己的项目之前,建... 查看详情

关于并发的那些坑儿

1.说一些并发编程的那些话一说到并发,脑子首先冲出来的是啥?复杂,高难度,难调试...总的来说就是——高逼格(逃:的确,并发编程的确不是那么简单的事,初级程序员基本上都接触不到并发,更何况是编程了;但是... 查看详情

flutterios苹果iap(内购)实现步骤及问题总结(全网最全)

参考技术A点击“协议、税务和银行业务”内购用的是付费应用程序,先签署《付费应用程序协议》,同意后状态变更为“用户信息待处理”,等待审核。状态更改完毕后,点击“开始设置税务、银行业务和联系信息”。(1)添... 查看详情

iosiap基本流程.md

...也就是游客状态下也要能购买,不然就耽误苹果赚钱了。关于这个问题有两个解决办法:(1)做游客模式可购买(未登录是绑定设备,下一个账号登录以后绑定账号)(2)必须登录才可以使用app。⚠️⚠️⚠... 查看详情

php苹果支付以及事件通知-周期订阅实现(代码片段)

介绍参考链接https://blog.csdn.net/qq_23564667/article/details/105512349iOS内购(IAP)自动续订订阅类型服务端总结IOS后台需注意iOS的App内购类型有四种:App专用共享密钥订阅状态URL内购流程流程简述服务端验证自动续费调用函数... 查看详情

didnotfindhandlermethodforspringmvc资源文件扫描不到---关于spring的那些坑

今天将项目的spring版本升级到4.2.5版本后,登录首页发现资源文件全部访问不到,页面彻底挂掉;查找原因,后来又查找spring的更新文档后,才确认下来原来是mvc-dispatcher-servlet.xml中静态资源文件的配置写的有问题//下面这个是旧... 查看详情

苹果内购是啥意思?

...appid账户内的钱,需要银行卡充值或绑定信用卡.问题二:苹果手机下载软件app内购买是什么意思?浪费钱吗这个意思是说app里面的道具会需要付费,当然你可以不买道具,或者不在app里面购买其他的东西就可以了,只使用他的免费... 查看详情

apple内购(iap)恢复购买产品在网络问题导致超时情况下的处理

问题现象Apple内购(IAP)正常的交易流程,小伙伴们都能很好的处理。不过正所谓“天有不测风云”,如果在IAP恢复购买时网络信号很差或者干脆没有网络,就会导致App长时间挂起,造成很差的用户体验。如上图所示,我们在App... 查看详情

apple内购(iap)恢复购买产品在网络问题导致超时情况下的处理

问题现象Apple内购(IAP)正常的交易流程,小伙伴们都能很好的处理。不过正所谓“天有不测风云”,如果在IAP恢复购买时网络信号很差或者干脆没有网络,就会导致App长时间挂起,造成很差的用户体验。如上图所示,我们在App... 查看详情

apple内购(iap)恢复购买产品在网络问题导致超时情况下的处理

问题现象Apple内购(IAP)正常的交易流程,小伙伴们都能很好的处理。不过正所谓“天有不测风云”,如果在IAP恢复购买时网络信号很差或者干脆没有网络,就会导致App长时间挂起,造成很差的用户体验。如上图所示,我们在App... 查看详情

ios苹果内购(详细步骤)

参考技术AiOS苹果内购(详细步骤)iOS内付费(in-apppurchase)--非消耗品的购买与恢复恢复购买官方地址苹果内购商品信息获取Unity苹果(iOS)内购接入(Unity内置IAP)#Unity3d发布IOS(包含u3d自带IAP内购)的流程-小白篇(三)-u3d配置ios内购... 查看详情

上线苹果自动续期订阅iap注意事项

...议,并在App专业版购买界面提供相应链接。同时应该提供关于自动续期订单的订购说明。如下:Onceyouconfirmyourpurchase,youwillbechargedtoyourAppleIDaccount.Ifpurchasetheauto-renewingsubscription,unlessyoucanceltheorderatleast24hoursbeforetheendofthecurrentbillingcyc... 查看详情

(转)ios内购(iap)总结

刚刚做了内购,记录一下这里直接上代码,至于写代码之前的一些设置工作参考以下文章:http://www.jianshu.com/p/690a7c68664ehttp://www.jianshu.com/p/86ac7d3b593a需要注意的是:只要工程配置了对应的证书,就能请求商品信息,不需要任何其他处理沙... 查看详情

我为什么要自己编译openjdk8以及那些坑

...openjdk呢,官方不是已经发布了安装包了么?要回答这个问题就要明白cc++是什么?Java又是什么?记得有位业内同行说过,C++和Java之间隔着一堵由内存管理围成的墙,里面的人想出去,外面的人想进来。笔者从业多年确实见过不... 查看详情

在angularjs使用中遇到的那些坑

...然做法趋向于angular2但是实际中还是angularjs1的问题。①,关于radio按钮的使用用遇到一个坑,明明确认数据的绑定ng-model的设定是没有问题的,但是就是无法正常的显示值,radio始终是无法选择的状态。起初我一直怀疑是数据的绑... 查看详情

mongodb那些坑

MongoDB是目前炙手可热的NoSQL文档型数据库,它提供的一些特性很棒:如自动failover机制,自动sharding,无模式schemaless,大部分情况下性能也很棒。但是薄荷在深入使用MongoDB过程中,遇到了不少问题,下面总结几个我们遇到的坑。... 查看详情

深度学习系列关于paddlepaddle的一些避“坑”技巧

  最近除了工作以外,业余在参加Paddle的AI比赛,在用Paddle训练的过程中遇到了一些问题,并找到了解决方法,跟大家分享一下:PaddlePaddle的Anaconda的兼容问题  之前我是在服务器上安装的PaddlePaddle的gpu版本,我想把BROAD数据... 查看详情