苹果内购方案调研

在服务器上验证收据 StoreKit 2 只支持 iOS 15+

1. app客户端请求支付，支付完成，返回服务端的交易id,服务端根据交易id去apple服务器查询交易信息

   1. 返回的该交易信息不确定是否能够判断交易的状态https://developer.apple.com/documentation/appstoreserverapi/data_types

   2. 交易id的获取，客户端是否需要区分ios版本

   3. 接口请求需要生成苹果的JWT令牌（https://developer.apple.com/documentation/appstoreserverapi/creating_api_keys_to_authorize_api_requests）

          官方提供生成JWT的java的sdk库：https://github.com/apple/app-store-server-library-java?tab=readme-ov-file

接口为：https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId}

参考地址：https://developer.apple.com/documentation/appstoreserverapi/get_transaction_history

在服务器上验证收据 StoreKit 2 只支持 iOS 15+

参考地址：https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device#overview

该方法在客户端进行验证收据，暂不清楚服务端如何调用apple服务进行验证收据

https://juejin.cn/post/7256692501113258041

https://cloud.tencent.com/developer/article/1939304

后端实现方案：https://juejin.cn/post/7231858374828048441

详细流程： https://blog.csdn.net/zou8944/article/details/124800989

验签：https://blog.csdn.net/yanyuan904/article/details/121922092

透传参数 appAccountToken ：https://zhuanlan.zhihu.com/p/681131542

购买回调：https://developer.apple.com/documentation/appstoreservernotifications/responsebodyv2decodedpayload

沿用已废弃的方案进行支付（成熟，网上案例很多），端上的StoreKit Original API没有弃用

使用verifyReceipt进行服务端的验证

参考地址：https://developer.apple.com/documentation/appstorereceipts/verifyreceipt

回调参数（重要）： https://www.cnblogs.com/zhaoqingqing/p/4597794.html

退款苹果有向服务端通知的回调，https://cloud.tencent.com/developer/article/2065861

问题

1. ios设备越狱（端上检测越狱设备，一律不准支付）

2. 用户输入完 Apple ID 密码或者验证完指纹支付成功之后，网络突然中断导致 IAP 没有收到支付成功的通知，App 就无法在支付队列的代理方法中获取支付成功的通知，后续的发放内购商品也就不可能了

端上保存支付队列，下次进入时再次查询

https://xiaovv.me/2018/05/03/My-iOS-In-App-Purchase-Summarize/

1. apple服务器延迟较大（因此，如果有条件，建议给App Store服务器的验证请求加上国际代理（比如使用HTTP CONNECT tunneling），降低请求延迟。）

2. 退款的订单

     用户退款过的订单依然会在receipt中出现，因此App服务器实现验证的时候需要能够识别出已经被退款的订单，不至于给退款的订单发货。

     被退款订单的唯一标识是：它带有一个cancellation_date字段。

     服务端验证凭据时，如果有这个字段，则不分发商品。

3. 补单场景，apple订单中有没有商家生成的订单号？

总结：

目前1.0支付的请求，苹果也会回调，即主动通知我们客户端的回调地址，我们拿到transactionId也可以通过2.0验证接口去验证transactionId是否合法。所以，1.0的receipt验证接口直接废弃。

iOS IAP 服务端处理流程

1、SDK服务器接收SDK客户端提交receipt，请求苹果接口验证票据（苹果接口会返回当前票据为沙盒还是正式环境），如环境不一致，则需切换环境再次请求。

2、验证SDK客户端发送请求数据

2.1、验证约定的加密数据

2.2、验证预下单订单号是否已充值

3、验证苹果票据返回接口数据【需特别关注】

3.1、app_item_id、bundle_id、product_id是否与服务器配置一致

3.2、in_app中product_id是否与客户端下单来源请求一致（即某个游戏应用ID）

3.3、判断transaction_id是否已充值

3.4、in_app返回为数组，循环判断transaction_id是否在in_app中。

4、SDK客户端发起的道具ID服务器需验证是否存在，并仅以服务器配置的金额、货币单位为准

5、SDK服务器动态判断当前游戏应用是否允许外币支付（提审时指定版本号开启，审核通过后对外发布前关闭外币支付）

6、风控模型（单账号多设备、单设备多账号、充值及游戏币消耗时地区归属、是否使用外币、是否为常用归属地、退款行为等），国内环境增加第三方设备反欺诈

7、SDK客户端获取到的receipt票据中混合了充值、游戏预注册（正式上线前的预约）、订阅等票据，需要注意区分判断

8、SDK客户端会定时循环监听IAP回调，并建立本地数据库防止SDK服务器充值异常不到账，除当前充值流程中执行多次补单行为外，客户端下次启动会继续监听IAP回调并发起服务器补单

9、SDK服务器存在主备多域名多环境，当主域名多次请求异常为后，开始请求备用域名，并在此过程中将行为日志上报UPS供预警使用

10、SDK服务器接收到充值请求后，即开处理内部逻辑，如游戏服务器无法在同步流程中返回正确的到账信处，则SDK服务器开始建立定时及延时补单策略，当下次SDK再次请求服务器时可返回状态

*只要客户端receipt数据正确，且服务器正确接收到一次消息，则必须保证充值流程正确并到账。

*苹果已开放服务器退款推送，需处理账号退款风险和应对措施：删除游戏币、封禁账号、补款等操作

【iOS IAP支付流程为客户端监听，不存在服务器回调，因此补单需要做到更加完善和严谨】

参考链接：https://juejin.cn/post/7254373662455185469

https://juejin.cn/post/6974733392260644895

https://blog.csdn.net/qq_37896194/article/details/137933425?spm=1001.2101.3001.6650.6&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-6-137933425-blog-115492464.235%5Ev43%5Epc_blog_bottom_relevance_base3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-6-137933425-blog-115492464.235%5Ev43%5Epc_blog_bottom_relevance_base3&utm_relevant_index=7

java接入：https://blog.csdn.net/weixin_45129599/article/details/128802573