Refoid
Automate App Store refund responses and track every outcome
Start new thread

Refoid - Automate App Store refund responses and track every outcome

by
•
Refoid automates App Store refund responses for iOS and macOS developers. Connect your apps, set your response preference, and track each request, response, and Apple’s final decision in one timeline. Get automatic retries and email alerts for confirmed refund declines, with no backend integration or success fees. Apple makes every final refund decision.

Add a comment

Replies

Best
Maker
📌
Hi Product Hunt! 👋 When a customer requests a refund for an iOS or macOS purchase, Apple can ask you for information to help review it and decide whether it's reasonable or not. A lot of developers don’t know about this. Those who do often need their own server to handle these requests. I built Refoid to make this process as simple and automatic as possible, so every incoming request from Apple gets a response and help to decline all unreasonable refunds. My priorities were straightforward: make it easy to add and manage apps, give developers a clear history of each refund request from start to finish, and keep the price reasonable. I looked at the existing options, but none quite fit what I wanted, for a few different reasons. So I decided to build my own. What you have to do? 1. Create an account. 2. Follow the quick setup guide and connect your app. Done! Refoid takes it from there, so you can spend less time thinking about refunds and more time building. You'll get an email notification on every successful decline with refund details. Every step comes with clear instructions, even if you’re just getting started as a developer. Statistically you can have ~70% of refund requests declined, but remember that Apple always makes final decision based on their own metrics. Hope you enjoy the product! Let me know if you have any questions.
Maker
Fair concern. It doesn’t just keyword-match the refund reason and fight everything automatically. The decision is based on the rules and data you provide, and Apple still has the final say. In practice, with our current setup, around 70% of refund requests get declined, not 100%, so it’s not a blanket “contest every refund” approach.

since Apple makes the final call anyway, I'm not clear on what automating the contest step actually buys a developer beyond saving a few minutes of typing. the part I'd want to understand before using this is how "unreasonable" gets decided, if it's a keyword or pattern match on the refund reason, that seems like it would just as happily auto-contest a genuinely wronged customer as a chargeback abuser, and getting an automated pushback response is exactly the kind of thing that turns an annoyed customer into someone leaving a one star review about how the developer fought their refund. is there a human review step before a contest actually goes out, or does it fire automatically based on the rules you set up front?

70% decline rate is a useful number, thanks for sharing it. the part still open for me is the human-review question specifically, not the decline rate: does a contest go out automatically the moment your rules flag a request as unreasonable, or is there a manual approve step before it actually reaches Apple? that's the detail that decides whether "the rules you set up front" can misfire on a genuinely wronged customer without anyone catching it first.

Maker

 I missed your question, sorry. Yes, it goes out automatically when automation is on. There’s no manual approval before each response.

You set the response preference for the app. Refoid doesn’t decide whether a refund is unreasonable. And I shouldn’t have used the 70% figure here - that’s Apple’s decline rate, not a measure of which requests we respond to.

The benefit is not having to build and run the webhook, retries and tracking yourself. But yes, that leaves the concern you raised about individual cases.

 appreciate the straight answer, and fair on the 70% correction. no manual approval step is the honest tradeoff to name out loud though, most tools in this space would rather stay vague about it. for us that means the risk sits entirely in how well the rules are written up front, so probably worth asking: is there a way to review a sample of auto-sent responses after the fact, even if not before, to catch a bad rule before it compounds?