IAP接入策略

作者: 本杰明面瘫 | 来源:发表于2017-08-22 11:27 被阅读0次

    接入原因

    苹果腊鸡,强行收过路费

    背景

    Apple要求 apple store中的有解锁类的功能app,如果收费,都必须走苹果支付(IAP)。

    牢骚

    与苹果进行支付是客户端操作的,我们作为服务端并不参与。

    本文主要是会聊一下,作为服务端,我们要做什么?

    要做什么?

    IAP作为一个接入苹果的支付系统,作为服务端主体的思想是保证资金流转正常,以及资金的完整性。

    做了什么?

    我现在个人理解,当有个技术需求需要我们来解决的时候,首先不要想,我要怎么做。尽量想一下,我要做什么?我们要实现的是一个功能、一个服务、还是一个系统。在做之前想好这个,会帮助你梳理清楚开发的思路。

    将服务端的IAP做成一个系统

    从设计的角度来想,我们与其他业务方在进行合作的时候,原则是互不信任的。也就是说,客户端回传给我的支付状态,对我来说并不可信。哪什么可信呢?———支付凭证

    支付凭证

    客户端每个支付事务,在支付成功后,都会有获得一个支付凭证。这个支付凭证是唯一能够证明用户曾经支付过,并且支付成功的标识。我们接下来所有的工作,都会围绕这个支付凭证,进行展开。

    验证

    由于与客户端互不信任,所以要服务端自己通过验证苹果的支付凭证,从而确定用户是否支付成功。在IAP系统中,有两种验证模式,同步&异步。同步验证,从字面上理解,在获取到客户端回传的数据后,直接对凭证进行验证。异步验证,就是不论你传什么,我都存下来,然后后台起脚本轮询这些数据,从而进行验证。

    优点&缺点

    先说同步验证吧:
    同步验证的优点在于,能够最大限度的保证资金的正确性,只有验证通过才能继续后续的业务流程。

    但是缺点也很明显。由于苹果没有在中国的服务器,导致每一次验证,都会请求到苹果在国外牛逼闪闪的服务器上。我做过分析,在我们有的机器上,请求苹果的验证接口,慢的要死的验证接口,平均请求时间长达3s,通过对这个3s分析,建立请求需要0.8s,苹果这个接口自己要处理1s,返回给我们1s,总体需要3s左右,当然这个也跟网络状态有关。

    同步的意思就是需要用户在客户端支付完成后,再等待我们验证的3s,体验还是不太好。

    再说说异步验证:

    先说优点,优点就在于对整个业务来说,除了用户需要等待客户端与苹果进行支付,并且支付完成后的这点时间,不需要等待其他的时间。简单的说,就一个字.

    缺点:
    这个缺点,就很大了,如果你的业务是解锁类(也就是付完钱就要給用户展示内容)那完全不建议用异步的方法进行验证,你会死的很惨的。你要相信在中国使用破解Iphone的人是很多的,使用内购软件(IapCracker等)的人也是很多的。钱出错了,要背锅。记得要MD5哈。

    异步的意思是,我接收上游传递的所有数据。本地化后,进行验证,补全业务流程。

    如果你的业务场景是,类似充值开通这种实时性要求并不是很高的场景中,异步还是很好的,至少用户在使用你的业务时,效果很好。

    过程

    验证

    简单的说,同步验证会直接在业务流程中,进行验证,如果支付凭证不正确,则直接报错。如果超时等异常情况,则会通过后台的Crontab(补单)进行解决。验证的主要点在于支付凭证,通过调用苹果验证接口,验证这个凭证内部的productid是否属于你的业务,支付时间(美国时间)是否正常。还有一些其他的防刷,防内购的策略,小伙伴们可以自己发挥聪明的脑筋想一想。

    补单

    异步的所有验证凭证并且补全业务形态的行为,都可以称为补单。补单分两种,数据库&日志(上游提供的“可靠性”数据,就是他们的日志!F**K)

    数据库补单很好理解,由于你提供給客户端的是一个同步回调的接口,那么客户端请求一次,我们的数据就会增加一条。如果这个单子在数据中没有进入到最终的状态,OK,那我们就給补上吧。

    日志补单(我也很绝望啊):从客户端的日志中捞出对应的信息,然后,分析其中的相关数据,模拟下单一次。

    退款

    IAP的用户是可以向苹果发起退款的,但是这里面牛逼的是苹果不会通知各个业务方。简单的说,退了就退了,业务方毫不知情。就是这么任性。

    怎么样才算退款呢?还是拿你的凭证,去苹果的凭证验证接口,请求一次,如果在返回的参数中,包含cancellaton_date这个字段,那就是用户退款啦。

    所以需要有个后台的Crontab,去定期的查询下退款的信息,然后更改你的订单状态,这个会体现到性能。退款查询是前一天的,我们假设前一天2w订单,Crontab中,单进程,每个与苹果验证至少要3s,20000*3=60000s,60000/86400约等于0.7天,那就是16个小时啊。所以骚年,多起进程跑吧。现在我起了40个进程,希望机器能够扛住吧。

    结算

    结算真的没有考虑,苹果结算也很任性,一个公司里如果有多个IAP的项目,苹果会给你转几笔钱,你们自己认领下吧。这样就需要IAP在记录的时候,金钱一定要记准啊。这里还没有设计,我理解,可能就是给运营或者财务一个总数吧。

    最后啦

    看到这里,如果你真的看了的话,你会心里面OS,这个孙子也没干什么事情。的确,这东西不是很屌炸天的东西。但是挺琐碎,也挺闹心的。做这样一个小又不全的系统,还是挺有意思的一种体验。每天和这些破解用户,斗智斗勇,也算在浑浊的空气里,一点乐趣吧。

    相关文章

      网友评论

        本文标题:IAP接入策略

        本文链接:https://www.haomeiwen.com/subject/rwokdxtx.html