RefundHalt vs building refund handling yourself
Every piece is documented and public. The question is not whether you can build it; it is whether the maintenance is worth more than $29 a month.
The quick answer
You can absolutely build this. Apple and Google document everything: App Store Server Notifications V2, the Send Consumption Information endpoint, Real-time Developer Notifications, orders.reviewrefund. Some teams should build it, especially if refund handling is core to the business or data must never leave your infrastructure.
What the docs do not show is the operational tail: verifying Apple's JWS certificate chain, minting In-App Purchase API JWTs, computing percentages in milliunits (100% is 100000, and sending a percentage for an auto-renewable subscription returns an error), provisioning Pub/Sub for RTDN, and being awake at 3 a.m. on a Saturday because the 12-hour window does not care about your weekend. RefundHalt is that tail, productized.
At a glance
| Feature | RefundHalt | Building it yourself |
|---|---|---|
| Time to first answered refund | About 2 minutes | Days to weeks of engineering |
| Apple JWS verification, IAP key JWTs, milliunits | Yes, built in | Yours to build and maintain |
| Google RTDN topic and OIDC push plumbing | Yes, auto-provisioned | Yours to set up in Google Cloud |
| 24/7 deadline coverage with fallback | Yes | Yours to run and monitor |
| Store API changes tracked for you | Yes | No, you follow the changelogs |
| Usage evidence | Yes, from your endpoint or push API | Yes, it is your data |
| Full control over every byte | Partial, you set the policy | Yes, total |
| Data stays entirely in your infrastructure | No, we process refund events | Yes |
| Ongoing cost | $0 to $29 a month for most apps | Engineering time, indefinitely |
Where Building it yourself is stronger
- Refund handling is a core competency you want to own, not outsource.
- Compliance requires that store credentials and refund data never leave your infrastructure.
- You already have the always-on server team, and marginal engineering cost is low.
Where RefundHalt is stronger
- Speed: protected this afternoon instead of next sprint.
- The failure modes are already handled: deadline fallbacks, retries, notification dedup, certificate rotation, API changes.
- Both stores from day one, including the Google chargeback flow that did not exist until 2026.
- It costs less than the first refund it saves.
Pricing
A careful in-house build is typically weeks of engineering plus permanent on-call ownership. RefundHalt is $14.99 a month or $99.99 a year, everything included. If you do build in-house, our blog posts document the exact payloads and traps; take them.
Frequently asked questions
- What are the most common mistakes in DIY implementations?
- Sending consumptionPercentage for auto-renewable subscriptions (Apple rejects it), treating 100% as 1,000,000 instead of 100,000 milliunits, missing the sandbox's 5-minute window during testing, forgetting that Google records only the first reviewrefund response, and having no fallback when the primary path fails at night.
- Can I start with RefundHalt and move in-house later?
- Yes. Nothing locks you in: the store-side configuration is a URL and a key you can repoint any time, and your refund history is exportable through the API and webhooks.
- Does RefundHalt need my app's source code or an SDK?
- No. It operates entirely on the server side against the stores' official APIs. The only optional integration is a small usage endpoint on your server so responses carry real consumption numbers.
Sources
- Apple: App Store Server Notifications V2
- Apple: Send Consumption Information
- Google: Real-time Developer Notifications
- Google: orders.reviewrefund
Competitor information comes from public documentation and websites, verified on the date shown. Spot something outdated? Email hello@refundhalt.com and we will correct it.