快速解答：CONSUMPTION_REQUEST 是当客户对符合条件的应用内购买或订阅申请退款时，Apple 发送给你服务器的通知。要进行响应，你需要回传一个结构化的 ConsumptionRequest——一组描述客户如何使用其购买内容、是否同意提供数据，以及你的退款偏好的字段。Apple 会在决策时权衡这些字段。本指南将说明每个字段的含义及其重要性。
该通知是什么
当客户向 Apple 申请退款时，App Store 会通过 App Store Server Notifications 向你的服务器发送一个 CONSUMPTION_REQUEST。这相当于 Apple 在说：告诉我们你所了解的该客户使用此次购买的情况，我们会将其纳入决策考量。
你需要返回一个 ConsumptionRequest 主体来进行响应。每个值都是一个信号。发送准确、完整的 apple 退款数据，Apple 就能获得充分的背景信息；若字段留空，它所依据的信息就更少。你本人并不能批准或拒绝退款——最终决定权始终在 Apple 手中——但你提交内容的质量会影响结果的概率。完整流程请参阅 如何自动化处理 Apple 退款请求。
Apple 接受的字段
以下是 ConsumptionRequest 中包含的内容，以及每个字段向 Apple 传达的信息。这些consumption request 字段提供了consumption api 工作流程中所使用的结构化数据：
字段 | 代表的含义 | 重要原因 |
customerConsented | 客户是否同意共享此数据 | 必填。必须为 true，否则 Apple 不会处理该响应。 |
consumptionStatus | 未消费 / 部分消费 / 完全消费 | 完全消费的购买与完全未使用的购买，情况截然不同。 |
deliveryStatus | 价值或服务是否成功交付 | 用于区分"我们已交付，客户也使用了"与真正的交付失败这两种情况。 |
refundPreference | 你的建议：未声明 / 倾向批准 / 倾向拒绝 | Apple 决策的参考因素之一——在证据支持的情况下，这是你在决策过程中的"发言权"。 |
accountTenure | 客户在你这里拥有账户的时长 | 账户历史悠久与全新账户所呈现的情况是不同的。 |
playTime | 客户在你的应用中花费的时间 | 直接反映客户对其申请退款内容的使用参与度。 |
lifetimeDollarsPurchased | 客户在你所有应用中的消费总额 | 有助于判断这是一次性消费，还是来自一位有价值的老客户。 |
lifetimeDollarsRefunded | 该客户此前已获得的退款总额 | 反复退款的模式是一个有意义的信号。 |
sampleContentProvided | 客户在购买前是否可以先试用 | 反映购买决策是否建立在充分了解的基础上。 |
userStatus | 当前账户状态（活跃、已暂停等） | 体现客户在提出请求时的账户状况。 |
Apple 会将其中大多数字段映射到既定的取值集合（例如，consumptionStatus 和 deliveryStatus 使用特定的枚举代码）。具体代码可在下方链接的 Apple 官方文档中查看，并且可能会发生变动——这也是为什么保持响应内容的时效性是一项持续性工作，而非一次性搭建就能完成的任务。
最重要的三个字段
如果你只能关注几个要点，那就重点关注这三项：
customerConsented：这不仅仅是重要，更是一道门槛。如果该字段不为 true，Apple 会拒绝整个提交，而且在发送数据之前，你必须已经在应用内依法获得该同意，这是你的法律责任。它既是一个技术字段，也同样是一个合规字段。我们在 客户同意与 Consumption API中深入探讨了这一同意要求。
refundPreference：这是你最接近"投票权"的字段。如果你的证据确实支持拒绝退款，表达这一偏好就是 Apple 考量的输入之一。如果证据不支持，强行设置"拒绝"偏好并不是一个可以直接覆盖决策的万能开关——最终仍由 Apple 决定。
consumptionStatus：客户是否真正使用了所购买的内容，往往是案件的关键所在。如果在请求到达的那一刻，你的使用数据不够准确或不够及时，这也是最容易出错的字段之一。
为什么正确填写这些字段比看起来更难
光看字段表格，这项工作似乎只需一个下午就能搞定。但实际上，要做好响应，意味着：
在请求到达的瞬间，为每位客户提取准确、实时的使用和账单数据——而不是昨天的快照。
将你的内部数据映射到 Apple 的精确取值集合，并随着 Apple 的调整持续保持映射的准确性。
在约 12 小时的窗口期内完成这一切，无论何时，且无需人工值守。
处理同意状态、重试、失败情况以及日志记录，以便你能够证明自己发送了什么内容，并了解其是否有效。
这些事情在概念上都不难。但所有这一切都是你需要为一个并非你产品核心的工作流程而自行搭建和维护的基础设施。这正是大多数团队最终得出的结论：字段本身是可以弄清楚的，但要为它们搭建并维护一个可靠、能在截止时间前完成、合规的响应系统，是一项持续性的成本，而且对你真正的应用本身毫无增益。
这正是 RefundSensor 填补的空白。它会根据你的数据映射每一个字段，持续跟进 Apple 的变更，并在窗口期内自动完成响应，从而确保决定退款结果的准确性得到妥善处理，而你无需自己搭建或随时盯着它。对于正在比较各类 Apple 退款自动化软件的团队来说，这消除了工作流程中的基础设施负担。
官方资料来源
Apple 的取值集合和要求会不断变化，因此应将其官方文档视为最终权威依据：
字段本身是可以弄清楚的。为它们维护一个响应系统，并不是你该做的工作。RefundSensor 会根据你的数据映射每一个 ConsumptionRequest 字段，并在 Apple 的窗口期内自动完成响应——准确、及时且合规。 免费开始
常见问题
这是当客户对符合条件的购买申请退款时，Apple 发送的 App Store Server Notification。它会要求你返回消费数据，Apple 会在做出退款决定时权衡这些数据。
包括描述同意情况、消费状态、交付状态、账户历史、使用时长、历史消费与退款金额、试用内容提供情况、账户状态，以及你的退款偏好等字段。每一项都是 Apple 纳入决策考量的信号。
customerConsented 是一道硬性门槛，缺少它响应就会被拒绝。在证据支持你的情况下，refundPreference 和 consumptionStatus 对结果的影响最为直接。
当退款偏好有准确的消费和交付数据支撑时，它的权重会更高。内容稀少的响应能为 Apple 提供的依据较少，因此单独的偏好字段不如配合证据的偏好字段有说服力。
不能。最终决定始终由 Apple 做出。准确的数据能提高你的成功概率，但并不能给你否决权。
