App Store Server Notifications V2: What Developers Should Know
App Store Server Notifications V2 is the modern way Apple tells your server what is happening with a customer's purchase: subscriptions renewing or expiring, refunds being issued, and, most importantly for revenue protection, when Apple asks you for consumption data before deciding on a refund.
If you're building refund automation, V2 is the foundation. Here's what you need to understand about how it works, what to verify, and where implementations usually fail.
Every notification is a signed JWS
Every V2 notification is a JSON Web Signature (JWS). The payload is signed by Apple and includes the notification type, signed transaction information, and metadata you can use to verify the event.
Verifying the signature matters for two reasons: it proves the notification really came from Apple, and it stops attackers from forging events that could trick your server into acting on a fake refund request.
A robust implementation verifies the JWS against Apple's public keys, then extracts the transaction and checks values like the app bundle ID and the original transaction ID. Apple documents the format and verification steps in the App Store Server Notifications reference.
The notification types that matter for refunds
V2 covers a wide range of events. The ones directly relevant to refund protection are:
CONSUMPTION_REQUEST: Apple asks for consumption data to evaluate a refund request for a consumable or auto-renewable subscription. This is the event your refund logic must handle first.REFUND: the App Store refunded the transaction.REFUND_DECLINED: the App Store declined a refund request the customer initiated through the request refund API.REFUND_REVERSED: the App Store reversed a previously granted refund due to a dispute the customer raised. If you revoked content because of the refund, reinstate it.
Subscription lifecycle events like SUBSCRIBED, DID_RENEW, and EXPIRED matter too, because renewal history is a strong signal when evaluating a refund request.
Sandbox and production are separate worlds
Apple sends notifications for both production and sandbox environments. Sandbox events are useful for testing, but they must never interfere with production data; in practice, filter by environment or route them to a separate test path.
A common failure mode is a misconfigured production webhook: verification fails and the whole pipeline silently stops. Test both environments during setup, monitor delivery, and make sure a sandbox event can never update production subscription state.
What V2 means for your architecture
To act on V2 notifications you need three things in place:
- A public webhook URL configured in App Store Connect for each app.
- A verification step: every notification is a JWS signed by Apple, so verify the signature using the certificate chain included in the header before trusting it.
- App Store Connect API keys to call the App Store Server API, including the Consumption API when a
CONSUMPTION_REQUESTarrives.
Beyond the credentials, your pipeline needs to handle duplicate notifications (Apple can redeliver events), out-of-order events, and the timing constraints of the refund response window.
How to use V2 for refund protection
When a CONSUMPTION_REQUEST arrives, your job is to send Apple the consumption data it asked for before the window closes. That data (whether content was delivered and consumed, how old the account is, login history, and similar signals) is what Apple uses to decide between a legitimate refund and an abusive one.
You can build this pipeline yourself, or use a service that handles the webhook, verification, and API responses for you. If you want a step-by-step setup, the instructions live in the docs:
Why this matters for your revenue
The CONSUMPTION_REQUEST flow is where Apple explicitly gives developers a voice in refund decisions. Getting V2 right is the difference between defending your revenue and watching refunds get approved by default. If you want the full picture, read our complete guide to App Store refunds.
Related articles
Ready to protect your revenue?
Connect your first app in minutes. No SDK, no code changes required.