问大多数团队是否在跟踪 Apple 退款，他们会说是。再问他们存了什么，结果往往是每笔退款一行记录，事后写入，只有日期和金额。
那是日志，不是跟踪。它只告诉你发生了一笔退款，却不会告诉你 Apple 在过程中是否向你询问过什么、有没有人回答、回答是否成功送达，以及该客户的访问权限是否与实际情况一致。
这个差距很重要，因为流程中的某些环节是有时效的。Apple 为其中一步给出 12 小时窗口，一旦错过便无法重开。如果你想了解的是整体思路而非跟踪机制，我们关于如何管理 App Store 退款而不损失移动应用收入的指南已有介绍。本文要讲的是应该记录什么，以及何时行动。
要点速览
• 退款的最终决定由 Apple 做出。开发者无法批准或拒绝请求。
• 一个退款请求会经历多个不同状态。只存最后一个状态，会丢掉大部分有用信息。
• 某些退款流程会给你机会在 12 小时内（经用户同意后）发送消费信息。
• 提交响应和响应被接受是两回事。要跟踪结果，而不是尝试。
• 退款结果必须同步到你的权益逻辑和收入记录，否则跟踪就没有完成。
• 自动化主要用于防止漏掉事件和错过窗口。它对 Apple 的决定没有任何影响。
什么是 Apple 退款请求跟踪？
Apple 退款请求跟踪，指的是在你这一侧追踪退款请求经历的每一个状态，从第一条通知开始，到最终关闭它的权益更新为止。它不是退款记录，而是流程记录。
这些状态之所以重要，是因为它们确实是不同的事件，而团队往往把它们合并成一个：
状态 | 它告诉你什么 |
已收到请求 | 存在一个退款请求，且 Apple 已通知你 |
响应窗口开放 | Apple 正在征求你的输入，计时已经开始 |
已提交响应 | 你回传了内容 |
响应已被接受 | Apple 确实接收了它——这与发送出去不是一回事 |
退款已批准 | Apple 批准了退款 |
退款已拒绝 | Apple 未批准 |
退款已撤销 | Apple 撤销了此前批准的退款 |
权益已更新 | 你的应用现在反映了该结果 |
只有最后一行与你的产品有关。它上面的所有行决定了你能否把这一行做对。一个只存“退款已批准”的团队，说不清为什么某位客户仍然拥有访问权限，也说不清 Apple 询问时是否有人回答。
开发者如何跟踪 Apple 退款请求？
开发者通过 Apple 的服务端通知系统和自己的交易记录来跟踪 Apple 退款活动。具体路径取决于事件类型，以及 Apple 是否要求你提供输入。事件会以签名 payload 的形式发送到你通过 App Store Server Notifications 配置的 URL，由你的后端验证并处理。
在你的处理程序中，有两类退款相关事件值得区分。一类是向你索取信息，另一类是告诉你发生了什么。
索取信息的一类是 Apple CONSUMPTION_REQUEST 通知。它表示 Apple 在评估退款请求时需要了解某笔购买的信息。它本身不是退款，编写处理程序时也不要假设它一定会到来。
告知结果的一类包括：REFUND 表示已批准，REFUND_DECLINED 表示未批准，REFUND_REVERSED 表示 Apple 撤销了此前批准的退款。第三种是大多数处理程序会遗漏的。
这两类事件之下，是你自己的交易存储，正是它让这一切变得可读。通知引用的是 Apple 的标识符，如果没有可以匹配的购买记录，你手里就只是一个无处挂靠的事件。
开发者应该跟踪哪些信息？
按信息来源来划分，因为其中只有一方是权威来源。
来自 Apple 的信息，位于交易 payload 中：交易标识符和原始交易标识符、产品标识符、购买日期，以及对于已退款的交易，还有撤销日期和撤销原因。这个原因字段能区分因应用问题导致的退款与其他原因导致的退款，比看起来更有用。
账户令牌介于两者之间。你在购买时生成并附加它，Apple 会在 payload 中将其返回，这正是让你能从一笔交易追溯到具体用户的关键。
其余的都由你来维护：内部用户标识符、通知类型及到达时间、是否需要响应、你发送了什么以及收到了什么、当时的订阅状态、处理后的权益状态，以及退款落入的报告周期。
这两个时间戳其实是整组字段中最有用的。Apple 事件与你的行动之间的时间差，是衡量你的跟踪是否有效的唯一真实标准。
如何逐步跟踪 App Store 退款
1. 接收退款相关事件
事件会到达你配置的服务器端点。如果端点配置错误或出现故障，退款仍会照常进行，只是你永远收不到通知，而你这边也不会出现任何错误。
2. 验证通知
在处理 payload 之前，先用 Apple 的证书链验证签名，并确认 bundle ID。一个对收到的任何内容都信任的端点，别人也能往里写。
3. 识别相关交易
将解码后 payload 中的标识符与你的购买记录进行匹配，再解析到对应的用户账户。如果你在购买时附加了账户令牌，这只是一次查询，而不是一场调查。
4. 检查 Apple 是否在请求输入
根据通知类型分支处理。消费请求需要一条响应路径，结果通知需要一次状态更新。把两者同等对待，正是错过响应窗口的原因。
5. 收集受支持的消费信息
从你自己的记录中提取数值：购买内容是否已交付、是否提供了试用内容、消费了多少。Apple 的 Send Consumption Information 文档列出了各字段及其有效值。在做这一切之前，先检查用户同意——Apple 要求获得客户的有效同意才能共享这些数据，获取同意是开发者的责任，未获同意的请求会被直接拒绝。
6. 在文档规定的窗口内提交
Apple 当前文档要求在收到通知后 12 小时内响应。发送准确的数值，并确认调用成功，而不是假定它成功了。
7. 跟踪最终结果
记录收到了哪种结果通知以及何时收到。如果你的管道在故障期间丢失了事件，Apple 的服务器 API 提供退款历史，可用于找回遗漏的部分——值得作为定期对账来运行，而不是只依赖通知。
8. 更新权益与访问权限
退款批准时撤销权益，退款撤销时恢复权益，并处理只撤销部分交易的按比例情形。由服务端事件驱动，这样无论客户是否再次打开应用，状态都是正确的。
9. 与收入记录对账
把退款归到正确的周期和产品。否则，工程团队和财务团队手里会是同一个月的两个不同版本。
如何响应 Apple 退款请求
响应的方式是：在 Apple 提出要求时，在获得同意的前提下，在窗口内发送消费信息。你不能通过批准或拒绝来响应，因为开发者没有这个权限。决定由 Apple 做出。
你发送的内容应描述这笔购买的实际情况，取自你的记录。不是估算值，也不是朝着你期望的结果偏移的数字——除了不诚实之外，这些数据是你在承诺准确共享的前提下获得同意的。
这是大多数跟踪方案遗漏的操作要点：提交响应和响应被接受是两个不同的状态。调用可能验证失败并返回错误，如果没人检查结果，失败的提交在日志里看起来和成功的一模一样。要存储响应状态，而不只是记录你尝试过。
Apple 对退款做出决定后会发生什么？
Apple 以通知形式发送结果，并在其一侧撤销扣款。接下来的工作就转到你这边。
值得牢记的区别：Apple 批准退款是一个事件，你的系统正确反映它是另一个事件。无论你做什么，Apple 那一半都会完成。而你这一半，只有在通知送达、匹配到交易、解析到账户并更新了该账户的访问权限之后才算完成。
当两者出现分歧，就会有客户已经拿到退款，却仍然保留着所有付费内容。没人会反馈，因为在他们看来一切正常。这种问题要到几个月后对账时才会显现，甚至根本不会显现。
订阅需要格外注意，因为退款周期通常意味着订阅终止而非继续运行，你的状态应如实体现。客服也需要这份记录，这样客服人员无需请别人去查看 dashboard 就能了解发生了什么。
为什么手动跟踪 Apple 退款会变得困难
并非因为疏忽。这项工作的节奏，本就与人的在线时间不匹配。
退款请求在客户提交的任何时刻到达，响应窗口在夜间和周末照样计时。每个事件都需要一次查询、一次账户匹配、一次同意检查、一个使用量数值、一次提交和一次权益更新。都是小任务，但有时限、重复，而且做对了也没人看见。
规模扩大后，问题的形态也随之改变。多个应用，交易数据在一个系统，账户数据在另一个系统。历史退款数据始终单薄，因为没人回填；权益不匹配悄悄累积，无人标记；财务在季度结算时才发现差异——此时早已过了响应窗口有意义的时候。
Apple 退款跟踪可以自动化吗？
可以，而且大部分都应该自动化，因为几乎每一步都是确定性的。
自动化可以监控并验证退款事件、在每个请求到达时记录、将交易解析到账户、按通知类型分支处理、从你的记录中组装消费数据、跟踪响应窗口和提交结果、更新权益状态，并保持退款历史可查询。
它做不到的是影响 Apple。自动化不会降低退款的可能性，也无法左右决定。它改变的是你这一侧的流程能否始终如一地在窗口内完成。
RefundSensor 如何助力 Apple 退款管理
App Store 退款管理是这项工作所属的类别，而 RefundSensor 正是为其中开发者的一侧而构建：监控 Apple 退款流程，自动化受支持的响应步骤，并将退款事件、结果和记录集中在一处，而不是分散在多个 dashboard 中。
在实际使用中，响应会在商店窗口内完成，无需有人盯着通知；随着数量攀升，退款记录也能保持准确。
它不会改变 Apple 的决定，任何 Apple 退款管理软件都做不到。它改变的是每个请求留下多少手动工作。
这些规则的文档出处
上述技术性论述背后有三份 Apple 资料。请直接阅读，并定期回查——这一领域已经变更过不止一次。
为 App 或内容申请退款——面向客户的流程。有助于了解请求从何而来、客户被告知可在 24 到 48 小时内收到更新，以及 Apple 关于退款资格因国家或地区而异的说明。
Send Consumption Information——开发者响应流程：同意要求、12 小时窗口以及请求字段。在构建任何响应处理之前先读这份文档。
App Store Server Notifications——退款事件如何到达你的后端、签名 payload 的格式，以及各通知类型，包括 CONSUMPTION_REQUEST、REFUND、REFUND_DECLINED 和 REFUND_REVERSED。
如果退款事件仍靠人工盯守
手动跟踪一直能撑住，直到某天凌晨 2 点来了一条通知，而窗口在有人打开 dashboard 之前就已关闭。这种失败悄无声息，所以代价高昂。
如果这正是你的现状， RefundSensor 可以承担 Apple 退款流程中开发者的一侧：监控事件、确保响应在窗口内完成，并确保结果同步到你的记录和权益逻辑。
常见问题
通过 App Store Server Notifications 和你自己的交易记录。事件以签名 payload 的形式发送到你配置的服务器端点。你验证它们，将交易解析到具体客户，记录事件，在 Apple 要求输入时作出响应，并在结果到达后将其存储。
在开发者一侧追踪退款请求经历的每一个状态：已收到请求、响应窗口开放、响应已提交并被接受、Apple 的结果，以及最终关闭它的权益更新。只存储最终结果，会丢失你解释事情经过所需的信息。
可以。Apple 会以服务器通知的形式发送结果。REFUND 表示已批准，REFUNDDECLINED 表示未批准，REFUNDREVERSED 表示此前批准的退款已被撤销。已退款的交易在交易 payload 中还会带有撤销日期和原因代码。
在 Apple 提出要求且已获得有效客户同意的情况下，使用你自己记录中的准确数值发送消费信息。你无法批准或拒绝退款。你的响应只是 Apple 审核的一项输入，并且你应该确认提交成功，而不是假定它成功了。
一种 App Store Server Notification，告知你的服务器 Apple 在评估退款请求时需要了解某笔购买的信息。它不是退款通知，也不是决定。响应它需要客户同意，Apple 要求在 12 小时内作出响应。
Apple 当前文档要求在收到通知后 12 小时内响应。请求随时可能到达，因此这一步最适合自动化。请以 Apple 页面上的当前要求为准，而不是依赖旧的集成。
不会有任何变化，除非你主动更改。Apple 撤销扣款并不会改动你的数据库。你的后端应在退款获批时撤销权益，在 Apple 撤销退款时恢复权益，并处理只撤销部分交易的情形。
机械性的部分可以。验证通知、将交易匹配到账户、跟踪响应窗口和提交结果、更新权益、维护退款历史，这些都是确定性的。仍需人来做的是设计同意流程，以及解读退款模式对产品意味着什么。
