Refund consumption information checklist

Define when to send evidence

Identify the events that justify consumption information: premium report generated, subscription value used, consumable spent, export downloaded, support override applied, or entitlement never activated. Do not send vague engagement data just because it exists.

The team should know who owns the decision, how quickly the information must be sent, and how the user can get support if the refund outcome is disputed.

AppReviewReady interpretation: refund evidence is not a weapon against users. It is a concise operational record that helps align access, support, and App Store commerce outcomes.

Minimize the data sent

• Use purchase, entitlement, and consumption facts rather than broad analytics history.
• Avoid sensitive content, private files, messages, or unnecessary identifiers.
• Record whether value was delivered, partially delivered, or not delivered.
• Keep internal support notes separate from API payload construction.
• Review data retention and privacy policy alignment.

Connect refund state to access

Refund handling should update entitlement logic, support view, analytics, and user-facing state consistently. A refunded user may need access revoked, preserved for a grace period, or manually reviewed depending on product promise and policy.

Test refund notification, partial consumption, delayed server processing, repeat purchase, family sharing, and restore states. Support should not need to guess whether the user still has access.

Separate Apple policy from AppReviewReady interpretation: Apple provides refund and server API mechanisms; AppReviewReady recommends an audit trail so product and support teams can act consistently.

Review privacy and fairness

1. Document each field used to decide consumption status.
2. Confirm the field is necessary for refund context.
3. Exclude sensitive content and unrelated behavioral analytics.
4. Keep a human-readable record for support escalation.
5. Audit refund disputes for confusing product promises.

Refund consumption record

The record gives finance and support a shared basis for explaining what happened without exposing private user content. It also helps identify product promises that cause repeated refund requests.

Review refund records by product ID and acquisition source. A high refund rate after a specific offer or guide CTA may mean the paywall promise is too broad or the first-session value is too slow.

After a refund incident, close the loop by updating entitlement rules, support macros, and conversion copy. Refund quality is part of profit, not a back-office afterthought.

Avoid using refund evidence to preserve a broken offer. If consumption is technically real but users repeatedly ask for refunds because value was unclear, the healthier profit move is to fix the promise and onboarding.

Refund record:
Transaction: [id]
Product: [id]
Value delivered: [none/partial/full]
Entitlement state: [state]
Evidence source: [system]
Privacy review: [yes/no]
Support route: [link]