If your app still runs on App Store Server Notifications V1, Apple never asks you about subscription refunds

Version 1 of App Store Server Notifications still delivers refunds, but it leaves out the one notification that lets you argue a subscription refund. Apple deprecated V1 on June 5, 2023, alongside the verifyReceipt endpoint, and has added every refund feature since then to V2 only. If your App Store Connect settings still say Version 1, Apple can decide a subscription refund without ever sending your server a CONSUMPTION_REQUEST. You don't lose a fight there. You never get invited to one.

What Apple's App Store Server Notifications V1 deprecation means

Deprecated doesn't mean switched off. An Apple engineer wrote on the developer forums in June 2023 that verifyReceipt and V1 notifications will keep working until an end-of-life date is announced, that the date hadn't been set, and that developers will be told in advance. More than three years later, App Store Connect still offers "Version 1 (deprecated)" as a choice when you set a server URL.

What deprecation does mean is a freeze. Every change in Apple's notifications changelog since June 2023 is a V2 change: new fields on the signed transaction, new notification types, the 12-month commitment data added in April 2026. A V1 server sees none of it.

Which refund signals a V1 server never receives

Here's how the same refund events reach a V1 server and a V2 server, according to Apple's documentation for each version.

Does V1 still get CONSUMPTION_REQUEST at all?

Yes, for consumables. Apple's V1 reference describes CONSUMPTION_REQUEST as the notification sent when a customer starts a refund request for a consumable in-app purchase. An Apple engineer confirmed on the forums in 2023 that V1 consumption requests fire for eligible refunds. The gap is subscriptions. Apple's changelog dates subscription consumption requests to April 11, 2024, in V2, and the Send Consumption Information documentation says Apple sends the request through your V2 endpoint.

Why CANCEL on V1 is easy to misread

On V1, when Apple refunds a subscription, the notification type is CANCEL, often paired with DID_CHANGE_RENEWAL_STATUS. Plenty of servers treat any cancel as a customer turning off auto-renew, which leaves access running until the period ends. V2 removes the ambiguity. A refund arrives as REFUND, and a customer turning off renewal arrives as DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED.

What staying on V1 costs in money

Apple decides every App Store refund. The CONSUMPTION_REQUEST is the only point where your usage data reaches that decision, and Apple asks you to answer within 12 hours. On V1, subscription refunds skip that step.

Here's a worked example with illustrative numbers. Say your app sells a $9.99 monthly subscription that includes AI image generations. A subscriber runs 400 generations in a month, and each one costs you real money in model inference. Then they ask Apple for a refund.

The payment you lose is your share, not the sticker price. Apple pays 70% of a subscription price, minus applicable taxes, during a subscriber's first year of paid service, and 85% after that or for members of the App Store Small Business Program. The compute bill doesn't shrink with it. Inference, third-party API calls and file storage were paid when the customer used them.

The two missing outcome notifications cost money too. Without REFUND_REVERSED, a server that revoked access on a refund never restores it when Apple takes the refund back, so a paying customer stays locked out and writes to support. Without REFUND_DECLINED, you can't tell a refund that's still pending from one Apple turned down.

How to migrate from V1 to V2 without dropping a refund

Moving to V2 is a server change plus one setting. Apple's own guidance on the forums, from an App Store Commerce Engineer in December 2025, explains what happens on the day you switch.

Build the V2 endpoint before you flip the setting

• Accept a POST whose body carries a signedPayload. V2 payloads are JWS, signed by Apple, so verify the signature before you trust anything inside. Apple's App Store Server Library does this for you.
• Map CANCEL handling to REFUND, and handle REFUND_DECLINED and REFUND_REVERSED as new cases.
• Answer CONSUMPTION_REQUEST for subscriptions with Send Consumption Information, and only when the customer consented to sharing data with Apple. Apple says that without consent you shouldn't respond.
• Return HTTP 200 to 206 on success. Any 40x or 50x makes Apple retry.

Switch the setting in App Store Connect

In App Store Connect, open your app, choose App Information under General, find App Store Server Notifications, and set the Production Server URL to your V2 endpoint with Version 2 selected. Do the same for the sandbox URL first if you want to test, and use Request a Test Notification to confirm your server answers.

Keep the V1 handler alive for about three days

After the switch, new notifications arrive in V2 format right away, for every subscription, old or new. V1 notifications already in retry keep coming in V1 format until they succeed or run out. Apple puts the last possible V1 retry at about 78 hours, which is 6 plus 24 plus 48. Leave the old handler running past that, then remove it.

Replace verifyReceipt while you're there

verifyReceipt was deprecated the same day. It still answers, but Apple points servers to the App Store Server API instead. Get Transaction Info returns one signed transaction, Get Transaction History returns a customer's history, and Get Refund History lists every refunded purchase for a customer. Together with V2 notifications, those cover what most servers used receipts for, including the cancellation_date field that once marked a refund in a receipt.

RefundHalt connects to App Store Server Notifications V2 and answers each CONSUMPTION_REQUEST inside the 12-hour window, using the usage your app already records. If you're still on V1, the switch is the step that makes any of that possible.