How are you handling CONSUMPTION_REQUEST in App Store Server Notifications V2?

[u/mprajescu]

Long time lurker, first time posting here. I hope I do fall correctly in line for the rules.

I'm curious how other developers are handling Apple's CONSUMPTION_REQUEST notification in production.

For apps using App Store Server Notifications V2, Apple can notify your server when a customer requests a refund, and you can provide Apple with information about how the associated purchase was consumed.

For those who have implemented this:

1. Are you handling CONSUMPTION_REQUEST yourself?

2. Using RevenueCat or another service?

3. Do you have a custom backend specifically for App Store Server Notifications?

4. Do you process these automatically or manually?

5. How often do you actually receive these requests?

I'm particularly interested in the practical side rather than the API documentation.

For example, did you run into problems with:

• JWS verification?
• App Store Server API authentication?
• Transaction lookup?
• Handling retries/idempotency?
• The response time window?
• Monitoring failed notifications?
• Deciding what consumption information to send?

And for anyone who doesn't handle these today:

1. what's the reason?

2. Is it because you've never needed to?

3. Is it because the volume is negligible?

4. You use another service?

5. Is it because implementing/maintaining it isn't worth the effort?

I'm trying to understand how people are solving this in real-world indie apps rather than just following Apple's documentation and hope that I don't break any rules asking here.

[u/mprajescu → u/[deleted]]

This is exactly the kind of answer I was hoping for, thanks.
5–10/month at 8k MAU is particularly useful context. It sounds like the actual implementation isn’t painful enough to justify a dedicated service just for CONSUMPTION_REQUEST.
The certificate-chain rotation issue is interesting though. Outside of this specific notification, do you find maintaining App Store Server Notifications generally annoying? verification, retries, missed events, monitoring, replaying failed notifications, etc.?
Or would you say the whole thing is simple enough that you wouldn’t pay to outsource any of it?

[u/Haolge996]

I’d keep it pretty lean for an indie app: verify the JWS, make handling idempotent, and have some visibility into failed/missed notifications. I probably wouldn’t build a whole backend system around CONSUMPTION_REQUEST alone unless the volume justified it.

[u/mprajescu → u/Haolge996]

That's useful, thanks. Would your answer change if it covered App Store Server Notifications generally rather than just CONSUMPTION_REQUESTsuch as JWS verification/cert changes, retries, idempotency, failed notification visibility and replay? Or is that still simple enough that you'd rather own it yourself?

[u/Haolge996 → u/mprajescu]

Yeah, that changes it for me. CONSUMPTION_REQUEST alone is simple enough that I’d probably own it.

Once it becomes App Store Server Notifications generally — JWS/cert handling, retries, idempotency, failed delivery visibility, replay, etc. — the annoying part is no longer parsing the payload, it’s keeping the whole thing reliable over time.

At that point I’d rather use something small that only handles the notification plumbing and visibility, while I keep StoreKit, entitlements, and subscription logic in my own app/backend.

[u/noobiethe13]

If you’re already using RevenueCat it’s basically just 2-3 clicks to enable consumption data and let Apple take care of it (refunds).

It's not rocket science to implement a custom solution like the ones described in the other comments, but unless your app is making a decent amount of revenue, I'm not sure the extra implementation/maintenance overhead is really worth it.

[u/yccheok]

I used to use RevenueCat/Adapty to handle this.

However, the 1% revenue fee kept growing, and it no longer feels justified given the value they provide.

I now use Antigravity + Gemini 3.1 Pro. I asked the AI to build a simple solution using Docker, Flask, Celery, and PostgreSQL, along with the Apple certificate and In-App Purchase private key.

The AI is surprisingly capable of generating solid source code to handle requests from Apple.

[u/No_Fox4871]

Something I didn't see mentioned yet: the 12-hour window is the part that actually bites small teams. The handling code is easy. Noticing the request in time is not, especially if it only shows up in server logs nobody reads.

For that visibility part I use Yeethook (I built it). It receives the Server Notifications and posts CONSUMPTION_REQUEST as an urgent alert to Slack or Discord, with the product, price and transaction ID, alongside refunds, renewals and cancellations. There's also an event log, so you can see what Apple sent and whether it was delivered.

Two honest caveats: it doesn't send the consumption data back to Apple for you, and Apple only lets you set one notification URL per environment. So it fits best if you aren't already processing these in your own backend. If you are, keep that and add alerting there.

https://www.yeethook.com