流程很简单,简单到险些不用跟业务配景打交代,但是坑却随之而来:
① 支付数据完全依赖前端应用,很难跟业务配景的订单系统逐一对应;
② 针对①的问题,IAP支付支持传递skPayment对象,里面的applicationUsername经常用来保存系统的OrderId;
但是应用支付乐成后收到的回调中,applicationUsername却偶尔会出现为null的情况,没有了对应关系,就没办法核销业务系统中的订单从而为用户充值;
③ iOS支付回调非常不稳定,有时延迟严肃;且没有任何注定查询的方法;
④ iOS应用内支付有很多非常情况要处理,最常见的就是没有登录、没有同意最新的iOS支付协议等,都会发送给app支付失败的回调;
但是当用户登录或是同意后,iOS系统又会触发新的支付,导致旧的附带业务订单号的支付无效,莫名又多出一个没有订单号的新支付;
⑤ 国内网上资料非常缺乏,根本都是19年从前的,Flutter的文章更是少的可怜,可参考性不强。
⑥ 测试文档对于中断购买的测试流程有巨坑,背面菜单一定不要错过~
通过查看文档和不断调试,我们发现:
① 支付错误的回调,根本能马上收到; ② 上面流程说到IAP支付须要手动竣事支付流程。同时iOS规定不能对同一个skuId重复发起多次支付的,只要当前skuId有没有final的支付,再次发起都会失败; ② 无论支付乐成或失败,只要app没有自动对当前支付举行final,每次启动app后,app都会收到这个支付信息的关照; ③ 关于applicationUsername,只有在支付完成马上收到回调的情况下,回调信息才会有这个信息;到②中的情况,肯定不会返回applicationUsername; ④ 没有applicationUsername就意味着订单对不上,因此我们须要举行凑单机制。
综上,我们对非常处理有了确定方案:
① app发起支付后,须要将业务OrderId和skuId举行持久化存储(即卸载应用都不会删除的数据)&#