针对苹果内购，看了 大量的 其他blog和阅读官方文档才发现，其实 苹果内购服务器做的工作很少，
此文档 写于2018年10月，只针对此时苹果返回的数据结构 内容解析。
基本上所有的 操作都可以再前端完成操作，包括对支付凭证的验证，但是如果在客户端验证凭证可能存在被篡改的危险，
服务器去重验证和加款，是建立在 用户已经在前端支付成功，然后由ios会得到一个字节流，然后 base64后转给 后台。
后台通过这个字符串 去请求苹果的服务器，然后得到一个json字符串去给用户加款，其中注意事项为
//沙箱static final String testUrl = "https://sandbox.itunes.apple.com/verifyReceipt";
//正式 static final String product = "https://buy.itunes.apple.com/verifyReceipt";
请求苹果地址 返回的 内容为
conten-type = application/json
请求的苹果的内容为String param = "{\"receipt-data\":\""+客户端返回的base64+"\"}";
{
"receipt": {
"receipt_type": "ProductionSandbox",
"adam_id": 0,
"app_item_id": 0,
"bundle_id": "com.rtjk.xshl",//当前的产品的包名，一定要验证返回的包名和此包名要一致
"application_version": "2018101001",
"download_id": 0,
"version_external_identifier": 0,
"receipt_creation_date": "2018-10-19 10:50:48 Etc/GMT",
"receipt_creation_date_ms": "1539946248000",
"receipt_creation_date_pst": "2018-10-19 03:50:48 America/Los_Angeles",
"request_date": "2018-10-31 01:58:21 Etc/GMT",
"request_date_ms": "1540951101844",
"request_date_pst": "2018-10-30 18:58:21 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": "6hongliao",//对应产品id，自己做一个金额的映射就行，对应到具体的金额，建议命名要规则
"transaction_id": "1000000460004095",//一定要进行去重验证，一个订单号只能加一次款
"original_transaction_id": "1000000460004095",
"purchase_date": "2018-10-19 10:50:48 Etc/GMT",
"purchase_date_ms": "1539946248000",
"purchase_date_pst": "2018-10-19 03:50:48 America/Los_Angeles",
"original_purchase_date": "2018-10-19 10:50:48 Etc/GMT",
"original_purchase_date_ms": "1539946248000",
"original_purchase_date_pst": "2018-10-19 03:50:48 America/Los_Angeles",
"is_trial_period": "false"
}
]
},
"status": 0, //表示当前请求返回正常
"environment": "Sandbox"
}
为什么要做 product_id，bundle_id，因为 客户端传递过来的 凭证，是不可信的，有可能是别人篡改后的结果。
比如，他们有个自己的内购，我们把这个凭证发到苹果是可以拿到返回结果的，但是 product_id，bundle_id没办法一样。