App Store从 CONSUMPTION_REQUEST 到守住的收入
在 App Store，Apple 会先问你再决定
Apple 在退款上格外宽松，大多数退款根本不给你表达意见的机会就通过了。但在消费请求上，Apple 会停下来询问退款是否合理，发送一条签名通知并等待你的回应。错过这个时限，退款就默认获批；回应得当，你赚到的收入就留得住。
Refund Sensor 从不错过这个时限。它还会记录那些 Apple 自行决定的退款，而这恰恰是大多数团队完全看不见的部分，于是你终于能看清 iOS 收入流向哪里、从哪些商品漏出去。
App Store 退款抗辩所需的一切
签名通知验证
每一条 App Store Server Notification V2 在接触你的数据之前，都会针对 Apple 的证书链做 JWS 验证，任何伪造都进不来。
自动拒绝消费请求
当 Apple 开启一个消费请求时，我们会在 Apple 的时限内通过 App Store Server API 提交带有你拒绝意见的消费响应，无需任何手动步骤。
完整的退款生命周期跟踪
退款、拒绝、撤回和撤销都会被捕获并与交易对账，静默的后台退款再也不会被漏掉。这些由 Apple 自行决定，因此我们记录而不是抗辩。
一个后台管两大商店
App Store 案件与你的 Google Play 案件并列，拥有相同的时间线、成功率分析和守住收入的报表。
无需改代码
所有流程都通过 App Store Connect 和 Apple 的服务器 API 完成。没有东西要加进应用，也没有版本要重新提交审核。
加密的最小权限访问
你的 App Store Connect 密钥在静态存储时加密，且仅用于验证通知和回应退款请求。我们不收集任何用户个人数据。
开始之前
App Store Connect 权限
管理该应用密钥和服务器通知的权限。
一个应用内购买 .p8 密钥
以及对应的 issuer id 和 key id。
在 Apple 后台花五分钟
这就是全部的接入工作量。
从接入到首次抗辩退款，约 5 分钟
五个步骤，其中只有两个在 Apple 后台完成。
- 1
添加你的应用
在接入向导中选择 App Store。粘贴你的 App Store 链接可自动填充应用信息，也可以手动填写。
- 2
上传 App Store Connect 密钥
在 App Store Connect 的「用户和访问」→「集成」中生成应用内购买 .p8 密钥，然后连同 issuer id 和 key id 一起上传到这里。密钥以 AES-256 加密存储。
- 3
粘贴你的 webhook 地址
把我们显示的 webhook 地址复制到 App Store Connect 的「应用信息」→「App Store Server Notifications」→「版本 2」，然后保存。
- 4
发送一条测试通知
用 App Store Connect 的「发送测试通知」确认连接。我们收到并验证后，接入状态会切换为「已连接」。
- 5
退款开始自动抗辩
从那时起，每个消费请求都会实时收到带拒绝意见的回应，其他所有退款事件也会在你的后台被跟踪。
关于 App Store 退款的问题
不会。消费请求正是 Apple 为这一刻设计的通知：它征求你的意见并等待回复。提交拒绝意见遵循的是 Apple 自己的流程，而不是绕过它。
不需要。在 App Store Connect 上大约五分钟：生成一个 .p8 密钥、粘贴一个 webhook 地址、发送一条测试通知。没有代码要写，也没有版本要重新提交审核。
它抗辩消费请求，也就是 Apple 会停下来征询你意见的那些退款。其他情况，比如 Apple 已经批准的退款或撤销，都是 Apple 自己的决定，我们会记录下来供你分析而不去抗辩。无论哪种，都不会在你不知情的情况下溜走。
可以。无需绑卡即可接入应用并开始回应退款申请。随着量增长再考虑付费套餐，价格页有详细说明。
接入即刻生效。测试通知当天就能确认连接，从你第一个真实的消费请求开始，回应就实时发出。Apple 只留约 12 小时，而你不必为此熬夜。
我们会逐笔记录，也就是大多数团队从未看见的静默后台退款。即便是你无法抗辩的退款，你也终于能在一个视图里看清 iOS 收入的流向和漏点。
安全。你的 .p8 密钥在静态存储时使用 AES-256-GCM 加密，且仅用于验证通知和回应退款申请。我们不收集你用户的个人数据。
不会。一切都在 Refund Sensor 与 Apple 之间服务器对服务器完成。你的应用不受影响，购买流程不变，用户看到的仍然只是 Apple 的决定。