Skip to main content
August 30, 2013
Windows Phone Developer Blog

In-App Purchase: Success stories and Tips to test common in-app failure scenarios



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.

Best practices

Apps and games sold in the Windows Phone Store that have the highest in-app revenue share several important characteristics:

  • They use in-app purchase to extend or accelerate gameplay, or to unlock highly valuable content.
  • They have a high replay value, to give users incentive to spend more time in the app.
  • They make it easy to purchase in-app items using custom UI, and they lead the user to the purchase experience at the right time.
  • They offer multiple options, at different price points, to appeal to the most number of users.

Here are some useful examples from apps in the Store that have been the most successful in their implementation of in-app purchase.

Royal Revolt! (flaregames GmbH)


image

image
  • Game progress is based on coins and gems, earned through gameplay. Players use these to purchase enhancements, such as more advanced weapons.
  • The game has many levels, and new capabilities are unlocked as the player progresses through the levels. The faster a player finishes a level, the more stars and coins they get. These features lead to higher replay value.
  • The app displays its UI to offer in-app purchase promotions at the beginning of the game, and suggests items to purchase at relevant points in the game. For example, if the player’s character expires and the game would otherwise end, they are offered in-app purchases that could revive and extend the game.
  • The game displays the app purchase UI icon on almost every screen. The icon is discreet, but it makes it easy to access the in-app purchases.
  • The game includes multiple offers at different price points, starting at $0.99 (prices can vary depending on the country or region, and current price promotions).

CoPilot GPS (ALK Technologies Limited)

  • CoPilot GPS app features maps and voice navigation for many countries and regions.
  • The app offers features not found in other GPS apps.
  • The app offers a 14-day trial, so users can try the maps before purchase.
  • The app initially asks the user to choose a primary map, and then offers a wide portfolio of maps with different coverage and price points.
  • The maps can easily be acquired and downloaded after purchase.
image    image

Drag Racing (Creative Mobile)


image

image
  • Game progress is based on Reputation Points (RP), earned through gameplay. Players use RPs to unlock enhancements (engine, wheels, etc.) and to unlock new vehicles.
  • The game has many levels of competition, different cars, car engine enhancements, and even online racing competitions. These features lead to high replay value.
  • The app offers many opportunities to earn RPs, as well as many options to spend earned RPs.
  • The game offers RP packages for purchase, at different price points, starting at $1.49 (prices can vary depending on the country or region, and current price promotions).

Scenarios

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:

  • Purchase flow is interrupted.
  • Purchase is cancelled by the user.
  • Multiple consumable items are purchased.

Read on for testing and fine-tuning you can do to help bypass these trouble spots in your app.

Purchase flow is interrupted

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.

  • App is reinstalled: An app user acquires a durable in-app purchase item and the app awards the item. If the user changes phones or reinstalls the same app, they should have the same durable in-app purchase item available that they had purchased previously.
  • Purchase was completed, but fulfillment process was interrupted: A user purchases any in-app purchase item, the purchase is completed, but fulfillment is interrupted. The user is not returned to the app, and the purchased item is not installed in the app.

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:

  1. Launch your app, and then purchase a durable item. Ensure the item is installed or unlocked, however a user would access the purchased item. Then uninstall the app. Reinstall the app and the item should either be automatically unlocked or reinstalled. If this doesn’t occur automatically, the app should offer you an option to reinstall the item (at no cost).
  2. Launch your app, purchase an item, and before the purchase process returns you to the app, touch the home button on the phone and then relaunch the app. The app should detect that it has unfulfilled purchased items and award them to the user.

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:

C#
  1. // This is called during startup, ideally in a background process
  2. // Well check for unfulfilled items, and fulfill if needed
  3. public void CheckUnfulfilledItemsAtStartupTime()
  4. {
  5.     var productLicenses = CurrentApp.LicenseInformation.ProductLicenses;
  6.  
  7.     // Check fulfillment for CONSUMABLE products with hard-coded asset counts
  8.     FullfillItemsIfUnfulfilled(productLicenses[“50gold”], 50);
  9.     FullfillItemsIfUnfulfilled(productLicenses[“100gold”], 100);
  10.  
  11.     // Check fulfillment for DURABLE products, if not fulfilled already
  12.     if (!InfiniteGoldPurchased)
  13.         FullfillItemsIfUnfulfilled(productLicenses[“Infinitegold”], 99999);
  14.  
  15. }
  16.  
  17. // Gold to be awarded is passed as a parameter
  18. void FullfillItemsIfUnfulfilled(ProductLicense license, int goldCount)
  19. {
  20.     if (license.IsConsumable && license.IsActive)
  21.     {
  22.         m_goldCount += goldCount;
  23.         CurrentApp.ReportProductFulfillment(license.ProductId);
  24.         // and store the data in the app if needed
  25.     }
  26.     if (license.IsDurable && license.IsActive)
  27.     {
  28.         m_goldCount += goldCount;
  29.         InfiniteGoldPurchased = true;
  30.         // and store the data in the app if needed
  31.     }
  32. }

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.

Purchase is canceled by the user

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:

C#
  1. async void PurchaseProduct(string productId)
  2. {
  3.  
  4.     try
  5.     {
  6.  
  7.         // Kick off purchase; don’t ask for a receipt when it returns
  8.  
  9.         await CurrentApp.RequestProductPurchaseAsync(productId, false);
  10.  
  11.         // Now that the purchase is done, give the user the goods they paid for
  12.  
  13.         DoFulfillment();// (DoFulfillment is your function)
  14.  
  15.     }
  16.  
  17.     catch (Exception ex)
  18.     {
  19.  
  20.         // When the user does not complete the purchase (e.g. cancels or navigates back from the Purchase Page), an exception with an HRESULT of E_FAIL is expected.
  21.  
  22.         // The in-app purchase was not completed successfully, so no items should be awarded to the user.
  23.  
  24.     }
  25.  
  26. }

Multiple consumable items are purchased

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.

How to test:

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.

C#
  1. public void DoFulfillment()
  2. {
  3.     var productLicenses = CurrentApp.LicenseInformation.ProductLicenses;
  4.  
  5.     // Check fulfillment for consumable products with hard-coded asset counts
  6.     MaybeGiveMeGold(productLicenses[“50gold”], 50);
  7.     MaybeGiveMeGold(productLicenses[“100gold”], 100);
  8.  
  9.     // Check fulfillment for consumable products with variable asset counts
  10.     MaybeGiveMeSilver(productLicenses);
  11. }
  12. void MaybeGiveMeGold(ProductLicense license, int goldCount)
  13. {
  14.     if (license.IsConsumable && license.IsActive)
  15.     {
  16.         m_goldCount += goldCount;
  17.         // Report item fulfilled, so it can be purchased again
  18.         CurrentApp.ReportProductFulfillment(license.ProductId);
  19.     }
  20. }

Next steps

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.

Tags:
Developing Apps
In-App Purchase