Value of In-Game Purchase

[Phil Steinmeyer]

I saw this pop-up a bit as a secondary topic in a couple of other threads, and wanted to break it out.

As I understand it, E-Sellerate has an SDK allowing a developer to add an in-game purchase option. Apparently, few if any of the other order-processors have this (which ones?)

What do you think of this?

As a user, I'm not sure I've ever seen this implemented in the games I've bought , but I may have overlooked - usually I go back to the portal/dev site to buy. Which game has a well-done in-game purchase that I can look at for reference?

For the public as a whole, is this a selling advantage? Are others like me and feel more comfortable buying from an on-line store, rather than in a game. The former feels more familiar and professional for entering a CC # to me, but I may just be an aberration.

[FlySim]

We use eSellerate's in-game purchase system and it has worked great since they fixed the dupicate order problem. We get about 5 to 1 using the in-game purchase method versus the web store. For $20/month you can get phone order support - I don't think many customers use this, but I think having a phone number makes the order process more credible.

[Codemattic]

Apparently, few if any of the other order-processors have this (which ones?)

Kagi does

http://www.kagi.com/about/bulletins/krm.html

I think Plimus does too

http://www.plimus.com/plimus/jsp/solutions_shareware.jsp

the "Buy button - Allow your users to activate the product and buy licenses directly from the tool" sounds like it

[James C. Smith]

Reflexive also does this. Any game distributed in the Reflexive Arcade can chose from 3 different levels of order form integration. Ricochet Xtreme is a good example of a game using tight integration with the order form in the game. It stays full screen and has no pop-ups. Big Kahuna Reef is slightly less integrated. There is a Buy button in the main menu of the game but it pops up a separate Window. Most game just rely on the wrapper to show the order form. It is not in the game window, but it does pop-up while the game is in play and you can continue playing the game if you make the purchase when the demo time runs out.

But none of this is really a "DRM" solution available to developers. It is only available as part of the Reflexive distribution network. So it is not an option to compete with E-Sellerate, but it is an interesting example of one way to implement the technology.

[Jim Buck]

I think Insaniquarium does this. As I seem to recall, I was playing the game, it paused, asked if I wanted to buy (of course I said "yes!" :) ), I did the buying all in the game ui, and then I went back to my game already in progress. It was amazing, and I'm surprised more games don't do this - I think it would garner a truckload of impulse buys.

[princec]

I did it too and I noticed a slight increase in registrations but at the expense of some complexity that I decided I didn't want to deal with.

I now have the equally-effective measure of ALWAYS opening the user's browser on the Buy page when they quit :)

Cas :)

[Phil Steinmeyer]

Am I correct in assuming that Software Passport/Armadillo does NOT support in-game registration/buying?

[ErikH2000]

Am I correct in assuming that Software Passport/Armadillo does NOT support in-game registration/buying?
That's right. The closest thing you have is a "CallBuyNowURL" library function that your game can call to launch a browser. And I can't think of any simple way to automate collecting the key and unlocking the game in response to a completed order. (I can think of complex ways, but I won't try to impress you with how clever I can be. ;) )

-Erik

[soniCron]

I don't understand the difficulty of including simple HTTP handling and doing the order however you see fit through the game, all the while parsing the HTML response pages. I assume SSL would be the most difficult factor to implement, and if there are any patent issues, the point would be moot. But I've seen (or at least I thought I saw) open SSL libraries available. I don't have any experience with this process, however, so I could be totally off the mark, but it would be nice if someone could dismiss this idea with some background.

[ErikH2000]

I don't understand the difficulty of including simple HTTP handling and doing the order however you see fit through the game, all the while parsing the HTML response pages.
It's maybe not that hard, but you are betting that the payment processor will keep their interface the same. If they change the form fields you have to submit, then you could have thousands of broken demos out there that can't be updated to the new payment processor interface. To deal with that you could write your own consistent interface PHP that passes through to the payment processor, and change it when needed, but the project is starting to get not-simple at this point.

And then you got to make sure the payment processor is cool with you putting in orders this way. Sometimes you read in contracts that you're not supposed to do this kind of thing. Probably they won't care if you write everything perfect and don't generate a bunch of faulty orders that cause customer complaints and order reversals. I imagine that if you asked ahead of time if it was okay, most processors would say "no" just to save themselves trouble.
I assume SSL would be the most difficult factor to implement, and if there are any patent issues, the point would be moot. But I've seen (or at least I thought I saw) open SSL libraries available. I don't have any experience with this process, however, so I could be totally off the mark, but it would be nice if someone could dismiss this idea with some background.
Yeah, that part is easy. libcurl will do SSL and everything else you need.

-Erik

[princec]

I did get it all working fine in Java but the real hassle is maintaining the GUI code for the ingame purchase. You know, dropdowns for country lists, etc. and the fact that at the time, only swreg actually had an easy direct interface into their ecommerce system.

Cas :)

[cliffski]

I don't understand the difficulty of including simple HTTP handling and doing the order however you see fit through the game, all the while parsing the HTML response pages. I assume SSL would be the most difficult factor to implement, and if there are any patent issues, the point would be moot. But I've seen (or at least I thought I saw) open SSL libraries available. I don't have any experience with this process, however, so I could be totally off the mark, but it would be nice if someone could dismiss this idea with some background.

have you DONE it?
Believe me, there is no much stuff to do to take a small game to market, the last thing on your list will be parsing html gubbins to handle the order process.
I think in some cases people would prefer to buy 'out' of the game. at least then they can keep on top of virus and spyware warnings during the order process. Your app could be doing anything it wanted if I ok it to connect to the web (in the eyes of some users).

[soniCron]

have you DONE it?
Believe me, there is no much stuff to do to take a small game to market, the last thing on your list will be parsing html gubbins to handle the order process. If it means more impulse buys and a higher overall CR, it would be the first thing on my list. Not to mention that written well once, it can be used in any future projects. I don't think I'm out of my element asking if it's been done or highly difficult.

[Robert Cummings]

I think a Get Full version link inside the game is just as effective. It just takes you to the checkout, where is the problem in that?

I personally don't actually trust In-game purchasing. Crazy huh? I simply refuse to buy outright.

[princec]

Bob C. is a rare one and no doubt, but he's dead right when he says that just taking people to a buy page as often as possible has the same effect. It's also so, so, so, much easier to do.

Cas :)

[Black Hydra]

This seems like a question that is similar to the .99 or .95 price question.

I think the only way you will find out what works best is through testing.

Couldn't you have both in-game and webstore purchasing on your game. Like when it pops up with the order form in the game it will have another button that says "Go to Web Store".

I understand Roberts concerns. Order forms inbedded in a game feel less secure to me, I know that is probably an incorrect thought, but a game is a complex (and often unknown) program and it seems less trustworthy to give your information to it than a reputable 3rd party device like a browser. Something makes the transaction feel more legitimate.

That said I think that having an ingame purchase option would definitely be a plus for all those people that don't have the same opinion about it that I do.

And the fact is, there is a lot of things that can increase sales, but the cost is paid in your time. If the net cost in time for providing in-game purchasing is more efficient than the net cost of so many other options for increasing sales, go for it. But if testing has proved its effects to be incredibly minor you might want to spend your time with other methods that have a higher benefit to sales (time spent on SEO is supposedly one of the most fruitful ways to spend time increasing sales)

[Fost]

We were considering implementing this a while back - although funnily enough, not because we thought it would increase sales, but because we liked the idea of auto-unlocking the game during purchase and making it all seamless for the customer.

We decided to wait a while though, because we knew verified by visa/ mastercard secure was being slowly phased in. Does this now work with in game purchasing? Since it has to pop up/iframe a new window?

[Pyabo]

I would think many people would not bother working on this option, simply because their game will be pushed through portals... What portals support this?

[Musenik]

I've been using the Kagi, in-game purchase system, exclusively for both Mac and PC for sales from my own site. The CR from my site is slightly greater than the online publisher selling the game with an unlock code system.

I'm not going to suggest that one is better than the other, but I don't think any of my direct customers have been put off by the in-game system.

Personally, the less I have to hassle with, the better. Trusting a casual computer user with typing in an unlock code sounds like the sign over the entrance to hell.

[arcadetown]

There's existing solutions probably better to use, Reflexive or TryMedia for example. Not convinced by claims of increased upsell but a little test will determine if for real. Might try TryMedia's wrapper on a test product to see what it produces. I'd use Reflexive's but they don't provide alternate online purchase mechanism like TryMedia does. My problem is both systems don't provide all the features BMT does like affiliates, vendor splits, etc.

[cybermonk]

I've also been using Kagi's KRM, and it's used by over 50% of my customers. Implementing it was easy, and it makes the whole registration process easier and faster for the user.