实战之订单绑定

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

只顾:随笔中探讨的 IAP 是指利用苹果内购购买消耗性的档次。

这一次为我们带来自己司 IAP
的实现过程详解,鉴于支付功效的要害以及错综复杂,文章会很长,而且付出讲明的细节也事关首要性,所以那一个大旨会包含三篇。

第一篇:[iOS]贝聊 IAP
实战之满地是坑
,这一篇是付出基础知识的助教,首要会详细介绍
IAP,同时也会比较支付宝和微信支付,从而引出 IAP 的坑和注意点。
第二篇:[iOS]贝聊 IAP
实战之见坑填坑
,这一篇是高潮性的一篇,紧要针对第一篇著作中剖析出的
IAP 的题材进行具体解决。
第三篇:[iOS]贝聊 IAP
实战之订单绑定
,这一篇是中央的一篇,首要讲述作者探索将自己服务器生成的订单号绑定到
IAP 上的经过。

不用担心,我尚未会只讲原理不留源码,我曾经将我司的源码整理出来,你拔取时只需要拽到工程中就足以了,下边先河大家的内容

源码在这里。

笔者写了一个给 Nokia X 去掉刘海的 APP,而且其他 Samsung 也足以玩,有趣味的话去 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

发表评论

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