Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
Related
I'm about to develop an app (for iOS and Android) that allows users to create a collection of digital content from their phone (e.g. some videos and pictures), and send that content to other users who can consume that collection on the same iOS/Android app. I'd like to bill users for sending a collection, because this process involves uploading and processing the collection to the cloud (which I pay for) and the recipient's app downloading it again (causing traffic costs). Note that I don't want to charge any money from the recipient!
The way I see it, producing such an iOS app is not possible (because Apple will reject it, see App store guidelines and In App Purchase Guidelines) for the following reasons:
Setting a fixed price for the app ("paid app") is not reasonable, because I want to charge the user each time he sends a collection, so IAP (In-App-Purchases) would be more reasonable
The IAP-logic/flow would be that a user can create the collection in the app for free and then, when he clicks the "send collection" button, he is asked to approve a purchase, in return he gets the link that he can send to his friend. The logic would essentially be the same in the Android app, using Google's "In App Billing"
Such an app could be rejected by Apple because of rule "11.3. Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected" - because the user essentially paid for hosting the collection, and that collection can be used outside of the app (by an Android app user for example)
OTOH it's also impossible to use external means of payment. For example, I was thinking about forcing users to first create an account on my website, where they can pay for a voucher (with Paypal, say) that enables users to send collections. They'd first need to log into their account in the iOS app and then they might see a warning that they have not yet purchased (or no longer have) any credits for sending a collection. The IAP guidelines forbid me to directly link to my website with a note saying that users can pay for additional credits by other means. When Apple engineers sees that message during review (assuming they aren't putting very bright people in charge) the app might be rejected, too. Even if it were not, this work flow is very uncomfortable for the user, I'd prefer IAP as this also makes accounting (taxes and earnings for my company) a lot easier.
I'd like to get your opinions on this. Please note that I might be "too hard" on myself. As a matter of fact, I do know apps that have been approved to the store that do exactly that, see e.g. here and here. Maybe they have been approved because paragraph 11.3 actually just forbids the ability to purchase the functionality of uploading (converting a collection to a link) and then use this functionality somewhere else - effectively that would mean "to buy credits for an external service" mechanism. My app wouldn't do this. You'd have to do the purchase and the upload/convert-to-link functionality would only work on that device where you did the purchase.
Any thoughts?
I have similar experience with an app i worked on. It was a GPS device showing tracking data in the app. The device uses cellular data to send tracking information and we need to collect a fee to pay the SIM provider which is an external service. We did this using Stripe payment but Apple rejected the app and asked to implement In-App purchase. Because we were blocking the user and asking to pay in the app that looks like we are asking payment for app digital content.
Based on my experience, to answer your question :
Yes you have to use In-App purchase and it can be Consumable type. When user try to send a collection, show a consumable purchase type. Keep track of the purchase in the server using purchase receipt, collection id etc.
Even though the amount collected is used for hosting and web traffic, you can term this as a service fee for managing/sending the collection. Behind the seen, you use this fee to pay your hosting provider or anyone else, that's up to you. Apple won't reject the app for this reason. Because you are charging a fee for digital service you are provided in the app. In apple guidelines, external physical service means, for example taxi charge in Uber, shopping goods price in amazon etc.
This is very common mistake developer often doing while choosing the payment options for any Payment related feature into application. Specifically in iOS there are new rules defined by the Apple for choosing the payment model for your application.
Here are some important points :
If your application having some points system or coins system for which you needs user to pay for than you must use the inApp purchase. And inApp purchase must be of type Consumable. So it will be purchasable multiple times
If your application offering any pro features or facility inside the application you must use inApp purchase. Type will be non consumable. (Note : For Non Consumable inApp purchase you must give Restore Purchase option into your application other wise your application will get rejected.)
If your application is providing any feature or any internal content access for limited time than you must use the subscription based inApp Purchase.
If your application is selling any physical goods than you must use any third party payment options. You can't use inApp purchase for it.
If your application is selling external services or any donation related feature then you can't use inApp purchase for it. This will be a complicated case & in this case according to the apple guidelines you should use the Payment gate way with Webview redirection. So the user will do the payment from the Webview redirected component.
Hope this helps to everyone.
I am developing an app for a client, where he wishes the app to be able to have users to sign up and try out the app for 14 days, after which they have to make a purchase to continue using the app.
My client does not want to absorb Apple's 30% cut for using Apple's in-app purchase mechanism. Initially I suggested implementing a 3rd party payment gateway, but it seems that Apple does not allow app that unlocks app functionalities via a 3rd party payment gateway.
My question is this: if we submit the app that allows users to sign up and login, but only use the app for 14 days without any form of payment mechanisms in the app to allow the user to continue using the app, will the app be rejected? As I was thinking to just have the payment gateway on a website, and during user sign-up, send the user an email informing them that they can go to the website to make a payment.
I know that Apple rejects trial/demo apps, but this is technically a full fledged app where users that purchased via the website will be able to login and perform full functionality. I will also provide Apple with a test account that is fully functional.
Thanks!
Short answer: Apple will reject you if you allow signups and block functionality after a trial period without allowing IAP. Period.
I have first hand knowledge of this, shameless plug in 3..2..1.., Simple In/Out offers a 45 day free trial, after which users are blocked from using the app. In the early days, we escaped Apple's ban hammer by being small and using a blessed trial account that never expired. Apple would review using test account, never see rejection or blocked alerts and prompts to sign up on our website. That did change one day after requesting an expedited review. We got a lot more scrutiny and they rejected us for essentially steering users to our website for subscribing.
The IAP for trials and subscriptions other than magazines is pretty terrible. It is essentially designed for magazines, and that's it. So beware going in. What we eventually did was allow users to subscribe in the app using IAP. Our server manages who is subscribed and who isn't. It also manages which subscription they have (IAP or our own). There is a lot of weird receipt checks you need to do to manage the subscription from Apple. The user is also stuck if they want to change to a bigger/lower subscription plan. Which kinda works for us because the only way to do it is email us, in which we can convert from IAP (-30%) to our own (-2.5% for card processing).
The moral of this story is that if you plan on allowing users to create accounts inside your app, then you will most likely be obligated to offer subscriptions via IAP. If you want to avoid IAP, then you will also need to strip any references to your website from your app and description. They will bust you on meta if you try and steer them around the IAP process. Once we added IAP, we were allowed to point everyone to our website for "more information" in which we are able to convert more users to our own subscription rather than IAP. Right now, our number of our own subscribers vs. Apple is about 75:1. So we don't lose much over the signups we get from Apple.
I believe this should be perfectly fine as long as the 14 day "trial" is a fully functional version of the app.
Your model seems similar to Spotify. Pay for subscription on their website, but use the service in the app.
These resources may help:
https://news.layervault.com/stories/9695-how-do-apps-like-lyft-uber-airbnb-skirt-apples-30-cut-on-each-transaction
http://www.quora.com/How-does-Apple-define-digital-content-when-taking-its-30-cut
My iOS app got rejected because we charge users with Stripe's payment service, and Apple requires us to use IAPs for payments.
We deleted the Stripe reload balance module from the app. Now the only way to recharge it is for the user to go to the website and make the payment. Does this solution work or does the app still have to use IAPs?
Apple has explicitly requested any submission to go through their iAP for any payment. Your rejection is expected and normal. You have two choices, asking a user to pay through iAP or accept the payment on your website. Both works, but you can't and can't explicitly ask your user to pay you directly.
Let's take Dropbox as an example. You can upgrade Dropbox account on their website. It works. But Dropbox isn't allowed to encourage you to do the upgrade in the app itself (unless the payment goes through Apple). That is, you can't do something like a button in the app that takes you to the payment form on your website. If a user knows how and where to do it on the Dropbox website without being told to do in the app, good, Apple doesn't take that 30% commission.
Unless your service is popular, most users wouldn't be bothered to goto your website and give you their credit card number for a purchase. You should consider just giving the 30% commission to Apple, you'll get more sales.
You are required by Apple to use IAP, and can only use IAP, if you are using the purchase to unlock code in the app. You may use other payment systems only if you are selling real world goods and services or, in certain circumstances, files that are being downloaded from your servers. If you use other payment systems they must be used outside of the app. This is explained in the app review guidelines, section 11.
Note that requiring the use of IAP for sales of code distributed by Apple may not be an issue under anti-trust laws. But in any event, if the "market" is smartphones then Apple is not a monopoly player since their market share is limited.
I'm building an app that will provide users with an evolving directory of companies in their local area (location-based) that manufacture green/sustainable products. I want companies to be able to add themselves to the app by purchasing a subscription using in-app purchase. This would be a 1 year subscription.
Just read this in the iOS Standard Agreement: 2.3 Content and services may be offered through the In-App Purchase API on a subscription basis (e.g., subscriptions to newspapers and magazines). Rentals of content, services or functionality through the In-App Purchase API are not allowed (e.g., use of particular content may not be restricted to a pre-determined, limited period of time).
If the service is only for a year, does this preclude me from doing the above? Anybody have any insight on any of this? I'd appreciate your input - I can't get any info from Apple. Thanks.
My guess is that you are not allowed to do that. As you really cannot restrict who subscribes for a year – it might be any user – you probably cannot offer this. The IAP doesn't provide any content or service to the user other that a listing. As you probably need an external data source (e.g. a web application) I would suggest moving the subscription there. This is just my opinion and I am no lawyer so I might be completely wrong here.
You can do it. See the image below. You just have to choose the right option.
You can find it itunesConnect in the app detail section.
For your case I suggest Consumable is appropriate and have to maintain a check that wether its been a year or not since the last magazine purchase or what so ever your scenario is.
The app I'm working on was recently rejected by Apple for containing an auto-renewable subscription. They recommended that we switch to non-renewing subscriptions for our content.
The one thing I can't quite wrap my brain round is how to restore a purchased subscription to a shared device. Apple recommends we don't use user login - something we would like to avoid ourselves. I did come across one solution where unique codes were used between the two devices - to validate a purchased subscription, through a server. But I believe that could be easily pirated, as in theory friends or employees within a company could share these unique codes with one another and avoid paying the subscription charge.
I can't really find much on Google about this, and was curious to know if anyone has been able to successfully implement a non-renewing subscription?
To paraphrase the advice we received from Apple when dealing with these issues:
Per the iTunes Connect Developer Guide:
...subscriptions must be provided on all devices associated with a
user. In App Purchase expects subscriptions to be delivered through an
external server that you will provide. You must provide infrastructure
to deliver subscriptions to multiple devices.
Apple consider user registration to be appropriate but won't allow you to make it obligatory. So registration must be optional and the user must be able to register at any time — including to allow them to share a subscription they've already bought between devices.
So it sounds like we may have received slightly different advice. Is it possible that Apple only told you not to require user login in general, separately from the requirement for distributing the subscription to all devices?