苹果内购服务器验证凭证回执Data

基本上所有的 操作都可以再前端完成操作，包括对支付凭证的验证，但是如果在客户端验证凭证可能存在被篡改的危险，

服务器去重验证和加款，是建立在 用户已经在前端支付成功，然后由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"

}

iOS苹果内购(详细步骤)

iOS 内付费（in-app purchase）－－非消耗品的购买与恢复

恢复购买官方地址

苹果内购商品信息获取

Unity苹果(iOS)内购接入（Unity内置IAP）

# Unity3d发布IOS(包含u3d自带IAP内购)的流程-小白篇(三)-u3d配置ios内购部分

每次支付行为或每笔交易被认为是一个SKPaymentTransation，只有当SKPaymentTransation被finishTransaction:，这次支付（交易）行为才算是正常结束了。即使这次支付途中被中断，其实也并没有丢失。假设支付没有完成 App 就退出了（比如崩溃），那么当下次 App 重启之后，只要设置了监听addTransactionObserver:，之前被中断的支付就会接着进行。

第1步，这个过程中 App 进程因为某种原因被 kill 了，其实支付行为还在系统后台进行着，苹果自己做的，很有可能扣款成功。但是这时候没法为用户充值虚拟货币。

第2步，App 端与自己服务器端通信失败；自己服务器端与 AppStore 服务器之间的通信失败。

针对第一种情况，可以在 App 一启动就设置监听，如果有未完成的支付，则会回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions这个方法，在这个方法里调用接口充值。

至于第二种情况，App 端需要做接口重试，设置一个重试的逻辑。

在发起支付请求之后，苹果返回商品列表，先请求服务器下单接口，成功之后，将订单信息保存在钥匙串，然后发起支付，在支付状态的回调当中， 成功了就去做服务器的验签操作，验证成功，关闭事物，并将订单信息删除，支付完成

app启动时监听掉单情况， 如果有掉单情况，回走事物更新的回调，然后再回调里，通过钥匙串拿出订单相关信息，然后获取支付凭证，重新向服务器发起验单的流程。

钥匙串保存订单信息作用：为了拿到订单的相关信息作为参数来请求服务器验签接口。

---