> You’re approaching this from the premise that you pay a commission for payment processing, when in actuality the primary purpose of the commission is to collect payment for the use of Apple’s IP. All the rest is secondary to that.
The IP I'm paying for is all tied to their payments platform. I would rather use none of it. I'm also paying separately for the right to develop and publish on their store via their annual fee.
> A decent amount of developers actually complain about how easily Apple gives refunds going by posts I see on different forums, but I prefer it this way.
We have a subscription offering, so the consumables experience may be different.
> This seems like a rather extreme solution. Was there a big issue with your app that compelled you to do this?
No. We have a freemium model with a subscription pro tier. The user was on the paid plan for a few months and messaged us that he actually gets enough value out of free tier features and would like a refund. It's very understandable that many decision makers in that position wouldn't issue a refund. But a single negative review can hurt us a lot, so we try to go out of our way to avoid that happening.
> If you mean a trial and then a temporary discount then no, there’s no direct native way of doing this. [...]
Yeah, this is the scenario I'm describing. Creating new products is laborious with setting international pricing and replicating for different discount levels across monthly and annual recurring subscriptions.
> Depending on how “ad-hoc” you’re talking about, wouldn’t offer codes fulfill this desire?
The use-case was to enable "Pay what you think is fair" pricing with a slider. Similar to what TrueBill/RocketMoney does.