Chris, I see some potential problems with that approach. I think you need to think out the process and make sure you have accounted for all the details.
For instance, you can't charge a different amount for an app based on what the user wants - can't charge twice as much for two characters. You can't buy the same app multiple times. A few points to think about: Where does the data/logic lie... in the main app or in the add on app? How would a user specify what character they chose? How would the process differ for 1 character or 3 characters? What if the user first buys one, but then decides he wants to buy two more after the initial purchase? What if the user uninstalls the app within the free trial period? All these nagging little questions can trip up the process. Please let us know if you come up with good solutions to them. On Mar 25, 12:20 pm, chris harper <[email protected]> wrote: > Frank > > Yes it was me that had the "payment" web page into your app but I am about > 90% sure I am going to change to somehow use Market place. > For the main reason that I don't think I will get near as many people buying > my characters for my app if they have to enter their payment info into my > app at my website. > > I think I need to find a way to make my characters available via market > place so I can use the market place payment. Like I said I am trying to > design an "install app" to work with my main app. > > Maybe they buy the install app, download it and the install app knows how to > download and install my characters from my site based on what the user > picked within the main app? > > There has to be a way to do this. > > I am good at digging until I find it. > > -Chris > > On Thu, Mar 25, 2010 at 10:59 AM, Kevin Duffey <[email protected]> wrote: > > 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]<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.
