Quick answer: Before you send consumption data to Apple in response to a CONSUMPTION_REQUEST, you must have valid consent from the customer, and you must set customerConsented to true. Apple's notification does not tell you whether consent exists, by design, Apple expects your app, not your server, to collect it. And because you're the one sharing data you collected from the user, the legal responsibility for that consent is entirely yours, not Apple's. Get it wrong and it's a privacy-law problem, not just a rejected API call.
The gap most developers miss
Refund automation guides love to talk about the 12-hour window and the consumption fields. Almost none of them stop on the single detail most likely to get a developer in trouble: the CONSUMPTION_REQUEST notification contains no indication of consent.
That surprises people. You'd reasonably assume that if Apple is asking you for data, Apple has already handled the permission to share it. It hasn't. Apple's position is the opposite the data you'd send is data you collected from your user, so the responsibility to have permission to share it sits with you. Apple simply requires you to attest to it by setting customerConsented to true, and rejects the submission if you don't.
So the field isn't a checkbox you flip to make the API happy. It's a legal attestation. Setting it to true when you haven't actually obtained consent isn't a technicality it's a compliance failure waiting to be found.
Why consent is the developer's responsibility
Think about who holds what. Apple runs the store and the refund decision. But the account tenure, play time, delivery status, and usage history you'd put in a ConsumptionRequest are your records about your user, gathered under your privacy policy. When you send them to Apple, you're disclosing personal data to a third party.
Under every major privacy regime, that disclosure needs a lawful basis — and for this kind of sharing, that generally means the user's informed consent. Apple can't give that consent on your behalf, and it doesn't claim to. That's why the burden lands on the developer, and why "Apple asked for it" is not a defense if a regulator asks how you had permission to share a user's data.
Where consent has to be collected
This is the part that matters practically: consent must be collected in your app, before the refund flow not inferred at the server when the notification arrives.
By the time a CONSUMPTION_REQUEST lands on your server, it's too late to ask. There's no user present, no UI, and about 12 hours on the clock. The consent has to already exist, captured earlier as part of how your app onboards and discloses data practices, so that when the request arrives you can truthfully set customerConsented to true.
In practice that means your app's terms, privacy policy, and purchase or onboarding flow need to clearly disclose that consumption data may be shared with Apple to process refund requests, and obtain agreement in a way you can stand behind. Vague, bundled, or buried consent is exactly what modern privacy law is designed to reject.
How this connects to GDPR and DPDP
If any of your users are in the EU/UK (GDPR), India (DPDP), California (CCPA), or a growing list of other jurisdictions, the sharing of consumption data falls squarely inside those frameworks. A few principles that consistently apply:
Consent must be informed and specific. The user should understand that refund-related data may be shared with Apple, not just agree to a wall of legal text.
Consent should be separable. Bundling data-sharing consent with unrelated terms in a single mandatory checkbox is a recognized anti-pattern.
You must be able to demonstrate it. If challenged, "we had consent" needs to be provable, which means your consent capture has to be recorded, not assumed.
Your privacy policy has to actually say it. If your policy doesn't disclose sharing consumption data with Apple for refunds, your consent for it is on shaky ground.
This is not legal advice, and the specifics of your obligations depend on your users and jurisdictions, but the direction is clear: the consent behind that customerConsented field has to be real, informed, and documented.
What a compliant setup looks like
Pulling it together, a defensible setup has three parts working in advance of any refund:
Disclosure: your privacy policy and terms clearly state that consumption/usage data may be shared with Apple to handle refund requests.
Capture: your app obtains the user's informed, separable consent, and records it.
Attestation: when a CONSUMPTION_REQUEST arrives, your response reflects that recorded consent honestly in customerConsented.
RefundSensor was built with this chain in mind. The platform handles the refund response and the customerConsented attestation as part of the automated flow, and we've published a full suite of compliance documents, privacy policy, terms, DPA, cookie and refund policies aligned to GDPR, DPDP, and CCPA, so the disclosure and processing side is covered rather than improvised. The consent capture in your app stays your call, as it must, but everything downstream of it is handled.
The most common mistakes
Setting customerConsented to true by default. The fastest way to turn a refund feature into a compliance liability.
Assuming Apple handles consent. It doesn't, and says so.
Trying to collect consent at refund time. There's no user and no window for it, it has to exist beforehand.
Disclosing nothing in the privacy policy. If the policy is silent on sharing data with Apple, the consent behind it is hard to defend.
Bundling it into one mandatory checkbox. Separable consent is the standard; bundling undermines it.
Official sources
Requirements and regulations both change, so treat these as the final authority:
Refund automation that respects the consent chain. RefundSensor handles the refund response and the customerConsented attestation as part of an automated flow, backed by a full GDPR/DPDP/CCPA-aligned compliance document suite. Start free
This article is general information, not legal advice; consult a qualified professional for your specific obligations.
Frequently asked questions
Yes. You must have valid, informed consent and set customerConsented to true. Apple requires the attestation and rejects responses without it, and you're legally responsible for having obtained the consent.
In your app, before the refund flow. When a CONSUMPTION_REQUEST arrives at your server there's no user present and about 12 hours on the clock, so consent has to already exist and be recorded.
No. The notification carries no consent indication. Apple expects your app to have collected it, and expects you to attest to it in your response.
It can be, if the consent chain is done properly, clear disclosure in your policy, informed and separable consent captured in-app and recorded, and honest attestation in the API response. The automation handles the response; the in-app consent capture is your responsibility.
Apple won't process the consumption data, so you lose the chance to inform that refund decision. The correct path is to obtain real consent up front rather than sending data without it.
