这是一个创建于 601 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在研究苹果的支付，大概了解了一些文档和接口，想参考下比较成熟的 Apple 内购的后端设计方案
主要是想了解，如何进行后端验证、处理订阅和退单的问题
 |
1
guxingke 2023-05-06 11:16:41 +08:00
1. 没有包袱请务必使用 StoreKit 2
2. 务必请客户端下单时传递后端订单号到 Apple Server 3. 没有 3 |
 |
2
WngShhng OP @guxingke 请问我看到 Apple 的文档里有 Server API 和服务器接受通知，获取下单信息是客户端下单之后上传给自己服务器的还是通过接受来自 Apple 的通知获取的？还有我看很多验证方案是基于 verifyResult 的 API 和收据数据来判断的，如果基于 StoreKit 2 是不是就不应该真么做了？
|
 |
3
nightsky 2023-05-06 12:31:40 +08:00
最好是客户端上传字符串，后端主动去苹果查询，
苹果的推送很蛋疼，有时候可能收不到 |
|
5
nightsky 2023-05-06 14:59:56 +08:00
是啊，支付完成后，不是可以获得两个超级长的字符串么。把 server 的发给服务器，服务器验证去请求苹果那边验证，至于退款问题，可以手动去苹果后台看。这样就非常简单了，适合小规模场景
|
 |
6
codeMore 2023-05-06 16:58:05 +08:00
1 、receipt 去苹果验单后一定要验证 bundle_id 、购买时间、查询 transaction_id 是否退款等
2 、订阅的话，走 server notification v2 吧，关联内部订单的话使用 appAccountToken 做透传吧 |
|
7
WngShhng OP 我现在疑问比较多的是，官方文档里给了很多接口，还有原始的一些接口，但是如何整合这些接口，如果自己设计的话，估计会踩一些坑
|
 |
8
rockyliang 2023-05-06 23:07:27 +08:00
调用苹果的收据验证(verifyReceipt)接口时，要注意判断 in_app 字段，这个数组字段有可能会是空的，这种情况不要给用户发货
|
 |
9
milukun 2023-05-07 20:30:33 +08:00
不想费劲，可以直接使用 Revenuecat 托管，基本达到他的付费标准也是做的不错了，出点小钱也没什么
|
|
10
WngShhng OP @milukun 那还是要学一下的，我有一套自己的付费系统，已经支持谷歌的了，这次希望把苹果的内购整合进去。
|
|
11
WngShhng OP 求人不如求己，先整理了一波文档并调试通过了接口。我梳理的文章：
https://juejin.cn/post/7231858374828048441 |
|
12
WngShhng OP 服务器整体的设计方案： https://juejin.cn/post/7256692501113258041
|
Select Language