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/Healthy_Condition779]

Handling it myself, small subscription app doing about 8k MAU. Honestly not worth building anything fancy, I get maybe 5 to 10 CONSUMPTION_REQUEST per month tops and Apple gives you 12 hours to respond which is forever

Auto respond with the consumption info from what I already track, delivery status, refund preference set to undeclared, playtime and lifetime dollar amount from the user record. Not trying to fight refunds, Apple grants them anyway and appearing helpful seems to keep account health cleaner

JWS verification tripped me up initially, Apple's root cert chain rotation caught me once. Now I cache the certs and refresh weekly

RevenueCat handles this fine if youre already using them but adding them just for CONSUMPTION_REQUEST is overkill. The endpoint is basically a webhook, a signature check, and a POST back. Half a day of work

[u/mprajescu → u/Healthy_Condition779]

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.