Every day there are more apps in the Windows Phone Store that offer in-app purchase: in the past 6 months alone, the sales of in-app purchase items in Windows Phone Store has grown by over 20x. Windows Phone apps with the highest in-app revenue share some key characteristics, which we believe could be valuable to you as a set of best practices for implementing in-app purchase. In this post we also look at practical approaches and scenarios that can help you avoid common errors when you decide to monetize your Windows Phone apps via in-app purchase.
Apps and games sold in the Windows Phone Store that have the highest in-app revenue share several important characteristics:
Here are some useful examples from apps in the Store that have been the most successful in their implementation of in-app purchase.
Along with the increase in apps that feature in-app purchase, we are seeing an increase in the number of apps that don’t implement in-app purchase correctly. This could generate certification delays, lost income opportunity for the developer, and if not fixed, can cause a negative experience for app users, who can submit negative feedback.
Three of the most common in-app purchase errors occur in these scenarios:
Read on for testing and fine-tuning you can do to help bypass these trouble spots in your app.
In Windows Phone apps, there are two primary instances in which an app “owes” the user a purchased item. More than 80% of the failures we see in in-app purchase app submission don’t handle these events correctly.
In both of these cases, because of an interruption, the app is not “aware” that a purchase needs to be awarded to the user – either again for an app reinstall or as an initial fulfillment if the fulfillment process was interrupted at time of purchase.
You can test your app before submitting for certification to see how it handles these events.
How to test:
How to handle app interruptions correctly:
Design your app to check for previously purchased items that are not yet awarded, and to fulfill them when the app starts.
You can use a version of DoFullfillment() from the In-App Purchase API documentation to create a function to handle these scenarios. Here’s an example:
Take a look at the DoFullfillment method in In-App Purchase API overview for Windows Phone 8 and call something similar when the app launches, as well as when the user tries to purchase an app. Even if the app crashes or the phone shuts down in the middle of the transaction, the purchase is not lost.
Sometimes a user initiates an in-app purchase, but then decides they don’t want to make the purchase after all. Your app should not award the items, and ideally it will inform the user that the purchase was not successful.
How to test:
Launch your app, purchase an item, cancel the purchase before the purchase is completed (either by tapping back or by tapping cancel). The app should continue to run normally, and it should not award the item you initially started to purchase, but then cancelled. Ideally a notification will inform you that the purchase did not complete, and that the item will not be awarded.
How to handle cancellations correctly:
Here’s an example from the In-App Purchase API documentation that shows how to handle cancellations and errors correctly:
When a user purchases the same Consumable item multiple times, the game should be able to handle each purchase as an item that is eligible for repurchase, and allow the user to purchase the same item again.
Launch your app, purchase an item, and verify that the item is awarded (for example, you received the 10 gold coins you purchased). Then, purchase the same item again: the app should add an additional 10 gold coins in the game.
How to handle multiple consumable purchases correctly:
The In-App Purchase API documentation describes a DoFulfillement() function that handles consumables correctly. You call ReportProductFulfillment() to indicate that a purchased item has been fulfilled, and so it can be purchased again.
We encourage you to test your apps before submitting to the Windows Phone Store, learn from the in-app purchase code sample, and consider following the best practices implemented in the apps we highlighted. All of these approaches can help you build an in-app purchase app that passes app submission certification, and which delights your users.
If you have questions about in-app purchase for Windows Phone, leave a blog comment, and let me know how I can help add in-app purchase to your app.
I love the screen shot showing the different level of gems someone can purchase. And its great there is no limit the developer is held too because they could throw $200 if they wanted to. But for a parent that has a Windows Phone, this is a scam. Parents download games that look safe for their kids to play not realizing that pop-ups for in app purchases may appear at the perfect time for disruption of play. To a child, when presented, they'll click on anything to get back to the game. This means the amount with the best looking eye candy. I know because I'm out $110 thanks to this. Developers know that Window Phones don't automatically prompt for credentials by default (and the few people I know with WinPhones don't know or setup Kids Corner). This means open season for making money until they find out the hard way. Why does a child's game list $89 purchases if this is not meant for targeted exploitation? Think about it!
Parents - You need to setup Kids corner and store kid games there. Also setup a Pin in the Store settings > Wallet > Pin. Don't use credit cards for your account, replace with small amount gift cards and add when needed. If already burned by this and using Credit card, go to your cards website, find the purchase, mark for dispute and work with your bank.