[iOS]贝聊 IAP 实战的订单绑定

大家好,我是贝聊科技
iOS 工程师 @NewPan。

只顾:文章被讨论的 IAP 是凭借以苹果内购购买消耗性的种类。

这次也大家带来自己司 IAP
的实现过程详解,鉴于支付功能的最主要及错综复杂,文章会死丰富,而且付出证明的细节也论及重大,所以这个主题会含有三篇。

第一篇:[iOS]贝聊 IAP
实战的满地是坑,这无异于篇是付出基础知识的教,主要会详细介绍
IAP,同时为会见比支付宝与微信支付,从而引出 IAP 的坑和注意点。
第二篇:[iOS]贝聊 IAP
实战的见坑填坑,这同一篇是高潮性的一模一样首,主要针对第一篇稿子中剖析产生的
IAP 的题材开展具体解决。
第三篇:[iOS]贝聊 IAP
实战的订单绑定,这无异首是重头戏的一律首,主要讲述作者探索用自己劳动器生成的订单号绑定到
IAP 上之经过。

不要担心,我没会只有谈原理不留给源码,我早已拿我司的源码整理出来,你以时仅需要甩到工程中就是足以了,下面开始我们的始末

源码在此地。

作者写了一个深受 iPhone X 去丢刘海的 APP,而且其他 iPhone 也得以打,有趣味的说话去 App Store 看看。点击前往。

直达个别篇稿子曾针对性 IAP
的九独雅之问题吃之八单问题进行了详尽的讲解,如果你未曾爱上一篇稿子,建议您先去看一下再次回到,因为马上三首文章是循序渐进的。上一致首文章解决了第一篇稿子提出的九独问题中之八单,还剩余一个,这一个题目一定重大,所以单独用同一篇稿子来教。

01.为什么这么重大?

到今日寿终正寝,是免是发有所的问题且运筹帷幄,心里有数了?

那么只是是假象,show me the code,编程不是空谈,而是需要亲自动手实践,细节是魔鬼。有各项长辈说:“同样是一个
for 循环,你勾勒于这边就值 5 毛钱,但是本人写在那边就是值 5
万片”。当然这不是投,而是想夸张的抒发编程中细节之严重性。

面前片篇讲话的情早已足以拧起来一个对立谨慎的支付流程了。但是要将所有工艺流程串起来,还不同了第一之均等步,而立即同步并非易事,至少作者走就同一步就是可怜勿易于。

当即无异步是呀也?就是如拿铺服务器生成的订单号 orderNo
绑定到苹果之交易 paymentTransaction
上。第一首稿子中说了,苹果的科班是故一个 product 生成一个
payment,然后将是 payment 推入到 paymentQueue
之中,最后咱们改为市业务的监听者,在监听方法里将到市的
paymentTransaction,我们放上一个苹果的 payment
实例,最后抱的凡一个 paymentTransaction

题目来了,我们最后将到之是一个 paymentTransaction,苹果就告诉我们
哪一个 paymentTransaction
成功了,而我们根本不怕无可奈何拿我们团结的订单号绑定到是成功的
paymentTransaction 上,从而确立映射,正确的去后台验证这个订单。

若将我们好之订单映射到 paymentTransaction
又是得的,下面就是一头来看望这揪心的末尾一步是怎么动之。

02. 堪当大任的 applicationUsername?

自我不信任苹果会并这题目都没有悟出,于是就夺探寻文档, paymentTransaction
里有一个 payment ,这个 payment 就是咱们友好用 product
创建的,但是 payment 的装有属性都是 readonly
的,没法改变。好于发生一个 SKMutablePayment,这个武器的多少属性是
readwrite 的,其中起一个性叫做 applicationUsername

var applicationUsername: String
An opaque identifier for the user’s account on your system.

即是一个 iOS 7 以后才有属性,可以允许我们温馨往 payment
里保存一个字符串类型的数量。

随即不就是正好嘛,我不怕说苹果不容许连这样简单的求都想不顶。好,就用者特性就
OK 了。当用户点击购买之时节,首先去后台生成一笔画交易,然后用到交易订单号
orderNo,然后将以此订单号保存到 payment
上面,然后以苹果支付成功之回调中得到 paymentTransacion,然后由这
paymentTransacionpayment
中将保留之订单号取出来,那么就算能够兑现我们友好之订单号及苹果的订单一一映射,perfect!

作者恰恰起即是按部就班此规律去落实之,直到功亏一篑。

事情是这么的,作者公司的测试发现只要有订单不推入 keychain
中持久化,而是等还开的时段重新失去检查不持久化的交易然后用那推入持久化队列的时刻,就见面来崩溃,从
bugly 后台看到的数额展示,是因取 applicationUsername
的上得到不交。然后自己便连上电脑测试,发现而拿 APP kill
掉,再次去得到前封存之 applicationUsername 的早晚就是
nil。说到底就是是苹果向就没有叫我们怀着进的音讯做持久化,苹果好的特性都发持久化,唯独
applicationUsername 没有。

“鸡肋鸡肋,食之任肉,弃的出股”,形象之抒发了 applicationUsername
这个特性之尴尬。show must go
on
,还是得继续搜寻这至关重要一围绕的解决方案。

03.充分利用 purchasing?

连片下去自己就是尝试,既然苹果不让咱的 applicationUsername
属性做持久化,那能无克我们自己来做吧?

具备的交易都是发出唯一的市标识的,我们如果能将持有的市在 purchasing
状态就抱起来,那么当某笔交易是 purchased
的下,我们就算能因贸易标识为引子去划一堆前封存的 purchasing 状态的
paymentTransaction 中找到相应之市,然后取到我们事先持久化的
applicationUsername。如果这样能够实施得通,那我们就是以会拿任何过程串起来了。

“理想很丰盛,现实非常骨感”。某笔交易状态还是 purchasing
时,支付系统还尚未呢这笔交易分配交易标识,所以即便算是存了,也并未法于那笔交易的状态变成
purchased 时起之前持久化的数量被找到存的数。

本条方案为只好作罢。

04.粗放式验证?

打上述两个尝试还结合苹果后台不对准账的风骨,我们约能体会至,IAP
的规划思想就是是未思量叫咱能用团结的订单关联到 IAP
的订单,这吗称苹果稳定想操纵总体的风骨。

在真的化解方案浮出水面之前,作者规划了一如既往种植“粗放式的证实”来应针对这种困境,下面我们来讲一下啊叫做“粗放式验证”。

咱俩将登 purchasing
的兼具订单还持久化起来,然后此时则没有分配交易标识,但是活标识或有些。等某笔交易到了
purchased 的上,我们为此者 purchased
的市的出品标识去持久化的贸易中将有是是活标识的市且收获出来做一个勤组,然后凭一博一画进行说明,只要说明成功了,就算交易成功。

一经难以明白,那我们就是对正值方这个图来探。我们以好之订单号存到交易里,然后将市存起来,那么和谐的订单号也获了持久化。以后在
purchased
的早晚去得自由一画交易的时光(指定产品标识的),其实取得之是咱们后台生成的随机一个交易订单号(指定产品标识的),然后用已到位的
IAP 交易及我们的订单号拼接成起来进行验证。

这种方案确实是能够及我们作证的目的。但是对于发生洁癖的同学来说,这个方案不得不算是过渡方案,称非齐周到,更讲不达标优雅,所以不得不叫做“粗放式的”。而且发生一个无可奈何避免的问题是,我们怀着的那基本上
purchasing
状态的交易,只有少数会于利用之后去,大多数都是无效的。但是咱又不曾一个关口能去清理是持久化数据,因为我们向得不到知道那个交易是实惠的,哪个是行不通的。所以我们只好全部保存,不敢清理,这样造成这持久化数据更是多,却尚无清理的或是。

05.打破思维惯性

本想清楚了便会见明白,以上之品尝迂迂回回,都是丢失进了思考惯性里了。我们严格遵循了古老的风土人情:先失团结服务器创建订单,再采取
IAP
交易。其实突破点就在这里,我们后端平的一个同事提出,先失苹果那里交易,交易完成之后还失我们自己之服务器创建订单是否可行?

尚记首先首文章被之就张图为?

咱们调转支付流程后,应该成为下面这样。

我无举行说明了,聪明的君得知道者神秘之界别带来的庞然大物的方便。至此,订单绑定得到了优雅的缓解。

06.方案缺陷分析

如是遵循此逻辑来移动的话,有一个格外明白的逻辑缺陷,从 IAP
支付到我们失去后台创建订单是进程发生苹果支付的跟咱们创建订单的延时。现在场面是用户
A 发起了开发,然后还未购就淡出了登录,然后用 B 账号登录了,然后 IAP
支付成功,我们以开发信息存进了盖 B 的 userid 为 key
的账户被,这样就见面招我们去后台验证的时段会拿钱假冒到 B
账户中,如下图所出示。

从而我们当用户退登录的下用去检查外是否来免形成交易,如果生将叫个警示。但是还是无办法彻底解决掉这题目,但是考虑到此结果是用户之一言一行造成的,而且出现这问题之几引领不雅,暂时就这么处理。

假定您确实有立面的担心,那便应该使用地方说之粗放式的证实,粗放式的验证是勿有这个题材之。

自我的章集合

下这链接是我拥有文章的一个会合目录。这些章是涉及实现的,每篇文章中都发出
Github
地址,Github
上还生源码。

本人之篇章集合索引

卿还可关注自己好维护的简书专题 iOS开发心得。这个专题的稿子还是真心实意的干货。如果您生题目,除了当文章最后留言,还得在微博 @盼盼_HKbuy落得叫我留言,以及走访我的 Github。

发表评论

电子邮件地址不会被公开。 必填项已用*标注