在退款模式上，IAP和很多常见的支付渠道都不一样，一般微信支付等支付渠道，开发者可以针对一年内的订单发起退款，请求退款状态来取回商品，我把这种模式叫做主动退款（主动是相对于开发者而言的）。

主动退款（开发者主动感知）

对于IAP渠道，退款必须由用户自己发起，我们可以通过配置苹果端的后台通知地址来被动接收通知来领回钱，我把这种模式叫做被动退款。

被动退款（仅对开发者被动感知）

截至撰写本文时，用户可以前往该页面对60天内的订单进行退款（60天是中国的限制，一些国家的政策可能有所不同，但最长期限为六个月内）。

对于60天以外的订单，我们只能通过手动转账的方式退款到用户的银行账户。但请注意，对于一些特殊订单（如用户账户无余额导致无法扣款），开发者账户可能无法在60天内结算；而且如果全额退款，开发者要承担30%的苹果渠道税，所以手动转账是最差的选择。考虑补发或退还原订单的70%是比较合适的。

01

—

初始退款通知

你可能无法想象，我们无法察觉最初的用户退款。

感知退款的前提是苹果端配置App 通知地址，App 通知地址原本是用来感知自动续费订阅（俗称 -to- ）生命周期的，该功能最早在 2017 年上线（详情可参考#303），通过判断 -to- 类型，我们就可以感知自动续费订阅的退款。

应用程序 - 应用服务器通知

至于其他类型的退款通知（不可消耗、可消耗、不可续费订阅），我们后续可以感知到（详情请参考#）。其他类型的退款通知也复用了-to-链接，但提出了一种新的类型来区分它们（也是因为复用了S2S链接，所以截至撰写本文时，对于新的App，必须创建订阅组才能看到这个地址的配置条目）。

这也导致了最初的灰色产业，就是单纯的利用退款路径来牟利。因为上面说的原因，开发者一开始无法感知退款事件，从而无法要求退款，导致了“货发了，钱没收到”的情况。虽然苹果分别在和推出了退款通知，但还有很多现有的应用并没有打通，所以对于一些应用来说，这个漏洞还是可以被利用的。

02

—

一些退款变更

事实上，仅靠被动的退款通知是远远不够的。目前，“是否同意退款”的审批流程仍由苹果客服审核，苹果客服可以参考的数据维度往往非常有限。比如，如果一个人使用产品超过三年，没有退款记录，并且有大量的累积内购，那么苹果客服可以参考产品的使用年限、退款记录、累计退款金额、当前退款金额等维度来判断是否同意退款。

除了被动接收退款通知以外，我们开发者还常常希望实现以下能力：

好在苹果也听取了开发者的呼声，做出了相应的优化，在（详情请参考###）中推出了如下能力来优化上述场景：

苹果通过迭代满足了大部分诉求，但主动退款的诉求却没能得到满足，现在我们看到的是苹果还是希望将退款审批权交还给苹果客服，也就是苹果自己希望做“最终裁判”。

退款通知变更（2017 年 - 2022 年）

这里需要提一下的一点是，虽然苹果提供了这个通知类型供开发者了解退款是否被拒绝，但是这个通知类型只对用户通过应用内（in:）接口发起的退款有效，对于应用外用户发起的退款，仍然无法得知退款是否被拒绝。

03

—

退款灰色市场

由于前文提到的退款通知延迟，退款依然是IAP灰市的重要手段之一，下面是退款相关的常见灰市手段及应对措施，欢迎读者补充。

1. 账户维护退款

这也是灰市初期的做法，成本主要在于维护账号，步骤如下：

创建大量的这样的对象。

这群人是通过群控设备进行控制，模拟正常用户下载APP、购买免费产品（这一步主要是为了增加退款成功率，让自己看起来像是正常用户）。

通过淘宝、拼多多等电商平台寻找买家，以低价出售商品，比如你可以以324的价格买到648的商品。

使用筹集的资金为买家购买商品。

通过网站/客服电话退款。

>> 帐号维护退款-对策 票务拦截及退款-对策 赠品及退款-对策 升级退款-对策