I'm about to implement In App Purchases (IAP) for a premium-upgrade feature in an app I'm developing, and I've read the official developer guides. There, they mention that
You can use the Play Billing Library to simplify your development
process, allowing you to focus your effort on implementing logic
specific to your app, such as displaying in-app products and
purchasing items.
and refer to the TrivialDrive_v2 sample app for a complete training class on how to implement in-app-billing.
Looking at the sample, and specifically the com.example.billingmodule.billing package, the phrase "simplify your development process" isn't exactly the first thing that comes to mind.
Is this really how we are supposed to implement in-app-purchases for premium upgrades? Seems way more complex than it should be, so I'm thinking maybe I've misunderstood something along the way, and that there is a much easier way to achieve this very common feature?
Related
Up until now we were using the in app purchaces api using the IabHelper classes that Google was giving in the form of raw code so that we could "rewrite" it and make it difficult for a hacker to reverse engineer it, trace the code and remove it and then upload the app in the black market with everything for free.
Now Google has released the Billing Library with very easy to trace methods and callbacks. Right away I'm wondering what that means for the safety of our apps because I think it's not that good. Can someone explain what Google is thinking with this and how we can still ensure that the app will not be easy to hack?
ΝΟΤΕ
I'm aware that it's impossible to make an app hackproof. We can just make it more difficult to hack so that the average person can't do it. My question is about whether using the BillingApi from a library makes it easier to hack than the previous approach.
You can't be sure what your app isn't hacked. It's only a matter of time.
I suppose all time that my app is hacked and I don't allow do any purchases if root was found.
I suggest you see the Google SafetyNet helper docs.
Good link from Dima!
The library mostly does integration with Play billing. There should be an additional logic in your app to protect it against hackers.
I also recommend checking Security Best Practices from Google Play billing team.
I was wandering if I can sell digital objects(like lives in Candy Crush) from an other app.
I'll explain it a little better: I have an android game built with AppInventor from which I can't implement in-app billing. I was thinking to build an app in java and allowing in-app purchase from it an sharing purchases info on the server on which the game is based.
The question is: does Google allow me to do this or there is some restriction I've not been able to find?
I hope you can understand what I wrote as english is not my mothertongue.
Isn't there a way you can just reimplement your game with in app billing? Having to open another app to buy things on this one seems not really intuitive. Plus, you may need to advertise the "buying app" in the "game app" somehow, so you'll still need to write some code.
As far as I remember, AppInventor apps were fairly straightforward to redo if you know how to code Android, plus it's not available anymore, which means you lost support in case you want to do something else.
I know that for jailbreak iOS device there is a way to get in-app purchase for free. There is in-app hack too for android. Is there anyway to prevent this when writing app that use in-app purchase ?
thanks
Yes, in addition to following all the latest Google Play/Apple licensing and security best practices you can, you need to make multiplayer interaction through your servers an intricate part of the game play and the fun.
For great examples of this, take a look at "Fun Run" or "Clash of Titans".
That being said, don't make the mistake of doing this after you've designed most of your game already. Most users (even and especially legitimate paid users) hate it when their game requires them to be online even when they're only playing it in a single player mode, and they will badmouth and down-rate your app if they suspect that you've purposefully crippled your game, or removed single player mode functionality after the fact.
I would just like to ask if there are any best practices for a shared subscription billing for iOS and Android.
Right now, we are developing a mobile app both on Android and iOS (both native sdk, not cross-platform). And we have this certain feature in the app which you need to subscribe in order to access. But this will be a shared subscription. A one time payment regardless of what device a user is using to subscribe.
Sorry, but I am not really good in explaining things so maybe I will give you a scenario. I hope it helps you to understand what I am talking about.
For example, a user has two phones, an Android phone and an iPhone. He then installed our app in both his iPhone and Android phone. Now, he opens our app in his iPhone and he wants to access that certain feature so he subscribed. With this, what we want as a developer is to make it so that when he opens the app in his android phone, he will already be able to access that certain feature since he has already subscribed when he used the iPhone app.
We are still hesitant to continue since Google and Apple have different billing schemes. But maybe there are solutions for this, or are there?
I am hoping that someone could give us light on how to do this in the best practical way possible.
Thanks in advance...
I am currently facing the same issues. That's what I have so far.
There seem to be cross-platform solutions but none of them seem to work through Google Play or Apple payment methods..
You can use your API/backend service to flag the current user subscription state and sync it across all your platforms (that might violate Apple in-app system conditions).
I'm currently looking for a way to communicate to both Google Play and Apple in-app payment system that the item has been already bought in a different platform. There should be a way but as said, still looking for it.
We'll keep that up to date.
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 :)