想抄作业了，有没有 Apple 内购的后端设计方案

1. 没有包袱请务必使用 StoreKit 2
2. 务必请客户端下单时传递后端订单号到 Apple Server
3. 没有 3

@guxingke 请问我看到 Apple 的文档里有 Server API 和服务器接受通知，获取下单信息是客户端下单之后上传给自己服务器的还是通过接受来自 Apple 的通知获取的？还有我看很多验证方案是基于 verifyResult 的 API 和收据数据来判断的，如果基于 StoreKit 2 是不是就不应该真么做了？

最好是客户端上传字符串，后端主动去苹果查询，
苹果的推送很蛋疼，有时候可能收不到

@nightsky 上传的字符串是指收据吗？

是啊，支付完成后，不是可以获得两个超级长的字符串么。把 server 的发给服务器，服务器验证去请求苹果那边验证，至于退款问题，可以手动去苹果后台看。这样就非常简单了，适合小规模场景

1 、receipt 去苹果验单后一定要验证 bundle_id 、购买时间、查询 transaction_id 是否退款等
2 、订阅的话，走 server notification v2 吧，关联内部订单的话使用 appAccountToken 做透传吧

我现在疑问比较多的是，官方文档里给了很多接口，还有原始的一些接口，但是如何整合这些接口，如果自己设计的话，估计会踩一些坑

调用苹果的收据验证(verifyReceipt)接口时，要注意判断 in_app 字段，这个数组字段有可能会是空的，这种情况不要给用户发货

不想费劲，可以直接使用 Revenuecat 托管，基本达到他的付费标准也是做的不错了，出点小钱也没什么

@milukun 那还是要学一下的，我有一套自己的付费系统，已经支持谷歌的了，这次希望把苹果的内购整合进去。

求人不如求己，先整理了一波文档并调试通过了接口。我梳理的文章：
https://juejin.cn/post/7231858374828048441

服务器整体的设计方案： https://juejin.cn/post/7256692501113258041

@WngShhng appAccountToken 是使用我们 app uid 生成 uuid 还是用 order_id 生成 uuid ？