The in-app purchases on iOS have evolved greatly, if not rapidly, over the years since Apple has introduced the option to pay from within iOS apps using their payment system. They’re available everywhere where the App Store is, subscriptions are now available for most apps, webhooks were added, reporting is better and the Apple fee now drops to 15 % after a customer is subscribed for 1 year. All good improvements, but a giant and glaring omission remains, making the user experience worse for customers and lives more difficult for developers. Further still, Apple doesn’t show any inclination to fix the situation and fill in the feature void:

It’s impossible for app developers to search, cancel or refund iOS in-app payments.

 

Why is this important? 

To provide a better service and user experience for our customers.

Refunds. Sometimes a customer just upgraded short while ago, but accidentally made a double purchase or had different expectations of the functionality. In such cases a customer would contact our support and request a refund. When this happens best we can do is to tell them to contact the App Store support, as we can’t authorise the refund ourselves. This can be a bit difficult to understand for some, as we’re the ones operating Toshl otherwise.

Cancellations API. Our apps are available on multiple platforms. Let’s say a customer previously used the Android app and subscribed through Google Play or used the web app and upgraded via PayPal. Then, the customer buys an iPhone and extends the Toshl Pro subscription using in-app purchase. In this case, we’d automatically cancel the previous subscription on Google Play or PayPal, so only the most recent subscription on iOS would remain going forward.

This isn’t possible in the other direction. If a customer first subscribes using an iOS in-app subscription, then upgrades via PayPal, we’re not able to cancel the existing subscription on iOS. Best we can do is to tell the person to follow these rather convoluted instructions to cancel the previous subscription on iOS.

Unfortunately, this can quickly lead to accidental double payments as the customer forgets to cancel the previous subscription manually. Logically, they’ll contact to our support, requesting a refund where we can again tell them only to request it from Apple’s App Store support, thus creating more ire and a user experience quickly approaching Kafkaesque territory.

Search. Sometimes, we need to look up a specific payment. Either we’re not sure if it was completed successfully, we’re investigating a potential double payment or testing something. There are many reasons why this would be useful and of course goes hand in hand with the ability to refund or cancel subscriptions as mentioned above. This isn’t possible with iOS payments. While some of the data could be checked via APIs, most can’t, there’s no graphic interface to check.

The lack of these crucial components is even more evident when comparing to the other payment methods that we use. All of the functions mentioned above are easily available on Google Play, PayPal and Adyen (our credit card processor).

 

Why isn’t Apple fixing this?

I can’t be sure, but other than the lack of time and focus on other areas, a few possible reasons come to mind. It could be that Apple is afraid of a loss of control here. But their refund policies with their own support are quite liberal as it is. Potential abuse of the refunds could quickly be algorithmically detected. Other payment providers can seem to make it work well.

Privacy could be a potential concern, but it need not be. We’re not asking for any card details of the customer, addresses and names can be hidden, as Google Play already does. What we need most is the unique ID of the transaction and the ability to search by it and email.

It is possible that the refund ratio of all purchases would go up slightly, but it’s doubtful it would do so significantly. In any case, it’s a better long term business practice to let your customer choose your product because they want it not because the cancellation process is so damn convoluted.

 

We’ve contacted Apple’s support regarding this, but all we got is a standard non-response:

“I do not have any information on whether this change is in the works. I can advise you that Apple does take your feedback very seriously. Many changes to our program have been implemented by feedback from our developers.”

I’m sure we’re not the only app developers, who face these problems and would greatly appreciate to see these issue sorted. If you agree, please share this article so we can get some improvements to happen.

 

We love Apple’s products and for the most part they make our lives easier, both on the user as well as the development part. This is why this feels so much more as a black spot on an otherwise great user experience record.

 

Apple we beseech thee, please help us make user experiences better for both your and our customers.