支付系统设计应用内支付五

　　应用内支付指使用手机操作系统自带的支付功能来支持支付。目前国内主要的应用内支付有GooglePay、ApplePay、小米支付、华为支付等。其中ApplePay是典型的一个应用内支付，Android平台的各种支付也一般是沿用ApplePay的设计。
　　为什么要IAP
　　相对来说，应用内支付的用户体验，和微信支付、支付宝相比，还是有一定差距的，但是为什么要开发应用内支付呢？这个和苹果的AppStore的审核政策有关。在官方的（AppStoreReviewGuidelines）中，有如下几条意见：
　　1。2AppsutilizingasystemotherthantheInAppPurchaseAPI（IAP）topurchasecontent，functionality，orservicesinanAppwillberejected。
　　在App内使用非IAP的系统来购买内容、功能或服务将被拒绝。
　　11。3AppsusingIAPtopurchasephysicalgoodsorgoodsandservicesusedoutsideoftheAppwillberejected。
　　IAP购买实物或者应用外的商品或服务将会被拒绝；
　　11。4AppsthatuseIAPtopurchasecreditsorothercurrenciesmustconsumethosecreditswithintheApp
　　通过IAP购买的积分或者其他货币必须只在App内使用。
　　这问题就来了，如果要购买的服务，即在IOS内使用，也在Android等IOS系统外使用，那应该是使用规则11。2或者规则11。3来执行？比如说视频网站，视频既可以在IOS上看，也可以在Android上看，那是否是需要通过IAP来购买？苹果公司在这一点上采取模糊的策略。爱奇艺、腾讯视频，在IOS上购买会员，只能用IAP支付。这就和苹果公司的审核有关。
　　IAP支付流程
　　一般IAP支付的开发流程，首先需要一些准备工作，包括：
　　在developer。apple。com上配置一个AppID，使用该ID生成和安装相应的ProvisioningProfile文件。
　　登录到iTunesConnect，使用AppID创建一个新的应用，在该应用中，创建应用内付费项目，设置好价格和ProductID以及购买介绍和截图。
　　添加一个用于在sandbox付费的测试用户，填写相关的税务，银行，联系人信息。
　　完成这些准备工作后，既可以进入正式的开发，开发代码我们这里就不说了，流程如下：
　　用户选择要购买的内容并点击购买按钮；
　　用户通过AppStore账户验证
　　苹果服务器验证用户请求
　　苹果服务器从用户帐号扣款
　　苹果向用户返回购买成功信息
　　软件接收并显示用户购买信息
　　老司机都能看出来，这里有好多好多的坑。
　　用户访问AppStore时使用的是Apple的账号，不是应用系统的账号。也就是说，我们并不知道到底是谁在购买这个内容。比如在应用中有两个账号A和B，用A账号登录后，上IAP买了东西，然后用B账号来登录，也上IAP买东西，这两次购买，用的是同一个Apple账号。苹果也不会告诉你，到底是哪个账号付了钱。账号坑在单次购买中还没什么问题，但碰到订阅的情况，得好好处理下。在订阅章节中会详细说明。从上述流程可以看出，苹果服务器都是和客户端打交道的，这里面似乎没有应用服务器什么事情。只有在客户端接收到苹果返回信息后，才可以把这个信息转发给应用服务器。如果用户一直不打开手机上的应用，那应用服务器就一直收不到通知了。好在后来苹果提供了一个验证功能，应用服务器可以把接收到的返回信息（加密后的字符串）发送给苹果服务器来验证和解密。
　　IAP订阅
　　IAPSubscription又是一个大坑。官方的文档在这里。内容不多，没有说明的东西却很多。
　　续费周期的计算
　　IAP主要提供给周期性订阅的音乐、电子书等内容使用。一般就按月来计算周期。苹果是以自然月来算权益周期。比如在1月3号买了权益，到2月3号，这个权益就过期啦，需要在此之前完成续费。那问题来了，1月31号买的权益，到几号过期？以自然月算，这个权益会在3月1日前到期，如果2月份，3月份都续费了，到4月份，也是享受到4月30日了。
　　自动续费
　　应用开发应该不需要关心续费的细节。苹果会做自动处理。在权益到期前10天，苹果检查用户账户是否可以扣款，商品价格是否有变动。在权益到期前24小时，苹果开始扣款，如果失败，会多次重试，直到成功。问题来了，这个重试，会延续到用户权益过期后一小段时间，苹果没有说这段时间该算是有权益还是没有，但开发人员需要注意应该如何处理。
　　免费试用
　　免费试用不是强制需求，但这有利于用户判断是否值得购买这个物品。免费试用期是在itunesconnect中设置。当用户第一次购买这个东西的时候，客户端接收到的Receipt中包含免费试用信息。在免费期快到的时候，苹果发起第一次扣款。整个过程和自动续费类似，唯一区别是第一个月是免费的。
　　Receipt验证
　　客户端接收到Receipt之后，需要提交到服务器端进行处理，开通权益。这就来了个问题：Receipt应该在客户端还是服务器端解析？当然需要在服务器端处理，这样可以防止越狱后的一些插件，如IAPCracker、IAPFree等伪造交易凭证，欺骗苹果服务器，开通权益。此外，还需注意，客户端和服务器端之间需通过HTTPS以及参数签名等方式来确保通讯安全。服务器端接收到Receipt之后，首先验证请求的有效性，然后将Receipt发送到苹果服务器上进行验证和解析。接收到苹果处理结果后，将Receipt中的userid，productid、purchasedate、transactionid等做验证和处理。
　　IAP破解和防御
　　既然Iap的验证主要是在苹果服务器端和手机客户端进行，并且是使用域名。这简直是为攻击打开了一扇大门，而不仅仅是漏洞。早期的IAP内购解锁工具IAPcracker对IAP的破解比较简单粗暴。写过IAP程序的人都知道，程序中基本都是用transactionState来判断交易是否成功。
　　transactionState有四个状态：
　　SKPaymentTransactionStatePurchasing
　　SKPaymentTransactionStatePurchased
　　SKPaymentTransactionStateFailed
　　SKPaymentTransactionStateRestored
　　SKPaymentTransactionStatePurchased表示购买成功了。只要修改这个变量值，如果客户端应用直接根据交易状态来处理业务流程，那就会收到这个假的交易成功信息，接下来用户就能不花钱得到所买的物品。这个过程，甚至都不需要接入网络。
　　另一个工具IAPfree功能更强大，安装使用也复杂很多。它是通过修改DNS，让客户端访问黑客提供的服务器来取代访问苹果服务器，实现所谓的MITM中间人攻击。当用户在客户端触发购买流程时，会被引导到伪装的苹果服务器上，不扣款而直接返回扣款成功收据。用户不需要支付任何资金，客户端能够拿到完整的收据。如果是在客户端处理收据验证也没有任何问题。为了避免用户所使用的设备被封，这些软件甚至可以提供伪造UDID的功能。为此，苹果特别说明，一定要在服务器端验证用户购买信息，验证内容包括收据签名，证书，产家信息等，确保收据无误后，才能授予权益。如果发现有诈，则将用户拉黑。
　　两套账户体系
　　苹果支付的账户体系，当然是以appleid为基础的，它允许用户在多台设备上共用一个账户。一台设备上，一般只有一个激活账户。但对应用系统来说，大部分是允许多个账号登陆的。这对续费来说就是个大问题。用户以账户a登录后，发起续费，获得权益。然后以账号B登录了，显然，A的权益不会衍生给B。过几天A开始续费了，续费之后，切换到B账号登录，客户端在B账号登录时得到续费的收据并发送给应用服务器。那这算是谁的续费请求？当然是A的。在这个appleid发起的续费请求，所有的收据都会有一个相同的原始交易号originaltransactionId。在用户发起订阅时，需要记录这个id和账号的关系，每次续费，需要在解析收据后，根据原始交易号从这里获取真正的充值账户，不能从客户端提交的用户id作为凭据。
　　还是这个坑，如果在账户b登录后也发起订阅请求，会怎么样？这个调用将会失败，所以需要阻止用户发起这样的请求。或者设置多个产品副本来让用户购买。
　　分成，定价和国际化
　　在iTunes中的给的产品定价必须是税前的，苹果和商家的分成，也是按税前算。商家给出在一个主要销售国家和地区（比如国内的基本就是中国了）的价格，即基准价格。在其他地区的销售价格，苹果会自动根据当前的汇率来换算成当地的货币。当然，也可以自己修改设定在这些国家或者地区的当地价格。目前是支持到155个国家。还要特别注意版权问题。
　　基准价格调整，如果是往高了调整，则在用户下一次续费时，需要用户确认。如果往低了调，那就不需要用户确认，直接扣款了。
　　苹果对商家的产品价格体系有分组（Group）的概念，同国内说的价格体系，比如白金会员、黄金会员、贵宾等，在同一个Group里面，用户只能选择一个档，比如用户要么是白金要么是黄金会员，不会同时是。
　　在同一个分组中，如果用户订阅时间超过一年（365天），则商家可以得到来自这个用户收益的更多的分成，目前是85。这个订阅时间不包括免费试用期。同时可以有60天的宽限。也就是说，这一年中，如果用户曾经停止续费，然后又开始继续续费，只要中间不续费的时间不超过60天就行。
　　更多的坑
　　目前用的是IOS10。0版本，这个版本和IAP有关的坑，先记录下：
　　沙盒环境，没法做取消订阅操作。只能在线上模拟。所以产品设计和开发时，尽量不要依赖取消订阅操作，也应该不依赖于这个操作。
　　沙盒环境下，有些receipt可能会收不到transactionid，线上的暂未发现这个问题。
　　苹果提供单个收据和列表收据两种格式。推荐使用列表数据，但问题是，这个列表收据的长度，苹果也不知道最多会有多少。
　　AndroidIAP
　　好吧，用这个话题作总结，不是太好。IOS上用苹果支付是被逼的，android上用IAP是图什么？支付宝和微信支付有这么多用户基数，接入也很方便，费用比IAP便宜多了。如果你有接入androidIAP经验，期待分享。
　　相关阅读
　　支付系统设计：支付系统的账户模型（一）
　　支付系统设计：对账处理（二）
　　支付系统设计：银行卡支付（三）
　　支付系统设计：绑卡、签约和身份验证（四）