也说iOS的In-app Purchase与Android的In-app Billing

前段日子因为一个项目做了Android上google的支付,然后感慨…原来google 更懂英文 比iOS的好多了


  纵览iOS和Android的支付流程,看起来都是纯纯的面相的客户端,或者说,貌似家大业大不做服务器对接尼们也都得乖乖入我麾下…于是呼,各种蛋疼。对比来说吧。

  • iOS
      iOS的In-app Purchase的安全问题和稳定性一直都困扰着各路开发者和破解者。支付流程作为纯c-s架构(前端-苹果服务器),虽然支付订单是unique的,但是缺少了支付前的s-s(开发者服务器-苹果服务器)unique通信校验,中间的各种问题就层出不穷…
      具体来说,Unconsumable Purchase还好,不仅仅依赖于前端的支付和结束后的订单验证,更提供了支付后的订单存储,因为是不可重复购买,在更换设备,重新下载等操作之后可以使用Restore从果子家服务器重新拉取购买记录,之后执行订单校验即可确保购买成功。但是碰到Consumable Purchase就要抓瞎——果子不提供服务器校验,而购买过程中,在还神奇的添加了 薛定谔的猫 SKPaymentTransactionStateDeferred这是个相当神奇的状态——8.0之前做过iOS测试的童鞋一般都有体会,当使用沙盒测试帐号党土豪买买买时,一不小心就会“卡支付”,不可重复购买却提示已经购买等待下载之类的,查看payment queue里面总是有个正在进行的支付,强行取消就会crash…于是,8.0果子很明智的…把这状态给加上了…“我们不清楚现在是个什么状态,不过您可以等…等我们清楚了告诉您”…测试发现不可重复购买在这种状态下…貌似只能卡住屏幕听天由命,然后在界面上告诉用户,你卡了,请别做任何敏感操作,等果子大爷回话,当然您也可以重启设备刷新,只要您不再下一单别的,您本机上次的订单就没死…当然实在不行请开iTunes截图消费记录吧…于是用户也是要疯。

  • Android
      一直以来,我对Android的感觉都是…二,各种奇葩的操作习惯,各种奇葩的逻辑,各种奇葩的rom…直到试过了google支付,第一次感受到了Android超越iOS的地方。
      先说订单号,和iOS神奇的transaction id与7.0添加的不靠谱的applicationUsername相比,Android有透传订单号这简直是仁慈…在发起支付前就可以对订单号做跟踪,直到订单结束都可以匹配到唯一支付,除了需要手动发自己服务器汇报参数之外简直毫无破绽。接着是Restore,Android没有Unconsumable Purchase,相对应的是consume操作,也就是说,只要您没consume,都可以使用Restore从google服务器要上笔已支付的订单信息!而且透传订单号在手,何愁对不上账?!当初为了处理可重复购买我在前端起sqlite存receipt数据,为了对应帐号和支付订单各种纠结,前端不但存一堆不可靠数据,因为需要发服务器对苹果服务器验证,服务器一环报错之后也是掉单,客服天天吵吵…但是Android,完全可以全靠google服务器Restore确保单笔订单不丢,支付校验完成后再consume可以重复购买,依靠透传订单号确定订单唯一…简直…完美…


* github iOS和Android的demo,还没整理完

你可能感兴趣的:(iOSAndroid,android,ios,支付)