I want to know if its possible/legal(not against terms of service) to use the google checkout api for an android app to support in app purchases. The types of items being purchased would be something like extra coins where they can be purchased multiple times.
I know that this would require getting the user's credentials or pointing them to the checkout page or something. I want to know if its possible to do this within the app by opening a webview to the checkout process, and then getting a callback to a custom url on my server that will allow the app to see that the purchase was successful. Something like what the android market does for app purchases.
Thanks for any responses. I don't currently have code to show as I am researching into this before devoting time to create something I won't be able to use. Also maybe android will support native in-app purchases in newer versions of the sdk.
Spoke to (Android evangelist) Reto Meier at Google Tech Days about this and he said it is perfectly OK to do inter-app purchases in the market. You should comply to other regulations - most common is that you need to only buy content that is consumed on the mobile. Virtual "coins" are on quite thin ice, some countries ban issuing "virtual money" but you can do essentially the same with just little different paradigm. Hope this helps.
Android market documentation explicitly states that you can do check it.
http://developer.android.com/guide/market/billing/billing_admin.html#billing-refunds
Important: You cannot use the Google Checkout API to issue refunds or
cancel in-app billing transactions. You must do this manually through
your Google Checkout merchant account. However, you can use the Google
Checkout API to retrieve order information.
Related
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.
I'm currently very much confused about with which subscription service to use between any Third-party or Google's In-App billing system.
Let me explain first , I have an app which is providing service to Landlord for Posting their vacant Properties where we are providing free trial 60 Days for full app features & after trial expires I would like to add Subscription Plans as below:
Silver: Less than 50 units (monthly or yearly)
Gold: Less than 51 - 100 units (monthly or yearly)
Platinum 100 and up units (monthly or yearly)
Now I'm exploring options to include to implement this subscription features & found that Stripe would be a good option for me but soon I find out about in-app purchases guidelines where they mentioned that In-app purchases must use Google Play’s payment system & also mentioned , examples of products not currently supported by Google Play In-app Billing:
So , basically there are two questions from my side :
Can I use other payment system or should I need to use Google's Play Billing system ?
For Google's Play system , How can I divide or how many subscriptions items will be there for above subscriptions plans?
Any help would be appreciated!
You can use both services Stripe and Google IAP(In App Purchases) or just 1 of them.
I suggest that you go with Google IAP since you do not have BE(BackEnd) and as I understand would be hard for you to maintain card numbers and everything.
Google IAP provides an SDK so that you can manage subscriptions on the Play Developers Console yourself. It also provides sandbox environment so that you can test it but also Stripe does that.
Here are some references:
https://developer.android.com/google/play/billing/billing_subscriptions
https://developer.android.com/google/play/billing/billing_overview.html
but I guess you have gone through them already. In the company that I previously worked on we were developing a project with pretty much the plans you described above and we used Google IAP and Apple IAP(for iOS/tvOS) without any problems. Furthermore we were able to query Google or Apple for previous subscriptions and let customers actually renew them instead of buying new ones.
As you mentioned the leasers/landlords will not be able to pay electronic bills with Google IAP but you can integrate Paypal/Stripe/BrainTree/WePay or any other alternatives for that.
Having mentioned that I would like to answer your questions now:
1) Yes you can use Stripe instead of Google IAP
2) You can divide subscriptions and you can manage them in your Google Developers Console at https://play.google.com/apps/publish/. However that can happen after you uploaded an .apk in console with in-app-billing dependencies and also permissions.
Hope it helps!!!
Your particular scenario is a bit of a grey area.
As a precedent the Autotrader app in the UK is using direct credit card billing in-app and this is a similar service to yours - i.e they are selling listings.
This seems correct to me because in app billing is designed to be used for digital content to be consumed in the app - not for real world services. Google may even reject your app for it.
In this case my advice would actually be to use Stripe or some other billing platform.
As for your billing model - it doesn't really fit the subscription model. I don't know specifically about Stripe but with Google you can't have a subscription AND a limit on items in the way you describe. So you would have to manage the listing limits yourself on your own backend.
There are some edge cases though - what happens if you use all of your 50 listings within the month? Do I have to buy another whole subscription?
The most suitable payment model I can see for you is Metered Billing from stripe - essentially pay as you go.
I recommended to use Google's In-App Billing. Because most of country payment support by google and user first trust on google that most benefit for you.
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
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?
I am using Ads in my App and also I am providing an option for users to upgrade via PayPal android api for Ad-Free app.
I could successfully integrate PayPal api for checkout in my app, but not getting how to tell to my app that this user has upgraded already/Now.
I want user to get ad-free app even after they re-installed the app.
Do I need to use my own server for tracking all upgrades or any other best practice is available.
Kindly help me out. Your reply is highly appreciated.
This will likely be against the TOS. As far as I know, you can only accept "donations" through other methods and not even that is clear. I have an app that accepted donations through paypal and afterwards I sent emails to those "donators" with an unlock code to remove the advertising. That didn't seem to break any terms of service, but I wouldn't write anything saying explicitly that the payment outside of google waller will give them an add free version.
"Google has been pressuring applications and mobile game developers to
use its costlier in-house payment service, Google Wallet for quite
some time. Now Google warned several developers in recent months that
if they continued to use other payment methods — such as PayPal, Zong
and Boku — their apps would be removed from Google Play. The move is
seen as a way to cut costs for Google by using their own system."
Source