I've come across a collection of android apps that utilise a questionable practice.
With the help of misleading ads user gets tricked into buying an app via SMS service (with prices up to 10 EUR). Afterwards the user then can enter an activation code in the free app distributed on Google Play store.
The entire operation is in grey-area, because it is the user itself who sends the SMS and is responsible for the cost. Due to the nature of the ads, its mostly unsuspecting older people that get tricked into this, because they assume that they must do it or they'll have problems with their device.
In app functionality being sold outside of the app store would most likely be a violation of Apple Store and the app could be reported.
I am wondering if there's similar rules for Play Store, so that this practice could be reported to Google.
The short answer is that Google allows this practice for now, but they are already working on changing it. From my experience, Google allows devs to use any payment/licensing model that their app requires. However, this is subject to change and the end results will be something similar with Apple's policy.
From their support page, it seems that from January 2021, they require that all new apps will use the GooglePlay IAP API. Existing apps have until the end of September to make the switch. As with any other policy, there are some exceptions, but please check the official page to receive the correct information.
Related
I have an Android app that has several features available as in-app purchases. We have published the app on both Google Play and the Amazon App Store. We need to stop offering one of the features as of a certain date. However, customers who have already purchased the feature should be able to use it past that date, even if they install the app on a new device. They should also still be able to purchase other features.
I was thinking that we could simply update our app so that the UI offered no option for purchasing the feature in question. However, that would not prevent a user with an older version of the app from purchasing the feature. So it seems like in addition to removing the feature purchase logic from the app (but not the feature itself), we need to do something to turn off the purchase at the store end. But whatever that something is, it must still allow the app to check whether the user had previously purchased the feature.
I've been unable to figure out from the Google Play or Amazon App Store documentation how to set this up. My understanding, from what I've read, is that removing the item (from either store) will cause checks for previous purchases to fail. Is it possible to do what I've described? We need solutions for both stores.
P.S. I did find one related question on SO: Are Google Play in-app purchases still valid if the app or the product is removed? However, it has no answer and also is a little too narrowly framed. (I'm not assuming that the product has to be removed and I also need to know about the Amazon store.)
I was thinking that we could simply update our app so that the UI
offered no option for purchasing the feature in question. However,
that would not prevent a user with an older version of the app from
purchasing the feature. So it seems like in addition to removing the
feature purchase logic from the app (but not the feature itself), we
need to do something to turn off the purchase at the store end.
For Amazon Appstore, you would need to contact their support team to get the in-app item in question suppressed (it's not a self-service as of today). Once suppressed, that in-app item would no longer be purchasable. It would not affect existing users who purchased that item in the past.
When it comes to in-app purchase I always opt for implementing everything in my own server. when a user buys something, I instantly consume it and notify my server. Then instead of querying Google or Amazon, I query my own server which gives me a lot of flexibility. If I face something like your problem I just add few lines of code!
Since you already published your app this may not work for you unless you willing to force users to update the app to the newer version. (Hoping you can do that!)
You mentioned that you don't know what happens if you deactivate the product and there is no documentation, well you can try it on a test project and see what happens! It shouldn't be that hard. If that doesn't work as you expect there is nothing you can do, your logic is in your app and it's already published so...
I'm planning to add In-App purchases to my Productivity app. Enhanced features are purchase products (e.g., freemium).
I would like to have user access to purchased feature on both Android and iOS, if he has purchased on any one platform. Technically I plan to store purchase information on server and have it retrieved whenever user logs-in on either device, and unlock the feature if already purchased.
Is this allowed in both iOS and Android?
Apple App Store Review Guidelines on Section 11 have this explained.
Points "11.1/11.2" and "11.14" sounds conflicting (or I'm missing something.).
On Android, I do not see this point mentioning in Policies.
If you had any experiences (w.r.t sharing purchase info between devices) that I should take care additionally, any suggestions are welcome.
I'd like to add a note about subscriptions. Here's the quote from Apple guide:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have both an iOS and macOS version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an macOS app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions
Link to Apple docs: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html
Quote from Android docs:
You can also build on your existing external subscriber base from inside your Android apps
If you sell subscriptions on a web site, for example, you can add your own business logic to your Android app to determine whether the user has already purchased a subscription elsewhere, then allow access to your content if so or offer a subscription purchase from Google Play if not.
You can implement your own solution for sharing subscriptions across as many different apps or products as you want ...
Link to Android docs:
https://developer.android.com/google/play/billing/billing_subscriptions.html
At the moment of writing this answer (May 23, 2017) Windows Store doesn't have subscriptions but they were announced during the latest BUILD conference. Some details here and here
Subscriptions should be available later this summer.
Answering myself. I submitted to App Store mentioning this case and got it approved. I'm yet to submit to Google Play so not sure about it.
Below the snippet I mentioned in App Store review notes that may help some
If user already purchased premium outside the app(our website or
Android app), then we are unlocking Premium as soon as user
logs-in to the app on iOS device. We do not include any button or link
or information inside this app regarding purchasing outside. If you
have any concern or comments regarding this, please let us know.
Additionally mentioned that our in-app item's service is based on user data at our server and not solely on iOS platform. I think this is the key point that makes sense to reuse user's purchase of our service. However, I do not find this case mentioned clearly in App Store review Guidelines.
[Update for April 2019]
As I've already answer here - from developer Apple guidelines:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So like #siddharth-gupta explain in his answer:
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation
Is it officially allowed (or tolerated at least) by Google to do it?
I've got some users suggesting to me that it could be a good idea to add a one click 'donation button' opening up their default Android bitcoin wallet app with my bitcoin adress pre-filled.
But hey, I don't want to see my apps suspended just because of this!
Did you see some apps or widgets doing this yet on Google Play?
The same question could be asked about Paypal donations I guess...
Thank you to share your opinion.
I don't know what Google's official policy is for certain, but a donation should be no problem. In theory.
http://play.google.com/about/developer-content-policy.html only mentions that any purchase of in-app benefits must be handled via Google's in-app billing system.
https://play.google.com/about/developer-distribution-agreement.html#pricing-payments says essentially the same in legalese.
So as long as donors do not buy/gain anything, not even a thank-you or honourable mention, and that is made clear in your app, you're in theory safe. Disabling ads for donors is for example easily a violation of those terms.
The rules are however Google's to interpret and enforce. And sentences like
The Payment Processor must process all fees a Developer receives for any version of a Product distributed via the Store.
in 2nd link can easily be applied to donations if the app-review person sees fit, even just because he/she misinterpreted the donation button or
If Google decides that your donations are actually fees, they can & will suspend your app (probably without prior warning & time to fix the problem). There are cases of this you can find on the internet.
There is an appeals form you can find here: https://support.google.com/googleplay/android-developer/answer/2477981 but the answer in practice seems to be "No. Don't ask again.".
Also be aware that Google counts violations and can ban you as a person (not just your current account) from publishing apps on the Play store.
The answer to the question is: NO.
You can't accept bitcoin tips or donations in your Android app, even it is free.
The same is applied for any kind of payment processor, including Paypal.
This because it violates our payments policy.
Policy Issue: Payments
Alternative payment mechanisms to Google Play's in-app billing service
are only permitted if the products purchased are to be used outside of
the app. For example:
For physical goods or services, such as movie tickets, or a publication where the price also includes a hard copy subscription;
or
For digital goods that may be downloaded to devices and used outside of the app, such as songs that can be played on other music
players.
Donations to 527 designated tax exempt organizations are also permitted.
Google don't have clear statement about this but i near future it's possible to allow it
Source
Yes you can. There are already plenty of apps that do this. On another note, for bitcoin donations, use the coinbase api. Its probably the easier in my opinion.
I have an application that I want to release for $x amount to the public, however, I want to allow the Google Developer Console Alpha/Beta APK to be downloaded for free. I want the testers to be able to download it for free? How do I do that?
Thanks in advance,
PS. I could swear I found the link on Google, but I can't seem to find it again.
Here is my conclusion (in short, no solution):
1- (Edit: unfortunately this point is not correct, you wont get the updates unless you download directly from the store.) The only issue is delivering the first APK to the testers, as they wont be able to download the application from the Play Store, however, downloading updates from the Play Store is doable and okay, (delivered APK must be signed with same key as Play Store APK).
2- If the application is never publicly released yet, testers must have some sort of a direct link to the application on the Play Store, as searching for it will never show up (even with package name: com.example.application). But after having the first APK, you can just look through the 'My Apps" section in the Play Store and find it.
3- Google sucks for not making this easier, especially given the triviality of the concept and the need for it.
Thanks everyone for your suggestions. But considering none of them were the answer, because there is no answer, I had to sum up my findings here.
Cheers.
After discussing this with a Google representative I found that there is a round-about way of offering the app for free to testers. The tester must initially pay for the app. However, it turns out that refunds initiated by the developer actually behave differently than those initiated by Google.
Google refund: License is revoked and the user will no longer have access to the app.
Developer refund: License is NOT revoked, the app will remain fully functional IF you are only testing for license response. If you verify Order IDs it will fail since the order status will have changed (this would be a custom implementation). For developers who implemented the recommended license verification example this would effectively yield a free app.
Caveat: I haven't tested this yet as my app is a couple months from release, but here's my chat:
me
Ok can you please explain the refund then. As I understood it a refund would deauthorize the user's license, so I assumed you meant refund outside of the Google payment system.
Artemis
If you yourself initiate the refund, the user will not lose access to the app in their library.
Unless you have designed your app to constantly check the order ID's status to trigger the revoke action or the like.
If a user initiate's a refund through Google, yes, they will no longer have the app in their library and they will lose access to the content.
me
OK, since I only check the license response from the server any refund I initiate will yield a fully functional and free app in the user's library?
Artemis
Well, I am unable to validate your app's code or what you have done in its design.
I am only able to confirm that if you refund a user's purchase for an app, that Google will not revoke the app from their library or their access to the app's content.
me
Excellent, perhaps I missed the documentation on this somewhere, but I searched quite thoroughly and most information states that the developer can NOT offer the app for free to testers.
This would be great information to add to the developer console help and the testing pages.
Artemis
That is true, you cannot offer the app as free to testers.
The app must be paid for, no matter what.
However, as with all apps, alpha, beta, or production, you are welcome to refund your users however you would like.
The google play developer console now give developers the chance to provide promotion codes offering a free app or free in-app purchases, perfect for providing a free app to Alpha and Beta users:
If I have an iPhone app, Android app, and Blackberry app, is there any way to implement a monthly or yearly subscription-based billing scheme such that a user need only pay for one subscription in order to use my app on any device? The problem is that each app store seems to have the stipulation that any fees required to use the app must be paid through them so they can take their cut.
Dropbox does this, but I think they can get away with it because their apps will work for free, and the subcription only offers more storage space. Is their any way to do this type of billing for an app which requires a subscription in order to be used at all? If not, will simply adding some sort of free functionality get me around this?
Thanks.
[EDIT]
Let me be clear, my question is about how this can be done legally. I'm basically running up into the same issue that caused the Financial Times to stop offering its paper through a native iPhone app. The difference between them and me, though, is that I don't mind paying the app markets their cut. I just want to know if this is possible; a user can either order their subscription through Android Market or the App Store, and if a user isn't paying through both stores then I think I'm violating the terms of one of the stores.
You could try Bango.But you need to implement a possibility to transfer the Bango User IDs between your different apps on the different devices. They offer a service where they bill a recurring fee to the user. They offer a SOAP-Based API (amongst others) you can use from your app.
But beware: there are some legal restrictions concerning inapp payment in the Apple AppStore and the Android Market and maybe also in the Blackberry AppWorld.