Like Chris said, the main thing is the user experience. We all know a user after 3 seconds of waiting for a page to show up, often goes somewhere else. Most people are impatient. Having them fill in all that info they've already filled out for their google checkout or paypal account, in a game or other app, in my opinion is asking for too much. You don't want to have a game or app require personal info to be entered. It's just not going to go over well. I honestly don't trust any app out there that asks for my info and uninstall it. There is just WAY too much identity theft, stolen cards being charged, etc. Most users, I am pretty sure will think along these lines.
What we need is some sort of Paypal, google checkout or other known vendor (not sure how many others are out there) that people are familiar with, and are asked for basically a pin or login or something that allows them to pay for something without the game/app knowing any of that info. There should be no way for any game/app to "store" their info they enter to access the account. Games like World of Warcraft, or Xbox 360 where you enter your info already when you sign up for something like xbox live, or in WOW you sign up to get charged monthly/quarterly.. they have that info already and to play a mega game like wow, you must do this, or to access xbox live, you must do this. Because that info is already there, in-game purchases, like upgrading xbox live, buying xbox "money" to buy expansion packs to games, etc.. is all done very easily. To me, there are really only two "good" ways to do this. One is google provides every android device an SDK they can use to do in-app charging, that ties to their google account. To use it, a user of an android device would do a one time setup of google checkout. Once done, the android device can "log in" automatically and allow one click charging/approval in any app on the device that uses the SDK. However, I don't see this being something very viable anytime soon. The other way that makes "the most sense" to me and is available sort of right now, is using a service like ScoreLoop, OpenFeint, etc, that provide a user profile setup..where the user can fill in info including credit card/pay pal info at the service site when setting up their profile. Once set up, any game/app using that service allows the user to "log in" to their profile. It adds the advantage of storing high scores, achievements, levels, etc and you gain the social aspect of things like being able to publish your new high score on some game you play to twitter/facebook, and possibly draw in other players, etc. The main benefit tho is that the end user signs up just once and any game/app using the service is able to allow for micro transactions like in-game purchases with one-click approvals. Short of those, I don't see any good alternative that will make end users of games feel comfortable. I forget Chris if it was you that embedded a "payment" web page into your app... but I don't know how else you'll get people to fill in private info like that to buy stuff in game. If the game is really good, I can see some players willing to go to a web site, buy stuff, then "reload" the game. When they buy stuff on the site, it updates some game DB that they now own an item, and then when they reload the game, it hits the server and downloads any purchases they made, so that its on the device. That still requires them to go to a website out of the game (or app) to do this, but its a much more common/secure way that more users would be familiar with. I was saying earlier, being able to call the API/SDK of a checkout program in-game would be nice because you don't take the user out of your game. But the more I think about it, the more I feel most users would not feel safe doing stuff in-game that allows the game to have any of their personal info. There will be some, for sure. But I just don't think that will go over well. That is why this profile/service thing looks promising. Sign up with openFeint, fill in the info once, the game can use the SDK to allow in-game purchases. On Thu, Mar 25, 2010 at 8:50 AM, chris harper <[email protected]> wrote: > Shane > > Kevin and I have been heavily involved in this because we both require > in-app billing for "virtual items" within our apps. > > Actually this morning (as Kevin knows) I am trying to decide which way to > go. > > I can either have my app access my website, require my users to enter > account information on my site and then download my virtual content from my > website within my app (which it will install it for them). > > Or I can find a way to make my virtual content available though Market > place and have my virtual content available via apk downloads. For me (and > Kevin probably agrees) the biggest advantage of using Market place is that > users are fimular with it and if they don't have to re-enter their account > information a second time from a source they don't know much about (i.e my > site) and instead use market place so all they have to do is hit "ok to > confirm" that will make a HUGE difference in the amount of users that will > pay for virtual content because its a two second click VS re-entering all > their account info again from an unknown source. > > As a developer of an app that is a HUGE incentive for me to use Market > place and worth the extra time for me to think of a way to make it work. > > I am just trying to design a way to make the virtual content available so > they don' t end up with dosens of apk files downloaded (one for each virtual > content they purchase). I am currently thinking of an "install" apk app > (different than my main app to make it small and lean for downloads) that > can maybe get "updates" depending on which virtual content is purchased. > Then that app talks to my main app to install my virtual content that my > main app uses. > > I am currently researching what is involved when you do an "update" to a > current apk. > > That's where I currently am right now. > > -Chris > > > > On Thu, Mar 25, 2010 at 9:02 AM, Shane Isbell <[email protected]>wrote: > >> I thought I'd briefly jump in on this discussion. I'm looking into >> providing a virtual currency/in-app billing solution for ZappMarket. >> ZappMarket is focused on paid app developers. >> >> I'd like to talk with developers (either on-list or you can send me an >> e-mail) about what your specific needs are for virtual currency and in-app >> billing. Largely at a technical level in terms of APIs you would find useful >> and whether you are looking for a basic set of interactions like >> check_balance, pay or for something more sophisticated that would also >> manage codes and virtual goods themselves. >> >> Based on your feedback, I can put up a trial solution that we can test and >> then go from there. >> >> Thanks, >> Shane Isbell (Founder of ZappMarket) >> http://twitter.com/sisbell >> http://twitter.com/zappstore >> http://zappmarket.com >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected]<android-developers%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> >> To unsubscribe from this group, send email to android-developers+ >> unsubscribegooglegroups.com or reply to this email with the words "REMOVE >> ME" as the subject. >> > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > > To unsubscribe from this group, send email to android-developers+ > unsubscribegooglegroups.com or reply to this email with the words "REMOVE > ME" as the subject. > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
