I am fully aware of Google rules regarding in app payments, but I am still not sure if my case pass these rules or it violate them, so I wanted to make sure and see if anyone have a better answer.
Basically I have a website where people register and buy a subscription for a X service, recently I built an Android app to correspond to the service of the website, my Android app shows a message to the users saying that if they want to buy premium subscription they have to go to my website, register and buy it there, the question is does it violate Google rules?
Thank you for any help.
Yes it does.
You are not allowed to hint that users can spend money somewhere else. Its also not allowed to link to external resources where the user can spend money.
Netflix is an example for this.
Netflix users can use the App with the account they created on the website.
Users that create an account from the App are forced to go through in app purchases.
Netflix App is not allowed to hint that users can get it cheaper through the Netflix website.
Related
I am working on an app that'll be available to specific customers, after figuring out that this approach does not work, I am switching to pushing it to the public as a free app but give login credentials to specific users. Would that violate any of the subscription rules by android? would the app be taken down if people can't sign up, knowing I will charge for the account personally?
You can do this easily using Firebase Authentication. Here is the documentation for it.
Just connect your app to Firebase, create login screen with Activity and create accounts with the usernames and passwords for your users and give them the credentials.
As for the Google Play billing policies, I believe this violates their rule that you should only get paid through Google Play so they get 30% of the income, however, if it all happens outside of the app, and there are no platforms to get paid through (like PayPal) integrated in the app itself, it shouldn't be a problem as far as I know.
have the following scenario:
we have an app that users need to pay for. But we also want to sell the app bundled with a book meaning there is a code / voucher in the book that can be used to use the app for free. Unfortunately we haven't found any good way to address this scenario yet:
a) make the app a paid app and use Google / iOS Promo Codes for the books - not good, because the number of promo codes per app and quarter is limited
b) make the app itself free but require users to make an in-app purchase to access most of the content. Alternatively make it possible to enter a code to access that same content. The code comes with the book and is created and maintained by us.
negatives: a lot of effort to maintain the promo codes, handle the in-app purchases and Google / Android don't like it if content within the app is paid for outside - so we could end up being rejected.
I'm really wondering: are we the first one with this need? is there maybe already a solution to this problem we are not aware of? We do not want to rip Google / Apple of their 30% share of app sales. But there doesn't seem to be a supported solution for this.
any ideas? thanks
Thomas
Welcome to SO.
This could be done but i dont know if this is the optimal solution.
Make the app free and lock down at the sign-in, there give link to your play books.
In the app check if the user has purchased the book using
https://developers.google.com/books/docs/v1/using
So if user pays for the book and downloads it, On the next app launch give access to him to use the app.
You should be careful with Apple's in-app purchase guidelines, 3.1.1:
If you want to unlock features or functionality within your app, (by
way of example: subscriptions, in-game currencies, game levels, access
to premium content, or unlocking a full version), you must use in-app
purchase. Apps may not use their own mechanisms to unlock content or
functionality, such as license keys, augmented reality markers, QR
codes, etc. Apps and their metadata may not include buttons, external
links, or other calls to action that direct customers to purchasing
mechanisms other than in-app purchase.
I think for users that purchase the book, they would need to register outside of your app (e.g. on your website). If you had some authentication system you could store a flag on the users profile if they've unlocked the book or not and give them premium access to your app upon logging in.
You can make your app free and set non-consumeable book SKU in your app.
If you want to send the promo code, you can use Google Play Console.
https://android-developers.googleblog.com/2016/01/create-promo-codes-for-your-apps-and-in.html
Google only allow a small amount of promo codes per app, 500/quarter. This is because they don't want to encourage developers to sell this promo code offline. But this is still an official feature supported by Google Play. You will be totally fine as long as you're less than 500/quarter.
I am building a website for a client that is promoting an App on Kickstarter. As one of the rewards this client wants to reward sponsors with in-app purchases. I have searched Apple and posted on other forums but I can't find out if this is possible and if it is possible, how it is done.
Thanks.
You need to implement a promo-code dialog inside your app to do that, then send promo-codes to your Kickstarter users.
I don't think It's possible.
Here's the only Google documentation I could find.
You could make the app free for a short period until all backers have their copy and then raise the price but non backers will be able to download it too.
It would be possible however to use the alpha/beta functionality in the Google Play store to release the app to backers who have joined specific circles setup by you. I don't know if Google would have a problem with you using it like this.
It might be possible to distribute the app outside of the Play Store but I suspect that will become a big support problem as users struggle to get the app installed and keep it up to date.
For iOS part we haven't this functionality with Store Kit. This framework was created to securely process payments from users. You don't need to work with payments. Just deliver some product or an extra functionality to user with promo code. Implement a dialogue in your app where user can enter his code, send this code to your server, check it and give an access for user, if code was right. That's all you need. After making the product available, your app needs to make a persistent record of the "purchase" like you do with normal in-app purchases.
I have to develop an app implementing in-app purchase, whoses purchases are suscriptions to a service (with a fixed price).
My client didn't ask me to use Google's in-app billing API, and asked me to provide fields for the user to enter his bank details instead (and to directly interact with banks I guess). I haven't seen many apps doing this (except maybe Uber), and I'm wondering what am I supposed to do.
Should I tell him to use Google's in-app billing API instead ?
Or should I develop this from scratch / using a library ? (I really don't feel confident about this...)
Thanks in advance for your answers !
That sounds like a bad idea. I certainly would immediately uninstall any app that asked for my bank account information. If it were me I would try to convince the client to go with Google's service, or at least some trusted third party - does Amazon have an in app purchase system for Android? I've only used Google's. That system is set up to allow purchases without giving credit card or bank information to the app. It may even be a violation of Android developer terms to ask for banking information, you may want to look into that.
Have they given you any reasons why they don't want to use the Google service? Is it possible they just don't know about it?
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.