Does there any existing good API for virtual Coins purchase in mobile application? Actually, I would like to make a cross platform application. I have researched on facebook, there is a facebook API for purchase. But it only for facebook application/games.
Generally, each app store/market wants you to use them to handle payments, so that they can take a cut (usually 30%) of your profits. Using third party payment providers is generally forbidden by the terms of use, etc. Thus, it is unlikely that you will find a cross-platform solution. PayPal should work on most platforms, but you have to make sure it's not against the terms of use. For Android, you can use unmanaged items with in-app billing, there should be something similar for the iPhone. You could probably manage your coins on your own server, and have them purchased on each platform with the required payment provider, but it's quite a lot of work.
Related
I'm developing a pay for win Android app, in which users are, among others, ranked according to the amount they have spent. The payments are Android in-app purchases.
My questions are:
Is an authentication system required for my users, in order to purchase and be ranked? In other words: instead of using an authentication system, could I use the UUID of the phone, or its MAC address, or any other piece of information that would actually act as an authentication system? If yes: why isn't there any other Android app that proceed in this way (indeed, they use Facebook/Google authentication, or e-mail + password authentication, etc.)?
Is there any Java ranking library that I could use and bind it to the Android in-app purchases? In particular: does Google offer such an API?
Is it a good idea to use Google's authentication and ranking based on Google Play? The ranking criteria must also be the total spent amounts.
Authentication and authorization
Firstly, I would like to make the distinction between authentication and authorization.
Authentication is a way to determine a user apart from other users. Authentication allows a developer to identify Jane Doe as a separate entity from all other users. Authentication is often a precursor to authorization.
Authorization pertains to what actions a user can take on particular resources. Authorization deals with the what, when, how as opposed to the authentication that deals with who.
To state your questions using more definitive language you are asking for best practices relating to:
Authenticating a user inside an application that is available on the Google Play Store, and
Calculating totals related to Android's In-App purchasing, and
Authorizating a user to take a claim action on a prize entity depending on the aforementioned total aggregate
Recommendations
I would highly suggest you use Google's OAuth 2.0 service to authenticate users as opposed to building your own authentication framework or implementing any other authentication framework, especially if this application is only used within th Android ecosystem. I recommend this because:
Android users already have a Google account, and
Implementing your own authentication framework requires very niche skills which usually require a team of people, and
Google already offers an Subscription and In-App Purchasing API which can be queried to rank you users, and
You will already have implemented this API to support in app purchasing to begin with
I would highly suggest you do not use MAC address or UUID authentication because
On a rooted phone I can change my MAC address, and
It does not uniquely identify a user across multiple devices, and
Using this type of authentication would not provide any benefit to your second goal of authorizing actions based on a total aggregate
In other words by using Google's authentication mechanism you can not only uniquely identify users across multiple devices, but you can also leverage the in app payment system to build your particular authorization logic.
The In-App Purchasing API already contains the necessary information you want since you will need to implement it to support in app purchasing to begin with. You might as well use it as a basis for ranking since it is readily available, secure, and contains the information you need with well documented ways of accessing it.
Additionally, you may want to look at the promotional capabilities and one time product-specific billing features functions and related APIs. This might fit your use case and it may make your application more secure and standardized.
Using the provided authentication framework and in app purchasing capabilities standardizes your application up until you implement the claim your prize functionality. People enjoy standardization because they become familiarized with it, and it provided a level of trust, so I would definitely investigate the other aforementioned APIs to see if your prize idea can be based off a foundation provided by Android. This would standardize your app all the way through and, in my opinion, would be best practice.
Summary
I would provide some sample code but your questions are still a but high level to provide anything useful in the way of code snippets. To summarize though my recommendations are as follows
Leverage the Google OAuth 2.0 framework for authentication, and
Leverage the In-App purchasing API and related APIs as a way to calculate total and rank users, and
Investigate the promotional capabilities, or one time product-specific features already provided by Google to see if it fits your use case, and
Avoid using MAC addresses and UUIDs for authentication for the reasons I outlined above
Edit ....
After rereading your title I realized I glossed over the fact that, as I understand it, the term ranking and it's related functionality as used by Android is mostly centered around where you application sits, popularity wise, in comparison to other applications. I have not seen the term used by Android to refer to internal ranking of users against some developer-defined criteria ( total, in your case ).
I'm not saying it does not exist, just that every time I see ranking it refers to application popularity. Therefore I would refrain from using that as a query term when researching how to build this application as you will likely get a plethora of false positives.
What I think you want, to reiterate, is
Authentication
Calculating in app purchasing totals
Promotional or one time features based on that total
Those terms will suite you much better. Please feel free to start a new post when you get further in to the project if you need assistance consuming the APIs
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 need to check, using APPLE ID/GOOGLE Android ID, if the user really has paid to buy my app.
I have to avoid an user use a cracked app (jailbreak)
Is there a "public key" unique for each app? I can use that (if exist) to check the unifier of my app
In short: No. You do not have access to this information via the API, but as others have said, you can roll your own solution via in-app purchases and your own server. If your concern is that unlicensed users will consume server bandwidth or other expensive resources, I'd suggest doing this.
If your end goal is just to prevent piracy, though, I'd suggest googling some of the off-the-shelf anti-piracy solutions available today. Even then, however, I would not expect miracles. I have implemented as many anti-piracy techniques as I can develop within a few of my own clients' apps, but to date, none of them remain "uncracked."
You could do something creative involving in-app-purchase and pinging your own server when the purchase is completed. This assumes you want to put content behind the IAP paywall and that you want to run your own server which perhaps isn't the case.
On Android, use the license verification library.
You could make it available for free on the AppStore, and then use a licensing or in-app purchases to deliver more content (full-content) to the users !
If I have an iPhone app, Android app, and Blackberry app, is there any way to implement a monthly or yearly subscription-based billing scheme such that a user need only pay for one subscription in order to use my app on any device? The problem is that each app store seems to have the stipulation that any fees required to use the app must be paid through them so they can take their cut.
Dropbox does this, but I think they can get away with it because their apps will work for free, and the subcription only offers more storage space. Is their any way to do this type of billing for an app which requires a subscription in order to be used at all? If not, will simply adding some sort of free functionality get me around this?
Thanks.
[EDIT]
Let me be clear, my question is about how this can be done legally. I'm basically running up into the same issue that caused the Financial Times to stop offering its paper through a native iPhone app. The difference between them and me, though, is that I don't mind paying the app markets their cut. I just want to know if this is possible; a user can either order their subscription through Android Market or the App Store, and if a user isn't paying through both stores then I think I'm violating the terms of one of the stores.
You could try Bango.But you need to implement a possibility to transfer the Bango User IDs between your different apps on the different devices. They offer a service where they bill a recurring fee to the user. They offer a SOAP-Based API (amongst others) you can use from your app.
But beware: there are some legal restrictions concerning inapp payment in the Apple AppStore and the Android Market and maybe also in the Blackberry AppWorld.
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.