What billing options could I use to allow users who download my app to have to pay for each additional device they install it on.
My app once purchased runs on tablets devices WITHOUT internet connection. GP allows users to install this on as many devices as they like using the same account details.
Increasingly my app is being used for commercial corporate use and I want a way to insure I get paid when the app is installed by commercial companies more than once. For example a Bar or Hospital has many tablets running my app, but they only paid once.
As far as I can see there is no specific billing to fit my purpose.
One thought was to display some kind of commercial user agreement at startup that stated that for non personal use they would have to purchase licenses directly to allow them to use it legitimately for each additional device they install it on.
This would rely on honesty, so can be ignored.
So my questions are:
Is there a billing method I've overlooked that could handle this situation?
Is there an alternative way to handle this?
Would I be in breach of GP if I had an commercial user agreement that sort of contradicts the GP billing model. eg paid apps can be installed on multiple devices owned by the same user account? And request additional payment for each device its installed on not using billing.
Related
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
This is the Android version of App for limited or restricted audience
The project
I'm going to start a brand new project for one of our customers that will be deployed to our customer's suppliers to track on-field activity. I am skilled enough on Java/Android development so this question is only about deployment.
Owned vs provided devices
Our customer will either provide a Samsung Galaxy Ace 4 device to the suppliers or will allow the supplier to use their own Android 4 smartphone without warranties from us. Our customer currently has a Google for Business organization set up, but we cannot rely on that (see partial answer).
Technical (non functional) requirements
Ability to easily distribute application and updates across enterprise users.
Application should not be visible to the public
Application must be able to send crash reports so our team can inspect and investigate
The question is
Given the above "should not be visible to the public" statement, what is the most effective and efficient way to deploy an Android app targeted only for enterprise users?
I'll post a partial answer below. I'm asking others to enrich it with other possible means, including using Alpha/beta channels for which I don't have experience about
Currently, limited-audience Android applications can be deployed like this:
Publishing on Google Play as a free app for the public
Maybe adding a limitation to our country
Advantages:
Simplemost and well documented
Auto deployes updates as soon as no new permission is enforced
Collects crash reports on Dashboard
Disadvantages:
Everyone can download the app
This has the disadvantage that some organizations may not be happy as publicly available code might in some cases help exploit vulnerabilites on remote systems (but it is almost impossible if app is well-written and obfuscated)
If country limitation is enforced, imported devices won't download
Distributing the APK direct URL
Advantages:
The app remains private (enterprise users are surely not going to redistribute the app to friends as it's no use without enterprise credentials)
Disadvantages:
No crash reports unless implementing a third-party library
No auto updates unless implemented by custom code or third party library. Implementing auto updates prevents the app from being published to Google Play in the future, even on a private channel, as Play prohibits apps that auto-update themselves via third-party channels. Or, to be precise, the auto-update feature and Play publishing require, in order to exist together, maintaining two APKs
Google Play for Enterprise
As mentioned on this link, Google Play provides a private channel for app deploying for users withing a Google for Business organization. This is the perfect approach for applications that organization's users must use
Advantages:
Same as publishing for the public (simple, auto update, crash report)
Visible only to restricted audience
Disadvantages:
Every device must come with a Google account within the organization, and it will be economically unfeasible to [request the Sysadmin to] enable Google accounts for every external supplier in our target organization
Permanently in Alpha/Beta
I haven't tested this yet, as it is also very tricky. Basically, it involves using testing mode without ever going to production. With Google Play, one can deploy artifacts into Alpha (e.g. test server environment) and Beta (a trick to point to production server environment) without ever moving the app to Google Play's Production stage.
All requires setting up special moderated Google+ groups
Potential advantages:
Same as publishing to enterprise
Disadvantages:
Only telling users to subscribe to Google+ and joining a community
From your requirements, I would suggest distributing the APK via a direct URL and integrating a service such as HockeyApp (see their Android SDK for more) to manage both the crash reports and app updates.
"Ability to easily distribute application and updates across enterprise users"
Many services allow .apk files to be uploaded directly to their service for deployment. A direct download link is then generated for that build.
Crash information is collected and updates are automatically displayed if the app implements the Android SDK provided by the service.
"Application should not be visible to the public"
Services such as HockeyApp do not publicise direct download links publicly. This link can therefore be distributed as required.
"Application must be able to send crash reports so our team can inspect and investigate"
Full stack-trace and device information is sent along with crash reports and can be viewed online by technicians.
From my experience there are a few pros and cons:
Pros:
App distribution is super easy, as simple as visiting a website.
Bug reports are comparable to those received through Google Play
Cons:
Crash report's aren't sent automatically and updates aren't automatic
By default, updates and crashes appear as system dialogs prompting users to either send the crash report/update the app or cancel. Ideally, no user interaction should be required to perform the desired actions. I am sure it is possible but have not found relevant documentation for it.
Cost. These services aren't free.
Would require the removal of the service SDK from the app if uploaded to Play Store
We have an application for the PC and we're thinking of writing an Android version of it. But I have a question about how Google Play and in-app purchases work.
On our PC version, the basic version of the app is free, and users upgrade to the paid version to get more features. But rather than "purchase" the app, they effectively "subscribe" - in other words, their upgrade is valid for a specific period of time, during which the extra features are available. They also get free updates and support during that time.
The mechanism for this is that they buy the upgrade and get a license key which they enter into the application. Every time they open the application, it pings our server to check whether the key is still valid. If it isn't, only the basic features of the application are available to them. Obviously they have to be online when they open the application, otherwise they can't ping the server.
The question is how we transfer this model to Android.
We want to make the app available in Google Play, so it has to conform to their rules, which I understand means users can download a basic version for free, and any subsequent purchase has to be done via Google Play, which is fine with me in principle. Rather than have a free app and a paid one, we'd prefer to have just one.
So my favoured option so far is to offer one app with the premium features locked until the user upgrades via an inapp purchase. My questions are:
1 - can the in-app upgrade contain a time limit?
2 - if the user has upgraded, is it technically possible for us to force the app to regularly ping our server in order to keep the extra features activated?
We offer refunds on demand for the software, because it's complicated to use, so if we do refund someone, I'd like to be able to deactivate their key on our server.
Grateful for any thoughts you have!
1) There are "consumable goods" and subscriptions
2) An android app can contact your server via e.g. http. But I'd prefer to do everything via google play, if possible.
3) Note that Google takes a percentage of the in-app purchase cost, so if you refund... will the Google also refund? See Android In-App billing cancel payment
Note also the limit of IIRC 20 goods per request in the API, the example code has a bug related to that limit.
I'm looking for some advice on an app that I am hiring a developer to work on for me - its my first app and his first solo app, so I at least am still getting a feel for the ropes a bit.
My question lies in the area of in-app purchases. My app will use an in-app purchase system that will be used to purchase "credits" for lack of a better word. Each time a credit is purchased it will enable data stored in the app to be emailed to a particular email address.
I had originally thought it would be good to have an external web-based shopping cart to deal with it, but I understand there are APIs available to embed these shopping cart systems into the app. Additionally I also understand that any "digital consumables" that unlock features of the app are subject to the commission that iTunes/Android charge, does anyone have any initial thoughts on whether the ability to email would be included in this?
Many thanks in advance.
Savvas, that's not true at all ... AFAIK , in Android there's some exceptions you can read here: http://play.google.com/intl/en/about/developer-content-policy.html
Paid and Free Applications
App purchases: Developers charging for applications and downloads from Google Play must do so by using Google Play's payment system.
In-app purchases: Developers offering additional content, services or functionality within an application downloaded from Google Play must use Google Play's payment system as the method of payment, except:
where payment is primarily for physical goods or services (e.g. buying movie tickets; e.g. buying a publication where the price also includes a hard copy subscription);
or 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)
So for example, for buying a coffee, you can use your own payment gateway.
I am pretty sure that both iPhone and Android agreements require you to use their own payment services for all in app purchases.
That means you can't roll your own paypal/visa/any other payment system and have your users use that if you plan on distributing the app via the Google Play Store or the App Store.
That being said, you can still roll out your own payment system if you distribute your app via other channels (for android you can have a look at the Amazon app store and other solutions. For the iPhone there is no official third party app store since Apple prohibits it. Cydia is an alternative app store that many people have though in their jailbroken phones)
Personally I am a big fan of Urban Airship. Works great on iOS and Android.
How are purchases of physical products handled in android? Are there any limitants and/or considerations? As I read in this article:
http://developer.android.com/guide/market/billing/index.html
Android developers are only considering digital products not physical. Nevertheless,I just found an office depot app which let us choose physical products from their store, add them to a shopping car and check them out. Furthermore, when cheking out we also have the chance to add a payment account i.e. credit card, meaning we must use security either for storing credit card data or to send it. When working with In-App, they say that the end-user makes his purchases by using its linked android market account (as well as the developer ..and a merchandise account also) but in the other case with office depot, I guess the developer must build the entire billing platform, doesn't he?
You can use in-app billing to sell only digital content. You cannot
use in-app billing to sell physical goods, personal services, or
anything that requires physical delivery.
Source
Thats for googles in app-billing. You may use other payment methods (self-built or external such as paypal). But these are not allowed in the android market afaik. So you have to distribute your app yourself too, or use alternative markets.
Edit:
Oh found something:
Developers charging for applications and
downloads from Android Market must do so by using an authorized
Payment Processor. Developers offering additional content, goods, or
services for an application downloaded from Android Market must offer
an authorized Payment Processor as the payment option.
The following are exceptions for the two requirements above:
Where payment is primarily for a physical good or service (e.g. buying
movie tickets; e.g. buying a newspaper app where the price also
includes a hard copy subscription)
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)
Source
So i was wrong. It seems to be allowed to use other payment providers if you are distributing physical goods.