InGame Purchasing

#1 Hey, those have not-unreasonable prices. Nice find.

#2 Thanks, I signed up as well. This could be interesting!

#3 The source code they give you is just plain, pure source. Very nice. This will be great for testing, and not having to maintain my own server. Maybe the push is a bit expensive at some volume, but the purchases are perfectly reasonable at 5 cents.

#4 At 35 cents per "price tier". don't forget that 30 cents go to apple

But yes, good find, will surely help some getting any in app purchase available at all.

#5 I wonder if they would handle In App purchases that were not part of an upgrade?

For example, In a multiplayer game they might be paying for a virtual service. Or, in a micro payment solution they might be paying for a soda or some chips at a vending machine.

Does anyone know who might handle the brokering of these types of payments?

Thanks,

Nick Powers

#6 This is for push notifications and ingame purchaseable downloads only. Ingame purchaseable upgrades do not require the special server setup apparently, only a lot less code. (I asked on their irc)

#7 @Nick: They're just middlemen for Apple, instead of you setting up the SSL+backend. Apple's rules apply (no physical goods). So the answer is: Nobody handles these types of payments in an AppStore app ;)

#8 Nick: you need to be carefull with micro payment systems. The rules are pretty strict which apply applies to the ingame store.

#9 Well,

That sounds like a service that is needed by the iPhone developer community then.

Since I am going to have to create it anyways, do you think anyone would be interested in using it as a service? If there is enough interest I might build it into a product to provide iPhone developers.

Thanks,

Nick Powers

#10 What exactly do you mean?

#11 What I mean is I could provide for inApp payments as a service for iPhone developers.

I run a virtual server provider (VSP). So, I have the credit card processing capabilities, etc. To provide for inApp payments I would just need to setup a server and sell accounts and give out code that could be incorporated into iPhone apps. Those apps then could accept inApp payments without the developer having to have a server or credit card processing capabilities, etc. In short, I could run a service that would be similar to PayPal but it would be used on iPhones applications.

Do you understand or am I just confusing you more?

Thanks,

Nick Powers

#12 Not 100% sure but I think you are confused yourself, as InApp payments are done through the AppStore and you have to comply to the InApp Store requirements, including only selling "final goods", you can't sell virtual money or stuff they can trade to get such.

An InApp backend solution has to provide other services:

1. It must keep the order in a storage be able to give users their ordered good after a device reset or on other devices of the same account.

2. You must offer the download to entitled users

#13 It looks like you may be both right and wrong at the same time. It appears developers cannot do what I stated above, using Apple's In App Purchase API. But, I'm not talking about using their API to do this.

If you read this: http://games.venturebeat.com/2009/03/17/virtual-goods-on-the-iphone-could-generate-big-revenues-for-game-firms/ it appears that one can use Apple for these inApp (in game) services, as long as they don't use it to sell any type of virtual currency.

In this article: http://games.venturebeat.com/2009/03/17/virtual-goods-on-the-iphone-could-generate-big-revenues-for-game-firms/ you can see that EA (Electronic Arts) sells a virtual stereo for 99 cents in their iPhone App that allows the player to listen to music from their iPod music library while in game.

From Section 3.3.17 of the new Apple iPhone 3.0 OS license agreement:

"You may not enable end users to purchase Currency of any kind through the In App Purchase API, including but not limited to any Currency for exchange, gifting, redemption, transfer, trading or use in purchasing or obtaining anything within or outside of Your Application. For the avoidance of doubt, nothing herein is intended to prohibit You from offering for sale goods or services (other than Currency) to be delivered outside of Your Application."

So, I couldn't sell virtual credits in my game that the user then could buy say virtual armor or weapons with but they could buy the virtual armor and weapons directly, using the In App Purchase API.

I still don't see anything that would forbid me from selling In App credits (virtual currency) to a player as long as I didn't use Apple's "In App Purchase API". Therefore, I could still run the service I described if there was a market it for it. I would just have to create my own API for developers to use.

A good example of this is that PayPal (aka eBay) has an application on the App Store that allows users to make or receive payments to and from anyone with a PayPal account. PayPal is used to purchase all kinds of virtual currency.

My game is a perfect example, I don't plan on charging anything for the App. Rather I'm going to make my income from people purchasing virtual goods within the game. People don't have to buy anything with RL money to play the game but those that want to can. I could name several web based games that generate millions in annual revenue using this model. Do you think any game will generate millions in annual revenue from just what they can sell the app for in the App Store? Like I said earlier even big players, like EA, are selling virtual items In App.

If you know of something I have missed that would keep me from developing my own API to allow iPhone developers, who integrate it into their apps, allowing their user base to purchase virtual In App items (even virtual currency), without using Apple's In App Purchase API, the then please let me know because I can't find it.

Thanks,

Nick Powers

#14 A lot of players don't like virtual credits, anyway. See the complaints about Microsoft's spacebucks system.

You'd have to check on the official iPhone forums whether your ideas would be allowed. Lots of active Apple representatives sometimes butt in with useful bits of information.

#15 I doubt that you have the multi million weight to offer apple a contract interesting enough that they let your app getting on their system and sell stuff without paying apple their 30% share, given Apple would even be interested in such special contracts

Also, I was under the impression that EA actually uses the InApp Purchase API for Sims3 as do the other business giants, as Apple used EA and Sims 3 for actively promoting the possibilities of this new API


Your comparision with Paypal is totally unrelated and completely wrong.
Its not money for virtual good transfer. Its not even a money for iphone app content transfer. Its just a bank transaction done within an iphone application, completely unrelated to apple.

The problem is real money -> virtual money, where as money is used as any universal trade good. Those things are not allowed by the InApp Purchase rules as you posted yourself and you are not allowed to sell anything in your app through any other way than the InApp purchase API.

If you try to sell anything on the iphone thats not sold through apple, your app at best is rejected, if you tricked them to get through by later enable it, your app actually is taken down and potentially black listed depending on the severity and can be followed by indemnification requests from apple.

Why do you think where there no in app contents and especially no subscription services around before 3.0 and some of those things still not around by now? :)

The rule basically is simple: You make money with an app or content for it -> the money goes through apples hands and apple gets 30% of it.
Thats as simple as it can be explained yet contains the full information required to keep in head

#16 Then why was the PayPal application not rejected by Apple? It does money transactions without going through Apple's API and Apple is not getting 30% of their transactions. It's not a game and although it's primary function is used to purchase real items I have no doubt that they process multi-millions of dollars, or more, a year aiding users purchasing virtual currency and the concept and rules should be the same.

But, you are right I'm not eBay and Apple has shown that they can reject an App for any reason, without even disclosing the reason. like the attempt to have the Firefox browser put onto the App Store. I can imagine if my game did start taking in millions in annual sales Apple would likely ban the app since they are not getting their cut.

So it seems futile to keep debating this issue. After thinking it through it is easy enough to sell virtual items in the game, avoiding selling virtual currency, similar to how EA does using Apple's API.

The benefits of having the transactions go through Apple, a trusted source (that already has your credit card info), rather than having to have the user sign up for an additional service outweigh any possible benefit a service like I described would provide. It even makes taking micro transactions much more feasible. Since the cost would be 30% regardless if I sell 1000 ten cent virtual products or a single $10 transaction (either way would cost me $3). This would not be true using my own credit card processor, since they have a set transaction fee.

So, thanks for letting me use this forum as a sounding board for the concept even though I could argue what I presented was technically allowed it is not a economically sound solution, and therefore irrelevant.

Though a service like Urban Airship that would take care of the back-end required to use Apple's API that was not bound to a software upgrade, such as selling virtual (non currency) items might still be a viable solution.

The dialog and my resulting research has been quite enlightening, and thus very productive. Hopefully others reading this will gain some of the same insight from it.

Thanks,

Nick Powers

#17 Apple's basic rule is something along the lines of this:
If your app is based on a service already available on other platforms - that is, if iPhone isn't the only platform - you have more leeway. See the Kindle app, or Stanza. Note that the Kindle app is free - that means they are not using StoreKit. So custom stores are possible.

Anyway, I think I'll go with Urban Airship if I need in-game purchases. They have a fixed price - who says I have to price all my downloads at 99 cents? That's still 5 cents per $3 map pack, for example.

#18 Because the PayPal application does not sell any InApp goods or any goods at all. PayPal is just a virtual bank, which allow you to do fund transfer from your bank account to another bank account.
It allows you to do what the browser would allow you too, just without the overhead and the massive view problem of the browser (and without the JS problems the iphone browser / safari in general has), thats it.

As selling party you have to comply to Apple's regulations, so if you provide a service or good in your application, then you are bound to the regulations.

And yes from the user point of view, selling goods and not virtual currency is a much better point of view, especially when the payments go through the same trusted source where the app already came from. They know what they pay for and they know that it will always be this said thing and that they can not lose it anymore.



@Ronny: The market demand ... a map pack at $3 would require an app at $10+ and in that case you wouldn't be here if you had such a master quality app ;)

#19 @Marc: It was just an example, although many people have talked about releasing $1 apps, and selling episodes at higher prices. Don't knock till you've tried it.