快速解答：当客户就应用内购买或订阅向 Apple 申请退款时，App Store 会向你的服务器发送一条 CONSUMPTION_REQUEST 通知，并给你大约 12 小时的时间，通过 Send Consumption Information 端点提交消费数据作为响应。Apple 会在做出决定时权衡这些数据。如果你未能及时响应，Apple 就会在没有你输入信息的情况下自行决定，而不合理的退款申请往往会被默认批准。将这一响应过程自动化，就能确保每一次请求都能在时限内得到答复，无一例外。
简要概述
Apple 掌控着支付通道。当用户在你的应用中购买订阅或应用内商品时，由 Apple 负责收款、抽成并处理退款。多年来，开发者在退款决策上完全没有发言权。
这一状况已经改变。Apple 现在允许你发送消费信息——即有关客户如何使用其所购内容的结构化证据——并将其纳入退款决策的考量因素。你无法自行批准或拒绝退款，最终决定权仍在 Apple 手中。但如果你保持沉默，Apple 就没有任何依据可参考；而一份完整规范的响应，则能为其提供背景信息。
问题的关键在于时效性和一致性。响应窗口很短，且开启时间难以预测，一旦请求量稍大，靠人工处理根本不可能实现。这正是 Apple 退款自动化要解决的问题。
Apple 退款流程的实际运作方式
以下是完整的流程步骤：
客户提交退款申请。客户访问 reportaproblem.apple.com，选择相应的购买项目，选择退款原因，然后提交申请。
Apple 通知你的服务器。对于符合条件的购买项目，App Store 会通过 App Store Server Notifications V2 发送一条 CONSUMPTION_REQUEST 通知。该通知的负载（payload）中包含用于识别该购买项目的已签名交易数据。正是这些 App Store Server Notifications 触发了自动化工作流程。
你以消费数据作出响应。你需要调用 Send Consumption Information 端点，提交原始交易 ID，以及一个结构化的 ConsumptionRequest 请求体，其中描述了交付情况、使用情况、用户同意状态以及你的退款偏好。Send Consumption Information 端点是整个流程中关键的 API 环节。
Apple 做出决定。其退款决策系统会将你提交的数据与客户的历史记录及其他因素一并权衡，然后作出裁定。
你会收到结果通知。REFUND 通知表示退款已被批准；REFUND_DECLINED 通知（针对通过 StoreKit API 发起的请求）则表示退款未被批准。
CONSUMPTION_REQUEST 包含哪些内容，以及你需要回传哪些数据
通知本身携带已签名的交易信息以及客户填写的退款原因（consumptionRequestReason）。真正的工作在于你的响应。Apple 定义了一个结构化的 ConsumptionRequest，其中包含以下字段：
字段 | 向 Apple 传达的信息 |
customerConsented | 客户是否同意分享此数据。必须为 true，否则 Apple 会拒绝该提交。 |
consumptionStatus | 所购内容是未被使用、部分使用，还是已完全使用。 |
deliveryStatus | 应用内价值或服务是否已实际交付。 |
accountTenure | 客户在你这里拥有账户的时长。 |
playTime | 客户在应用中花费的使用时长。 |
lifetimeDollarsPurchased | 客户在你所有应用中的累计消费总额。 |
lifetimeDollarsRefunded | 此前已退还给该客户的累计金额。 |
sampleContentProvided | 客户在购买前是否可以试用相关内容。 |
userStatus | 客户账户当前的状态（正常、已封禁等）。 |
refundPreference | 你向 Apple 提出的建议：不表态（undeclared）、倾向批准（prefer grant）或倾向拒绝（prefer decline）。 |
每一个字段都是一个信号。若留空，Apple 就永远无法获得这部分背景信息。我们在 What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdown 一文中详细拆解了每个字段及其可接受的取值。评估 Apple 退款 API 的开发者，也应当了解这些字段在整个退款流程中的作用。
12 小时响应窗口
在生产环境中，你大约有 12 小时的时间来响应一条 CONSUMPTION_REQUEST。一旦错过，你就失去了提供意见的机会，Apple 会依据已有信息作出决定。
问题并不在于窗口本身的长短，而在于它何时开启。退款请求不会等到工作时间才出现，窗口可能在深夜、周末，或是节假日期间开启，如果没有人 24 小时随时待命，人工审核队列根本无法覆盖这些情况。这正是开发者本可以争取却最终失去退款申辩机会的最常见原因：不是响应质量差，而是根本没有响应。我们在 The 12-Hour Window: Why Most Developers Lose Refunds by Default 一文中对此有更深入的探讨。
同意授权要求——切勿跳过这一步
这是几乎所有人都容易在此栽跟头的一环，而且这不仅是技术问题，更是法律问题。
Apple 的 CONSUMPTION_REQUEST 并不会告诉你客户是否同意分享其数据。这是有意为之的设计——Apple 希望由你的应用而非服务器，在发送任何消费数据之前收集并确认用户同意。你必须在 API 调用中将 customerConsented 设置为 true，而作为开发者，你要对获得有效同意负全部责任，因为你分享的是从用户那里收集来的数据。
如果在这一点上出错，你面临的将不仅仅是提交被拒的风险，还可能引发 GDPR 或 DPDP 合规问题。在实现任何自动化之前，务必先在应用的条款和购买流程中妥善处理用户同意事宜。我们在 Customer Consent & the Consumption API: What Apple Actually Requires 一文中详细介绍了具体应在何处、如何处理这一问题。
实现自动化究竟需要什么
从表面上看，实现这一响应过程的自动化似乎只是个周末小项目：捕获通知、填写字段、调用端点。但在生产环境中，这其实是一套需要长期维护的基础设施——真正理解其中涉及的工作量，决定了你是选择“自己动手做”还是“干脆放弃”。
一个可靠的自建响应系统，必须能够接收并验证 Apple 的已签名通知，在请求到达的瞬间为每位客户拉取准确、实时的使用情况和账单数据，将这些数据映射到 Apple 规定的确切 ConsumptionRequest 取值，并在约 12 小时的窗口期内、不分昼夜、无需人工值守地完成提交。除此之外，它还需要具备符合时限要求的重试机制、故障处理、可审计的日志记录、用于及时发现故障的监控，以及每当 Apple 调整其负载结构或字段时进行的持续维护。这些都不是你的产品本身。这一切都是你需要无限期维护的基础设施，而它与你的应用实际所做的事情毫无关系。（关于通知层，我们在 Setting Up App Store Server Notifications V2 一文中有更深入的介绍。）
这正是大多数团队最终得出的结论：实现机制并不复杂，但构建并持续维护一个合规、能够按时响应的系统，是一项永久性成本，对应用本身没有任何附加价值。这正是托管服务所擅长解决的那类无差异化的底层基础工作。
这正是 RefundSensor 所做的事情。只需一个 webhook URL 即可接入你的 App Store Connect 设置——无需 SDK、无需修改代码、无需重新提交应用——随后它会在 Apple 规定的时限内自动响应每一条 CONSUMPTION_REQUEST，根据你的数据映射相应字段，处理重试与监控，紧跟 Apple 的各项变更，并将每个结果都记录在同一个 dashboard 中。你无需自行构建或维护一套响应系统，即可获得其应有的效果。对于正在寻找 Apple 退款自动化软件的团队来说，这提供了一种托管替代方案，无需再自行维护这一整套工作流程。
响应是否真的能减少退款？
答案是肯定的，不过效果因情况而异，且最终决定权始终在 Apple 手中。提交准确的消费数据能为 Apple 的系统提供更多背景信息，持续给出响应的开发者，其获批的退款数量通常要少于那些对请求置之不理的开发者。在有确凿证据支持的情况下，选择“倾向拒绝（prefer decline）”这一建议，也是 Apple 会考量的又一项输入因素。当你需要大规模管理订阅退款流程时，这一点尤其重要。
自动化能做什么，不能做什么
坦诚面对自动化的能力边界：
它无法保证任何特定的退款申请一定会被拒绝。每一次决定权都在 Apple 手中。
它无法为那些从未触发 CONSUMPTION_REQUEST 的退款申辩——并非每一笔退款都会触发该通知。
它能够确保每一个符合条件的请求都能在时限内以一致、准确的数据得到响应，让你不会仅仅因为没人看到通知而白白失去申辩退款的机会。
最后这一点才是关键所在。你并不是在凌驾于 Apple 之上做决定，而是在确保自己每次都有机会为自己发声。
具体细节请以 Apple 官方资料为最终依据：
整个行业花了 15 年时间，才为开发者在退款问题上争取到一席发言权。请务必每一次都善加利用。RefundSensor 会在时限内自动响应 Apple 的 CONSUMPTION_REQUEST 通知，并追踪每一个结果，同时支持 Apple 和 Google Play。免费开始使用
常见问题
这是一条 App Store Server Notification，当客户就符合条件的应用内购买或订阅申请退款时，Apple 会将其发送给你的服务器。这是提示你需要提交消费数据作为响应，Apple 会将这些数据纳入退款决策的考量。
在生产环境中，大约有 12 小时。如果你未能及时响应，Apple 就会在没有你输入信息的情况下自行决定，而未获响应的请求往往会被默认批准。
不可以。你可以发送 refundPreference 建议拒绝该退款，但最终决定权始终在 Apple 手中。自动化通过确保每次都提交准确数据来提高你的胜算，但并不能赋予你一票否决权。
是的。你必须在应用中获得有效的用户同意，并将 customerConsented 设置为 true。Apple 不会替你收集这项同意授权，在未获同意的情况下发送数据会带来隐私合规风险，而这一风险由你自行承担。
不需要。响应 CONSUMPTION_REQUEST 是通过 App Store Server Notifications 和 Consumption API 在服务器端完成的。使用 RefundSensor，你只需将一个 webhook URL 粘贴到 App Store Connect 中即可——无需 SDK、无需修改代码、无需重新提交应用。
Apple 会在没有你数据的情况下继续处理。你将失去提供背景信息的唯一机会，退款（包括不合理的退款）获批的可能性也会更高。
