We want to offer a ‘prize pot’ in our application, in that two or more players pay money into a prize fund, and the winner of the game gets this money. We were thinking of using PayPal to store the money, and then distribute a percentage to the winner (with us taking a small percentage). However, we’re not sure if this would infringe any of the guidelines surrounding iAP’s (in-App Purchases). Would this PayPal system be viable? Another possible approach would be to allow iAP’s to purchase virtual currency within the app, which the winner could redeem for real money via a PayPal transfer.
Furthermore, we believe this falls into the gambling sector, and according to the App Store guidelines:
20.5 - Apps that offer real money gaming (e.g. sports betting, poker, casino games, horse racing) or lotteries must have necessary licensing
and permissions in the locations where the App is used, must be
restricted to those locations, and must be free on the App Store.
20.6 - Apps that use IAP to purchase credit or currency to use in conjunction with real money gaming will be rejected.
We have seen an application on the App Store that has similar functionality: Pact (Pact: Earn Cash for Exercise, Healthy Living, and Eating Right). Pact allows users to set up a ‘pact’ for example going to the gym 3 days in a week would earn you $1.50 each day you complete. Or else you are required to pay out $5 per day you miss. This app has recently been updated on April 1st, 2015 and it has similar functionality to our idea, in that users agree on a price to pay out (via PayPal) if they do not complete a task. Would our idea comply with the App Store rules?
Any suggestions are welcome, Thanks
Related
we have an app which has both services at 30% online video and 70% offline onsite serivce for customers. As the policy defined by Apple company that any online service virtual through APP will be charged 30% of total amount.
The problem is that our app is not a full virtual services providing to customers but offline onsite services are also involved.
What will Apple company define our app according to their policy?
What is a better way for us to avoid the 30% charge collected by Apple Company?
I will so appreciate if any replies or advice.
Here are few points you may like to see :
If you are using Consumable or non consumable inApp purchases than there will be fix 30% charges will be taken from Apple. And that will be fix in all cases of this types of inApp purchases. Developers already requested to Apple to reduce this charges to 15% but yet rates are same.
If you are using subscription based inApp purchases than the rates will the same 30% for the first year. After the 1 year rates will be changed to 15%. So after 1 year of subscription period you will get 85% of amount from original.
Important Note :
Above facts & figures are according to the current rules & regulations stated in Apple's official Site. So there is no chances of getting anything wrong.
Hope this will help everyone.
I am now setting up IAP in my app and all is running fine in the sandbox environment.
The products in my app are consumable products. Users will post ads on my website once the purchase is successful. The ads on my website has a limited time (I.e. It will expire after 20 days).
If users purchase the products in my app and the ads are posted on my website, after some days, say 14 days (I've heard that users can request a full refund in the first 14 days without specifying any reasons), they request for a refund from Apple. Then this undoubtedly affects my apps revenue and Apple seems to provide no measures or policy to protect the developers.
How can this be prevented?
Due to a range of legal requirements in various countries, Apple are required to provide a "change of mind" refund on both App and In-App purchases. As an App vendor, you're agreeing to this in the various documents you "sign" to become so. That basically means you have to absorb any loss that may occur from this (such as you describe). Luckily this doesn't seem to currently be a major issue, and as long as your IAP pricing is reasonable, you shouldn't expect to encounter this on a regular basis. I suppose in some ways you can consider this the digital equivalent of shoplifting. It's something that will probably happen to a very small degree, but if your prices are good, and the environment is friendly, it's far less likely to happen.
We sell minutes to call other countries, and we want to allow users to make payments within the app. These minutes have a cost to us from wholesalers. Using in-app purchase will dramatically increase the cost to the user if Apple takes a 30% cut.
1 - "You must deliver a digital good or service within your application. Do not use In-App Purchase to sell real-world goods and services." (Source)
I'm not sure if this applies to me or not. Can anyone shine some light on this?
Only Apple can give you a definitive answer, but the way I would interpret the paragraph quoted below, you have to use IAP for purchasing credits, and you also have to be able to use those credits directly within the app (i.e. make phone calls):
Apps that use IAP to purchase credits or other currencies must consume those credits within the application
Section 11.2 of the App Store Review Guidelines says this:
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
If the minutes you are selling are consumed by an iOS app (any app, not just the app in which the user buys the minutes), then this rule applies to you.
If you are selling minutes that are added to a calling card that the user physically possesses, then you might be able to bypass Apple's IAP, but you'll have to either submit your app or talk to someone on the review team to be sure.
What you're selling is a digital service - connectivity. Your IAP product is similar to credits in most games in available on the store.
The real-world goods and services they prohibit are things like you'd carry out of a store in a shopping bag, or having somebody carry that shopping bag. They don't allow the sale of tangible things, only electronic. Goods for sale should be transferrable between two different devices.
I don't think you can avoid in-app-purchase for what you're trying to deliver from inside the app.
I think your case is much like Skype iOS app. You will need to go through in-app purchase for your app as the credit will be used to make calls via app to other countries.
I have a question about in app purchases. My company charges customers for access to our software system. They are charged to use the system (subscription fee) and then can opt to use higher quality data (satellite imagery). We have multiple imagery sources but one that provides better imagery (5 meter resolution vs 30 meter resolution) charges for it (the lesser quality imagery is government provided and free) and we pass that cost to the user in the form of credits. We require the user to per-purchase credits to "activate" a boundary (provided imagery is available at that location).
Apple allows us to "activate" and charge against a customer's credits (at least hasn't rejected the app based on this yet).
My question is if we can use our own purchasing system to add credits in the app? It does not unlock features in the app. Anything you can do with the higher quality data, you can do with the other free data.
In the App Store Review Guidelines (https://developer.apple.com/appstore/resources/approval/guidelines.html#purchasing-currencies), section 11.3 states:
Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
Does this mean we are allowed to use our own purchasing system to process payments for goods and services used outside the app? These same credits can be spent through other software we provide as well as third part software (we offer third party support through our APIs).
I need to preface this with several caveats
Carefully read all of your Apple contracts
Nothing is guaranteed - Apple's reviewers can be touchy in this area and Apple has been known to change the rules in this area
Until you build and submit it, I doubt anyone can give an authoritative answer - all of this is opinion.
I believe Apple will allow this but will not allow you to, in any way, encourage users to use (including links or text references to) the alternative method of payment from within the App. The rule is they want a 30% cut of any revenue the application generates. Only if the revenue is generated elsewhere can they be cut out. Amazon Kindle app has fought this battle. Also note that once they get the idea that this revenue is somehow "theirs" then it will be difficult to convince them otherwise. Be very careful on that first submission.
I'm building kind of a mobile marketplace on which users can offer and buy services that are only valid for a short time (for example, 5 hours).
Is there a possibility to implement a in-app payment method (in iOS/Android) for that? The problem is that in "normal" in-app purchases you have specific, pre-defined goods or services that are bought in the app. In my marketplace, user can offer lots of different services themselves (various products, prices, etc.) so specific products wouldn't help.
Thanks in advance and kind regards,
Clemens
I can only speak for the iPhone
And as you have figured out already, it is not possible. You have to create all your in-app-purchase products in iTunes Connect, and they all have to be reviewed by apple.
And if you mean physical goods when you say "various products" then it isn't allowed anyway.
IAP is only allowed for stuff that is used inside your app.
This answer is about the iOS app store, from what I understand the Android marker is basically the wild west.
The obvious solution is to sell people "tokens" of some sort in the app, then let them trade those tokens to other users for their products/goods/services. Then you need a way to redeem people's tokens for cash, presumably keeping a modest cut "for the house". I don't see anything in the App Store TOS that would outlaw that.