How Apple refund evidence works
App Store Server Notifications V2 sends a CONSUMPTION_REQUEST when Apple wants information before making a refund decision. The notification contains signed transaction data that identifies the purchase.
The developer calls Send Consumption Information with the original transaction identifier. Apple uses the response as one input in its decision. This is evidence, not a developer-controlled decline button and not a guarantee that Apple will refuse the refund.
The evidence Apple accepts
Apple defines a structured ConsumptionRequest. Each value should reflect the purchase and the customer experience you can support. RefundHalt applies your ordered policy instantly so the response is consistent before the deadline.
- Customer consent: whether the customer agreed before the purchase was made.
- Delivery status: whether the in-app value or service was delivered.
- Consumption status: whether the purchased value was consumed.
- Sample content: whether the customer could try content before buying.
- Refund preference: your recommendation to Apple based on the available evidence.
How to set up Apple refund protection
Apple does not offer delegated access for this API. Create an In-App Purchase key in App Store Connect, then upload the .p8 key with its Key ID and Issuer ID. RefundHalt encrypts the private key with AES-256-GCM at rest.
Next, point the production and sandbox App Store Server Notifications V2 URLs to the per-app RefundHalt webhook. RefundHalt can send a test notification and watch for the signed event. No mobile SDK or app release is required.
- Use the In-App Purchase key, not a general App Store Connect API key.
- Configure both production and sandbox Server Notifications V2 URLs.
- Keep RevenueCat, Adapty, Apphud, or your backend connected with raw notification forwarding when needed.
Why automatic responses matter
A 12-hour window can open overnight, on a weekend, or while the team is busy. A manual queue adds delay without changing Apple’s deadline.
RefundHalt matches the purchase, applies defaults plus ordered rules, sends the response, and records the outcome in one ledger. There is deliberately no manual-review mode, so an eligible request never waits for a person.
What this can and cannot do
Accurate consumption information gives Apple more context, but Apple always makes the final decision. Not every refund produces a CONSUMPTION_REQUEST, and no service can promise that every submitted response will prevent a refund.
Use real product and usage facts when available. If you do not send custom usage events, deadline-safe fallback values can still make sure a request is answered, but they should match your product policy.
Official sources
This guide was last verified on July 17, 2026. Store policies and APIs can change, so use the primary documentation below as the final authority.