I am in the process of building a Video On Demand kind of app for Android which is very similar to what Google Play Movies with a few differences.
I am done with most of the things for the app and now I am deciding upon the billing strategy for renting out movies from this app. By looking at Google Play Movies I found that if you rent a movie there, you are given a period of 48 hours from when you start watching the movie. I want to understand that is such a billing strategy possible using the In App Billing method already available for Android.
As far as I understand and have tried out, In App Billing is applicable to a list of products that I define in the developer console and the users consume but for a VOD kind of app where my video listing would change from time to time, this might not be the best strategy and might not be even applicable.
If that is the case then how are things working with the Google Play Movies?
Can anyone throw some light on what other options i might have of making the user experience as close as possible to what Google Play movies provides.
I have also explored other payment options of third party payment processors like Zooz and a few others but in my opinion of Google Play Movies is using In App Purchase or Google Checkout interface then is it possible for my app to use the same and if yes any pointers are greatly appreciated.
As you've worked out, you wouldn't have one IAP product per film. But you might have one product which is a single 48-hour rental, and the user buys this product and then cashes it in within your app to rent the actual film.
Really, it's the Google Play terms that decide this question for you. If the thing you're selling is only accessible within your app, then you must use Google Play's IAP functionality. If the sale is usable from outside the app (e.g. you can buy a rental on Android and then watch the film via a web browser on any device), then you shouldn't use IAP. This is all explained in the terms.
None of the parts of Google Play use the public IAP interface, even though they all go through the same billing system in the end.
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 want to publish an android app in he google play store in two modes:
The first free but with advertising. The second without advertising but the user have to pay. It is the same application but the difference is the ads.
Way is the best option to achieve this?
1 - One application that hides ads with a property? (app property, database property, etc)
2 - Two differents apps?
3 - Other solution?
Many thanks
All the best
I done it as 3 projects: one contains core project with additional hook and interfaces and two which implement end user application based on core. Technically it's looks like registering additional listeners for ads and IAP
I would recommend you keep it as one application with IAP so user can get rid of ads without losing any data and hustle. It's also good for google play rating as you'll have cumulative number of downloads and reviews
I have done this with all of my applications and I find that it's definitely better to keep it all in one application. With Android it's possible for your applications to be ripped after purchase and spread around for free without other users having to pay. Of course this isn't what you want so the way I get around this is to develop only one application. Inside that application have a managed in-app purchase that will remove ads. When the application is running, before displaying the ads, check to see if they have purchased the remove ads item and if they did don't show the ad. This stops you from having to repeat code and separate into different projects.
I should create one app, and create an unlocker for it to hide the ads. Most of the time you will see that some people will pay for your app once and then distribute it for free online. As you can see on the Google Play Store, there are a lots of apps, but if you want the full features you need to buy an unlocker. This kind of protection is much better compared to publishing two seperated apps.
Keep it in one project and use the Google in-app payments to manage the full version. If you have two separate apps people can just buy the full version, extract the .apk and then get a refund. That way they didn't pay anything and have the full version. They then can pass the .apk to anyone else.
In-app purchases are bound to the Google account, this does give you some security.
I launched an app on google play store this week. The app uses Google Play Games Leaderboard and Achievements APIs. Should the app page in play store app not show these icons/badges like it does in other apps that use these APIs? Do i need to enable it anywhere?
These are the icons/badges I'm referring to (image below). How do i add/enable these? Do i need to do anything in the app apk to get these?
Just had a chat with the Google Play support team. They said that it gets enabled automatically after a certain threshold (a few hundred users from what they said) is reached. So basically no additional configuration/setup is required to start showing the icons. I'm just going to wait a few days and see if it pops up. Will update.
I added Google PlayServices at beginning of the year, so its active almost a year.
Currently 330 users are in the leaderboard of my game. But that symbols still not appeared;-(
In general what I can see is that the initial requested acceptance of the PlayServices in my game, is distracting a lot of people. From 10 people who download the game only 3 will register the PlayServices.
Some of the other might even directly deinstall it, not noticing that my game can also used without.
A lot of people dont want it either because of privacy or because they expecting unwanted data traffic.
I have to create an application where a user makes a deal and then gives me (the owner of the application) a certain amount of money for the deel to be made available to the rest of the world. I was thinking of achieving this through Google Checkout, but I stumbled upon Android in app billing sdk. My question is, is it possible to use in app billing in my scenario?
The google in app billing works only officially with receivables (AFAIK) i.e. The most effective way i could see you doing this is to make the deal, then charge for an item called for example ("Transaction fee" / "Deal fee") and then the app runs as normal.
It's not reccomended that you start using your own payment system, purely if not anything else, support could drop at any minute and your app starts breaking the ToS
I got the answer :) We can use in app billing with Unmanaged products :)
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.