[casual_games] Different Payment Models

Sun Oct 8 17:20:46 EDT 2006

Hi Jeff. Great question regarding security.

First. Let’s look at the security of the platform itself. If we look at .NET web services then it wouldn’t be all that hard to implement a single interface with integrated soap header security where the services themselves would run on an SSL site (https). The way to interface and interact with the services could be well defined and implementation examples would be available. This all becomes a question of integration, then. When a game, supporting the “Casual Games Pay4Play” platform (neat name, huh J) integrates the services it needs to log the user onto the platform using his/her platform credentials. The logon would be made directly to the services that would register a session for that particular game. The answer from the platform would indicate whether the user would be able to play or not. If the game would also want to support direct payment (own the game without paying for each time you play) then that is simply a matter of implementation for the developer – disabling the call to the platform.

Now, this scheme wouldn’t exclude shady businesses from saving player credentials and, later, abusing them. That would mean another layer of security. I imagine that each game or developer would have to submit to some agreement and have to take on some responsibility for being able to submit a proof of purchase. A rating system could also be activated where games and developers would be submitted to some sort of an integrity rating by users.

A really “heavy” model would incorporate an approval step by the user. Then no transaction would take place without an email being sent by the platform to the user and the user would have to agree to the purchase. This would increase complexity and slow down the ability to play directly and, thus, it would force the model to support credit purchase – the user is able to allocate or buy more than one “go” at a time.

But, at the center, I think the platform could be pre-paid. The user clears a platform transaction of a specific amount which he can then relocate to games played. The user should always be able to get a complete overview of his transactions and expenses.

Anyway. This is really painting a rough picture. As I said. I’ve thought about this for a while and I’m pretty sure it would be doable. Before I turned to the game industry I spent most of my time designing distributed high-security systems for banks and financial institutions that needed to exchange information with each other and a central data store in a safe and secure way. A design of some sort of a pay4play platform would incorporate many of the same issues I’ve had to deal with in the past regarding banking and financial system integration. I’m still called on to assist with implementation and design of a pretty big central system that interconnects with a lot of financial institutions (Dealing with high-risk data) so I’m still pretty well up to date regarding these systems.

But I think the core issue would be getting big players involved in an effort like this. It would have to be well supported and executed (almost) flawlessly. The technology and design would have to be iterated on, quite a bit, and the whole thing would have to be pretty well thought out.

I’m also pretty sure that a basis for a platform like this (closed central platform as opposed to the open platform of paypal) can be found out there. I know that State lottery sites have dealt with platform vendors that specialize in monetary transactions that are integrated into various games made available by the lotteries so we could probably find a very similar model there.

Regards,

J#

From: casual_games-bounces at igda.org [mailto:casual_games-bounces at igda.org] On Behalf Of Jeff Murray
Sent: 8. október 2006 20:37
To: IGDA Casual Games SIG Mailing List
Subject: RE: [casual_games] Different Payment Models

Chris, that is sooo right it's untrue. The kind of models that support micropayments are also the models that mean a significantly higher development cost. Couple that with the 'hit and miss' nature and it's just as much as a gamble as putting money on the horses.

Casual games are so throwaway in nature that micropayments just don't make much sense. Take it further, into independent development of games and you're looking at a huge 'build it and hope' factor unless you have an already established idea which you're building on. The problem with starting small and building up is that users quickly get bored of the lack of crap you can give them. It has to be an almost constant flow of crap to keep them interested, or at least a significant enough amount of crap from the getgo to get them to go part with cash!

Jonas, the whole 'casual games paypal' idea seems interesting ... if you can provide developers with some APIs to get started with and reduce the dev time significantly (by clever item purchase / unlock design) you may well be on to something there... the biggest problem every customer of that service would face would be security, though. How can we be sure that payment has actually gone through correctly when we're dealing with 500+ different games with code of varying integrity? The authors would have to retain responsibility for their own security and my spider senses detect a legal minefield!!

Anyhoo ... after Chris' email I felt inspired to throw my two cents out there!! :)

Jeff Murray.

Jeff Murray | Game Programmer

FUEL INDUSTRIES
tel: 613.224.6738 x246

www.fuelindustries.com <http://www.fuelindustries.com/> 

www.fuelgames.com <http://www.fuelgames.com/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://seven.pairlist.net/pipermail/casual_games/attachments/20061008/5e0f93bb/attachment.htm