最近整了一把苹果内购集成,记录一波。
嘿嘿,以上这些事情统统交给产品。如果没有产品,那就交给老板吧。
如果他们不愿意,和他们说的时候带上这个
苹果内购集成有两个版本:
V1:集成体验差
V2:集成体验不错,有SDK
看起来选择V2没跑了,可是那个劳什子产品说我们的App要兼容iOS14,我直接谢。敢情玩我呢,让我看到了希望,又把我的希望给掐灭了。反思了一下,应该是技术方案评审的时候忘记带谈判神器了,毕竟神器在手,产品只能苟。
棋差一着,只能忍着心里的不痛快,赶紧把思路给搞出来。毕竟老板也想着快点赚钱,要是耽误了老板赚钱,直接降本增笑就难受了。那就继续搬砖吧,先把逻辑给搞一下:
这整套流程执行下来如果都成功,那是相当完美的。这句话的意思是如果有些地方执行不成了,那就完犊子了。相信你也发现了,这里最关键的一步是:【完成交易】。如果这一步出问题,那就是用户给钱了,但没给用户发服务。
这就是著名的苹果内购掉单问题。那怎么破呢?
第一步:穿上西装站直
第二步:弯腰90度
第三步:虔诚地说出:对不起
不好意思,走错片场了。
第一步发现问题:
第二步排查问题:
第三步解决问题:
其实,已经搞完了。。
还有一个问题:苹果的订单怎么和后台的订单对应上?
正常情况下,苹果和后台是通过交易ID关联起来的。但怕的就是不正常的情况。
假设用户购买了一个商品之后,去服务端发放权益的时候失败了。用户以为是App的bug,结果把App卸载重装了,一重装App保存的交易ID可就没了。
这个时候还剩下什么?用户的设备ID,用户的uid和交易凭证。
我们只能在这三个值之间开辟出一条路来的。众所周知,交易凭证不能带任何自定义的信息(applicationUsername这个属性是个坑,别踩),所以抛去一切复杂的逻辑之后,最简单的就是根据这三个值:uid+商品id+购买时间 来寻找一个后台合适的交易挂上(这里不得不淬一口,是真的恶心)
交易凭证验证:
这玩意解析压根就不用token
官方文档:verifyReceipt | Apple Developer Documentation
代码看这个大佬的:Java接入苹果支付 – IAP支付 – IOS应用内支付- 完整版 - Java实战博客 (zanglikun.com)