My app is basically supposed to sell ebooks and need to distribute via Android Market. For payment options, I would like to use PayPal. So, straight to the point, am I allowed to use paypal as payment option for digital goods(in my case Ebooks)? I had googled for it a while. But nothing worth referencing came up to me.
I also read through Android Market terms and didn't quite get it whether they allow such option for in-app billing. All I see from their docs is referring to Google Checkout. Any help would be greatly appreciated.
Well, just for information, I refer to http://www.google.com/mobile/android/market-tos.html .
Just to keep up, http://www.android.com/us/developer-content-policy.html#showlanguages this link may well more specific to my situation.
In general, you need to be careful - the TOS of the Android Market generally require you to use Google's payment processing options to charge users (see "Paid and Free Applications").
That said, they name two exceptions, one of which seems to apply in your case - "Where payment is for digital content or goods that may be consumed outside of the application itself (e.g. buying songs that can be played on other music players)". If your app sells ebooks in the form of standard files (like epub or pdf), you should be in the clear.
I believe you can sell digital content using paypal via your app - however I don't think you can use Google's In-App Purchasing system - that has to go through the Market Place, and is linked to a Google Checkout account.
So you'd need a separate delivery and authentication system.
Related
I’ve built a SaaS website with subscriptions, enabled by an external payments processor (which could be Stripe, Braintree, Paddle, etc.).
Now this website for my SaaS has been packaged in a small WebView wrapper and is about to be released as an Android app. But on the Stripe website, I found this:
Google’s developer terms require that purchases related to the app, such as premium features or credits, are made via their native In-app Billing API.
– https://stripe.com/docs/mobile/android
Diving deeper into Google Play’s terms, you can find this (emphasis mine):
Developers offering products within a game downloaded on Google Play or providing access to game content must use Google Play In-app Billing as the method of payment.
Developers offering products within another category of app downloaded on Google Play must use Google Play In-app Billing as the method of payment, except for the following cases:
Payment is solely for physical products
Payment is for digital content that may be consumed outside of the app itself (e.g. songs that can be played on other music players)
– https://play.google.com/intl/en/about/monetization-ads/
So that seems more permissive than Stripe’s interpretation, and since my SaaS is not a game and can be used via a generic web browser as well, my understanding would be that using an external payments processor instead of Google Play’s billing is fine.
On the one hand, this would mean that most digital services could avoid Google Play’s billing and use something else, which seems (too) fair on Google’s part. On the other hand, this excludes games, which Google can generate a lot of revenue from, so it may be reasonable again.
This is not a legal question, and the answer could not be found in legal literature or by asking a lawyer, anyway. Instead, it’s entirely up to Google’s discretion whether using an external payments processor is allowed or not, based on one’s interpretation of the terms presented above.
So instead of legal advice, I’m looking for practical guidelines and examples of real-world usage that supports any interpretation of the terms above.
One example that I’ve found is Dropbox: Having downloaded their app on Android, Dropbox allows me to select between two payment methods: Google Play, or debit card on Dropbox’s own site. This seems to support the more permissive interpretation of Google Play’s terms.
Another example is Spotify, which opens a WebView where you can choose from several payment options, none of which is Google Play. The app still has Android’s permission for in-app purchases, though, which is also disclosed in the Play Store, so perhaps they’re using Google’s in-app billing in specific countries only.
Are there any other real-world examples?
There are such apps. Various network providers for instance, one could argue that ability to use phone calls or internet is not a physical good. Specific example would be Skype, which allows buying skype credit from a webview within the app.
But I think a good example for you would be WPS Office android app, which suggests upgrading to premium with an in-app subscription or a credit card payment.
For sure, all (real-money) poker application are real-world example. (pokerstars for example)
I had never seen a poker application which use Google Play Service for billing. (maybe for legal reason)
They are using an hosted web-page (in a webview or in an encapsulated builtin web-browser) to treat payment processing on their side, which allow end user to select a payment methods in a big list.
Note that in that case you have to treat by yourself the user balance (which implied to treat all the security on payment processing on your side)
I think the mobile banking applications is simple example one of them. You can pay your bills, send money via mobile banking apps. But there is no need to use Google Play Service for billing. The all transactions will complete on the banking side. You can even send money directly to some betting sites. (If you want I'll share with some mobile banking apps for this features but you need to login, you have to be customer of the app owner bank)
I just want to share it for an idea, I think you can build your own crypto currency with Ethereum infrastructure called smart contracts. Its really easy to deploy. You can find 10mins tutorials for this. You can use as a money in your mobile app. In this way If someone need to be buy something they have to be purchase some of your crypto currency. And the google side you will be exception because of this,
"Payment is for digital content that may be consumed outside of the
app itself (e.g. songs that can be played on other music players)"
But as you said,
it’s entirely up to Google’s discretion whether using an external payments processor is allowed or not, based on one’s interpretation of the terms presented above.
I'll signing under this.
You can also examine crypto stock market applications. I can bet they did not charge Google Play commission
Some of the information is not exactly what you want, but it's just for sharing ideas.
I think Quickbooks by Intuit (accounting software) is an example of a SaaS solution which, I believe, does not go through Google:
https://play.google.com/store/apps/details?id=com.intuit.quickbooks
Another example is Invoice2Go
https://play.google.com/store/apps/details?id=com.invoice2go.invoice2goplus
These solutions are available through different devices (iOS and Android) and thorough web. It doesn't make sense for Google to take a cut since the Android app is just one of many different user connection options, just like Google's songs/music example.
I'm starting developing and app about fights and violence and i'm planning to distribute this app through the Google Play Market, like i did with all my other Android apps. I usually develop and publish apps for children, so i'm scared about publish something that is really far from my other published apps. For example I'm scared about the fact that an user, while is looking for one of my child related app, can see the violence app in the "other apps from this developer" section.
Is there a way to avoid that or the only solution is to buy another developer account?
Unfortunately, More from Developer and related search on site and Play app is based on developer's name.
For example, search for more from developer looks like this: https://play.google.com/store/apps/developer?id=publisher_name and for devices market://search?q=pub:publisher_name
The only option is to register separate Google Play publisher account.
To create another account for the sheer purpose of publishing an application which is violent and should not be seen by users of your other applications, is purely a subjective matter. If you believe this is the best way of doing so, go right ahead. I don't see how it will affect any other factor.
That being said, when you publish an application, you already have the option (a mandatory one, I might add) to select the Content Rating. The recommended selection for such an application could be High Maturity. Read more about it at this link.
I would like to make my app freeware, but if a user is willing to retrieve additional features, it should be possible to 'activate' them after in-app payment.
Should I set up my app as "FREE" (or can that cause trouble later as this setting can't be change anymore?) and which way would you recommend to go - should I retrieve the additional stuff from my own website, or does Google provide a way for it after payment was successful?
Basically the app will be (and stay) really useful (well I hope) in its free state already, I just want to kinda provide additional goodies for the few that would be ready to support and maybe want to get even more out of it.
Yes, set up your app as free.
What you're describing is the freemium model, where you give the app for free, and charge for advanced features:
http://en.wikipedia.org/wiki/Freemium
A lot of Android apps are successfully monetizing using the freemium model. One example is Angry Birds Space, a top downloaded free app, which uses in-app billing to sell Mighty Eagles or remove ads.
I am currently developing an application where I want to be able to have an option to allow the user to donate money for the app. Is there a particular way about doing this for android. I have tried looking at google but it mainly shows about paypal donation buttons for websites
I think it should be possible.
There's a similar discussion on Google Groups which basically says that donations are allowed as long as you don't offer additional functionality for that money.
Meaning no functionality is enabled after the donation is made.
Like #alocaly said, you're unable to recieve donations through a system different from android market payment or ads inside the application.
However, it is still possible to have your application on the Internet by free and with a donation button. The difference is that you cannot post it on the Android Market, so you'll have to do some extra work:
Upload to a webserver, so it can be downloaded to your phone.
Create a website (or post your application to another "illegal" market), so people can find your application.
Use some sort of advertising to let people know your application (Twitter retweets, community ads, GoogleAds, SEO, whatever)
Manage some kind of update system. Since you don't rely anymore on the Android Market, you don't have an automatic updating method (Android Market updates applications when you post a new version of it), so you should have a small class that checks a website looking for a new version (it's not that hard) and downloads a new version when there's one available.
Make work the Paypal button like #Tim said
However, you are able to do something that I've see out there: create a free version of your application and post it on the Android Market, and post another version of the same application called "Same program name (Donation)", costing some money. When someone wants to donate you, they'll only have to buy this version.
I hope it helps
I don't know what importance it has, but I think that the chart / terms of services we sign as android developers don't allow the usage of this kind of monetization.
As this is a subject that is changing a lot in Android world, with the soon to come API to pay in apps, I'm not sure it still has any importance, but you should still be aware of that.
Maybe you should take a look at this post, which explains how to integrate Paypal payments into an Android App witout leaving the App itself: How to integrate paypal donate in android app?
Edit: Android now supports in-app billing!
Original question:
It looks like Android won't natively support in-app purchases for a while, and when it does there might be a huge user base with devices that don't support them.
What's the best way to implement iPhone-like (additional content or services) in-app purchases in Android using the Android Market if possible?
The solution should consider in particular:
For all kinds of in-app purchases: Android Market's 24-hour cancellation policy
For consumables/non-consumables: storage of additional content (ie: use precious application memory to avoid piracy, or use SD card to avoid bloating application memory)
Thanks!
This has changed as of today! There is now an example on the Android Developer site here: https://developer.android.com/google/play/billing/billing_overview
You can create a premium key application, that will have a key. How you expose that it's your deal ( or you can just check if PremiumKey activity exist ). From the main app you just check for your key and if it's exist enable premium option )
If you're talking about buying OTHER apps from yours - build your list with market url pointed to the other apps ( market:// )
It is against the Android Market Developer Distribution Agreement to take in-app payment:
3.3 ... All fees received by Developers for Products distributed via the Market must be processed by the Market’s Payment Processor.
Looks like Paypal has launched a library for accepting in-app payments. See here. Not sure if this system violates the T&C though.
You say that Android Market doesn't support in-app purchases, and then ask how you can implement in-app purchases using Android Market?(!)
Anyway, if and when they do support it, I imagine it could be distributed as an update to the Android Market application itself, so most users would be able to use the functionality. I believe the Market app updates itself automatically.
Possibly the Market would accept an Intent to trigger a payment via the usual on-device mechanism and return your app (or more likely your server) a callback.
There is also another in-app payment platform for Android applications called MoVend (www.movend.com). I have checked it out and there are several benefits using it compared to the other 2 mentioned earlier:
Many payment channels : Operator Billing for more than 38 countries, PayPal and virtual credits.
Many distribution channels: They work with developers to distribute their applications through the various distribution channels like Operator AppStores , OEMs and Android applications website. Marketing is something we all need. They are also invested by Singapore Telecommunications who has a strong presence in South East Asia.
They provide a sales analytics for you to track, trace and monitor the performance of your apps. Since they are available worldwide, you can always tailor your applications to the different geography area.
I am trying to build Android applications and monetizing is important.
Reply this thread so we can discuss how we can monetize our Android applications.
Here's another free licensing and payments system. The nice thing about this one is that it allows you to offer your app in any app store.
You can find more details # http://www.cloud4apps.com/
Check out http://mobpaynet.com, they are doing something like this. Not sure if it violates terms or not, but I will probably check it out.
For implementing in-app purchases in Air applications you may use third-party libs (Adobe AIR does not support In App Purchases for any platforms out of the box). For example, developed by Milkman Games (unfortunately, they are not free)