IAP接入策略

接入原因

苹果腊鸡,强行收过路费

背景

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,这个孙子也没干什么事情。的确,这东西不是很屌炸天的东西。但是挺琐碎,也挺闹心的。做这样一个小又不全的系统,还是挺有意思的一种体验。每天和这些破解用户,斗智斗勇,也算在浑浊的空气里,一点乐趣吧。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,425评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,058评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,186评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,848评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,249评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,554评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,830评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,536评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,239评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,505评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,004评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,346评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,999评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,060评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,821评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,574评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,480评论 2 267

推荐阅读更多精彩内容