最近公司的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.rjkf.cn/apple-pay-iap/