苹果应用内购买(IAP)，服务器端开发处理流程

2023-12-15 23:44| 来源: 网络整理| 查看: 265

最近公司的app，提交appstore审核时，被拒了，理由是：必须使用IAP接口支付，除了apple pay的用户使用门槛要比第三方支付要高很多，而且iap接口，要跟apple公司三七分成，也就是用户支付10元，苹果要分掉你3元（服务费）。这跟国内的第三方支付相比较，APPLE这种费率太TM的黑了。

但是没办法，你要上架appstore，你只能使用IAP，这TM就是垄断。

首先要登录APPLE开发者中心：https://itunesconnect.apple.com 设置协议，税务，和银行账户信息。这部分网上都有教程，按着教程来填，虽然有点麻烦，但也不至于太难。其中有一个步骤，是设置购买项目，需要设置：名称，消费类型，价格，ID。例如：

名称类型价格 ID 5币消耗型 1元 rjkf_itemid_1 15币消耗型 2元 rjkf_itemid_2

一般来说，我们的项目都包含和服务器端数据交互，所以大概的流程是这样：

1、客户端首先需要显示充值列表，实际上就是上面这个价目表，我们需要提供一个价目表接口给客户端，这个数据不建议在客户端做死，因为如果我们经常搞一些优惠活动，或者调整价格，这样在服务器端调整价目表就可以了，不需要更新客户端版本。

2、客户端通过用户选择的充值金额，首先向服务器提交订单，服务器生成相应的订单。并将我们自己的订单系统的订单编号返回给客户端。

3、客户端向apple发起订单支付，如果支付完成，这个时候apple服务器，会将订单结果返回给客户端，这里与支付宝或者微信支付有区别，支付宝或者微信支付，都是通过回调的方式，将订单结果通知给我们提供的服务器端回调地址，进行订单处理。但是IAP是直接将支付结果，返回给客户端。

4、客户端收到APPLE返回的receipt-data，然后和第二步生成的订单号，将信息提交给服务器端。服务器端收到receipt-data后，然后到apple server进行验证。官方文档地址：https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-CH104-SW3

apple server提供了两个环境：

//sandbox 开发环境 https://sandbox.itunes.apple.com/verifyReceipt //prod 生产环境 https://buy.itunes.apple.com/verifyReceipt

验证接口参数如下：

需要注意的是：我们在提交app store审核时，apple审核人员实际上是在sandbox环境进行支付测试的，所以，我们在审核时需要单独处理。

验证返回值如下：

首先，根据接口返回的status状态码，如果status=0，表示支付成功，如果是其他的表示有错误，比如上面的步骤中，在appstore审核时的处理，我们可以先提交prod进行验证，如果返回status=21007，然后我们在提交sandbox验证。

这里有一个地方需要注意，在我们开发调试过程中，发现验证结果会返回两种数据格式的返回值：

1、数据格式1

{ "receipt": { "original_purchase_date_pst": "2016-12-03 01:11:01 America/Los_Angeles", "purchase_date_ms": "1480756261254", "unique_identifier": "96f51b28f628493709966f33a1fe7ba", "original_transaction_id": "1000000255766", "bvrs": "82", "transaction_id": "1000000255766", "quantity": "1", "unique_vendor_identifier": "FE358-1362-40FD-870F-DF788AC5", "item_id": "11822945", "product_id": "rjkf_itemid_1", "purchase_date": "2016-12-03 09:11:01 Etc/GMT", "original_purchase_date": "2016-12-03 09:11:01 Etc/GMT", "purchase_date_pst": "2016-12-03 01:11:01 America/Los_Angeles", "bid": "com.xxx.xxx", "original_purchase_date_ms": "1480756261254" }, "status": 0 }

2、数据格式2

{ "status": 0, "environment": "Sandbox", "receipt": { "receipt_type": "ProductionSandbox", "adam_id": 0, "app_item_id": 0, "bundle_id": "com.xxx.xxx", "application_version": "84", "download_id": 0, "version_external_identifier": 0, "receipt_creation_date": "2016-12-05 08:41:57 Etc/GMT", "receipt_creation_date_ms": "1480927317000", "receipt_creation_date_pst": "2016-12-05 00:41:57 America/Los_Angeles", "request_date": "2016-12-05 08:41:59 Etc/GMT", "request_date_ms": "1480927319441", "request_date_pst": "2016-12-05 00:41:59 America/Los_Angeles", "original_purchase_date": "2013-08-01 07:00:00 Etc/GMT", "original_purchase_date_ms": "1375340400000", "original_purchase_date_pst": "2013-08-01 00:00:00 America/Los_Angeles", "original_application_version": "1.0", "in_app": [ { "quantity": "1", "product_id": "rjkf_itemid_1", "transaction_id": "10000003970", "original_transaction_id": "10000003970", "purchase_date": "2016-12-05 08:41:57 Etc/GMT", "purchase_date_ms": "1480927317000", "purchase_date_pst": "2016-12-05 00:41:57 America/Los_Angeles", "original_purchase_date": "2016-12-05 08:41:57 Etc/GMT", "original_purchase_date_ms": "1480927317000", "original_purchase_date_pst": "2016-12-05 00:41:57 America/Los_Angeles", "is_trial_period": "false" } ] } }

这特么也太坑了，返回的数据格式还会不一样？查了一下资料，大概说是：ios7（这个数字可能不对，印象中的，大概就是这么个意思）以前的版本支付和现在的版本支付，去验证时会返回不同的数据结构。WTF，那么作为服务器端，只能先麻烦点，先判断结构中是否包含：in_app，这部分，如果包含就用下面的结构解析，反之则用第一种结构来处理。如果status=0，我们就可以根据客户端提交上来的订单号，将订单状态进行变更了，并将验证结果返回给客户端。

所以，我们这边可以看到，apple的Receipts属于那种不记名，是由客户端提交给服务器端，在由服务器端到apple server进行验证。所以，我们需要在第二步中，先由我们自己生成一个订单，验证时，将订单号也提交上来进行验证。但是，细想一下，好像还有漏洞，比如用户创建2个订单，订单1，充值1元，订单2，充值2000元，如果用户将充值1元，返回的Receipts，然后加上订单2的编号来进行验证，我们去apple server验证，status=0，说明票据是对的，然后根据订单号查询，充值2000元，然后将这个订单状态更改为成功，那不就是用户通过充值1元，骗了2000元的订单么。

这个漏洞怎么破？我们看到apple返回的Receipts中，有一个"product_id": "rjkf_itemid_1"，这个是关键，因为这个是我们在苹果创建的项目价格表的ID，每个ID都是对应一个金额，所以我们看到rjkf_itemid_1是充值1元，特么的你给我的订单是充值2000元，你丫的居然想骗钱？这样就防止了这个漏洞。

至此，充值的步骤就处理完成了，当然高手这么多，我担心业务逻辑还有漏洞，希望你能告诉我。

这个是我的处理逻辑，当然因为有一些隐私性，将部分逻辑写成了伪代码，大家根据自己的实际情况进行处理。

public ResultDto verify(String tradeNo, String receipt){ Recharge recharge = rechargeService.findByStoreTradeNo(tradeNo); //订单不存在 ICheck.notFound.check(!Objects.equal(null, recharge), e -> e.message("[W004]非法的回调请求")); //订单已经成功，不处理 if(Objects.equal(recharge.getStatus(), TradeStatusType.TRADE_SUCCESS.name()) || Objects.equal(recharge.getStatus(), TradeStatusType.TRADE_FINISHED.name())){ return fail("订单已经成功"); } //订单已经失败，不处理 if(Objects.equal(recharge.getStatus(), TradeStatusType.TRADE_CLOSED.name())){ return fail("订单已经关闭"); } //根据不同的环境，选择是去测试环境还是开发环境验证 String verifyUri = VBConfig.isProd() ? VBConfig.getIapProdVerifyUri() : VBConfig.getIapSendboxVerifyUri(); JsonObject obj = new JsonObject(); obj.addProperty("receipt-data", receipt); okhttp3.RequestBody body = okhttp3.RequestBody.create(MediaType.parse("application/json; charset=utf-8"), obj.toString()); Request request = new Request.Builder().url(verifyUri) .post(body).build(); try { Response response = new OkHttpClient().newCall(request).execute(); if (response.isSuccessful()) { String result = response.body().string(); //解析json IapVerifyDto iapVerifyDto = new Gson().fromJson(new JsonParser().parse(result), new TypeToken(){}.getType()); if(iapVerifyDto.status == 0){ //下面是伪代码，说下处理思路 //判断product_id，看返回的product_id与实际的充值金额是不是一致，防止骗单 //将订单更改为成功 return ok(); }else if(iapVerifyDto.status == 21007){ //下面是伪代码，说下处理思路 //验证sandbox环境，主要就是为了appstore审核 }else{ //记录错误日志 } }else{ //记录错误日志 } } catch (JsonSyntaxException e) { //记录错误日志 } catch (IOException e) { //记录错误日志 } return fail("支付失败，请联系客服"); }

作者：陶清清链接：https://www.jianshu.com/p/7e7c3a918946 来源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

【本文地址】

公司简介

联系我们