也说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，还没整理完