快速回答：在响应 CONSUMPTION_REQUEST 向 Apple 发送消费数据之前，你必须已获得客户的有效同意，并且必须将 customerConsented 设置为 true。Apple 的通知并不会告诉你同意是否存在，这是刻意设计的——Apple 期望由你的应用（而非你的服务器）来收集同意。而且，由于发送的是你从用户那里收集的数据，获得该同意的法律责任完全在你，而不在 Apple。一旦出错，这就不只是 API 调用被拒绝的问题，而是一个隐私法问题。
大多数开发者忽略的盲区
退款自动化指南通常喜欢大谈 12 小时窗口期和消费字段，但几乎没有一篇会停下来讲清楚那个最可能让开发者陷入麻烦的细节：CONSUMPTION_REQUEST 通知本身并不包含任何关于同意的指示。
这会让人感到意外。你可能会合理地假设，既然 Apple 向你索取数据，那么 Apple 应该已经处理好了数据共享的授权问题。但事实并非如此。Apple 的立场恰恰相反：你发送的数据是你从用户那里收集来的数据，因此获得共享授权的责任在于你自己。Apple 只是要求你通过将 customerConsented 设置为 true 来对此作出证明，如果不这样做，Apple 会拒绝你的提交。这正是 Apple Consumption API 同意要求的核心。
所以，这个字段并不是一个为了让 API 满意而随手勾选的选项，而是一项法律声明。如果你实际上并未获得同意却将其设置为 true，这不是什么技术细节问题，而是一个迟早会被发现的合规漏洞。
为什么同意是开发者的责任
想一想各方分别掌握着什么。Apple 运营着商店并做出退款决定。但你放入 ConsumptionRequest 中的账户使用时长、游玩时长、交付状态和使用历史，这些都是你关于你的用户的记录，是依据你的隐私政策收集而来的。当你把这些数据发送给 Apple 时，你实际上是在向第三方披露个人数据。
在适用的隐私法律框架下，这种披露需要有适当的法律依据。Apple 具体的 API 文档要求，在通过 Consumption Information API 共享个人数据之前必须获得有效同意，而具体的法律要求则取决于用户所在的司法辖区。Apple 表示，开发者有责任自行判断是否符合适用法律的要求。
这就是为什么这个责任落在开发者身上，也是为什么当监管机构追问你是依据什么授权共享了用户数据时，"是 Apple 要求的"并不能成为有效的辩护理由。对于一个 apple 退款同意工作流来说，关键在于：同意必须在数据被共享之前就已经存在。
同意必须在哪里收集
这是实践中最关键的部分：同意必须在你的应用中、在退款流程开始之前收集，而不是等通知到达服务器时再去推断。
当 CONSUMPTION_REQUEST 到达你的服务器时，再去询问已经太晚了。此时没有用户在场，而且时钟只剩约 12 小时。同意必须早已存在，作为你应用引导流程和数据实践披露的一部分事先被收集好，这样当请求到达时，你才能如实地将 customerConsented 设置为 true。
在实践中，这意味着你应用的条款、隐私政策以及购买或引导流程，都需要明确披露消费数据可能会被共享给 Apple 用于处理退款请求，并以一种你能够站得住脚的方式获得用户同意。模糊不清、被捆绑或隐藏起来的同意，恰恰是现代隐私法所要否定的对象。这也是 apple 退款隐私的核心所在，因为 Apple 明确要求在共享消费数据之前必须获得有效同意。
这与 GDPR 和 DPDP 的关系
如果你的用户中有任何人位于欧盟/英国（适用 GDPR）、印度（适用 DPDP）、加利福尼亚州（适用 CCPA），或是越来越多的其他司法辖区，那么消费数据的共享行为就完全落在这些法律框架的管辖范围内。以下几项原则普遍适用：
同意必须是知情且具体的。用户应当理解与退款相关的数据可能会被共享给 Apple，而不仅仅是对一堆法律文字表示同意。
同意应当是可分离的。将数据共享同意与不相关的条款捆绑在同一个强制勾选框中，是公认的不良做法。
你必须能够证明这一点。一旦受到质疑，"我们已获得同意"必须是可以被证实的，这意味着你的同意收集过程必须被记录下来，而不能只是假定存在。
你的隐私政策必须明确写明这一点。如果你的政策没有披露会为退款目的向 Apple 共享消费数据，那么你所获得的相关同意就站不住脚。
对于正在审查 gdpr 消费数据要求的团队来说，重要的一点是：Apple 本身就要求此 API 必须获得有效同意，而具体的法律要求和合法依据则会因司法辖区而异。Apple 的指南指出，同意必须是自由给予、具体、知情且明确的，并且开发者有责任自行判断是否符合适用法律的要求。
对于面向印度市场的应用而言，同样需要根据适用要求审查 dpdp 应用退款的同意机制，而不能想当然地认为满足 Apple 的 API 要求就足以解决所有隐私义务。
这并非法律建议，你的具体义务会因用户和司法辖区而异，但方向是明确的：customerConsented 字段背后的同意必须是真实、知情并有记录可查的。
一个合规方案应该是什么样的
综合来看，一个能站得住脚的方案需要在任何退款发生之前就完成以下三个环节：
披露：你的隐私政策和条款明确说明，消费/使用数据可能会被共享给 Apple 以处理退款请求。
收集：你的应用获得用户知情且可分离的同意，并对其进行记录。
声明：当 CONSUMPTION_REQUEST 到达时，你的响应会在 customerConsented 中如实反映已记录的同意情况。
RefundSensor 在设计时就考虑到了这整条链路。该平台将退款响应和 customerConsented 声明作为自动化流程的一部分来处理，并且我们已经发布了一整套符合 GDPR、DPDP 和 CCPA 的合规文档——隐私政策、条款、DPA、Cookie 政策和退款政策——因此披露和处理环节都是有章可循的，而非临时拼凑。应用内的同意收集环节仍然由你自行决定，这也是必须的，但在此之后的所有环节都已经处理妥当。
对于正在评估退款合规软件或 Apple 退款自动化工具的团队来说，这种职责划分非常重要：自动化可以处理技术层面的响应，但它不应该凭空捏造或假定客户已经同意。
最常见的错误
默认将 customerConsented 设置为 true。这是把一个退款功能变成合规隐患最快的方式。
假设 Apple 会处理同意事宜。事实并非如此，Apple 自己也这么说。
试图在退款发生时才去收集同意。此时既没有用户在场，也没有时间窗口，同意必须提前存在。
在隐私政策中完全不作披露。如果政策对与 Apple 共享数据一事保持沉默，那么背后的同意就很难站得住脚。
把它捆绑进一个强制勾选框里。可分离的同意才是标准做法，捆绑会削弱这一点。
把 App Tracking Transparency 当作同意机制来使用。Apple 的文档明确指出，Consumption Information API 所需的同意与 App Tracking Transparency 是两件不同的事。
官方资料来源
要求和法规都会随时间变化，因此请以以下资料作为最终权威依据：
尊重同意链路的退款自动化方案。RefundSensor 将退款响应和 customerConsented 声明作为自动化流程的一部分来处理，并配有一整套符合 GDPR/DPDP/CCPA 标准的合规文档。对于正在寻找应用退款自动化方案的团队来说，同意链路仍然是实施过程中不可或缺的一部分。 免费开始
常见问题
是的。你必须获得有效、知情的同意，并将 customerConsented 设置为 true。Apple 要求提供这一声明，没有声明的响应会被拒绝，而且你本人对获得该同意负有法律责任。
在你的应用中，在退款流程开始之前。当 CONSUMPTION_REQUEST 到达你的服务器时，没有用户在场，而且时钟只剩约 12 小时，所以同意必须早已存在并被记录下来。
不会。该通知不包含任何关于同意的指示。Apple 期望你的应用已经收集了同意，并期望你在响应中对此进行声明。
是可以的，前提是同意链路操作得当：在政策中清晰披露，在应用内收集知情且可分离的同意并加以记录，以及在 API 响应中如实声明。自动化负责处理响应环节，而应用内的同意收集则是你自己的责任。
Apple 将不会处理该消费数据，这意味着你会失去影响该退款决定的机会。正确的做法是提前获得真实的同意，而不是在没有同意的情况下发送数据。
