最近公司的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<IapVerifyDto>(){}.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/
