In-App Purchases on iOS and Android

In-App Purchases on iOS and Android

Challenges Due to the Nature of Mobile Development

In-app purchases (IAP) are unique to iOS and Android in the amount of revenue they can drive, and the challenge of testing these on large and complex apps.

IAP is unique to mobile platforms and when you sell digital products, not implementing it is rarely an option. You have to pay a hefty fee of 15% on revenue up to $1 million annually (both for iOS and for Android), and 30% above this. On top of the cut, you still have to work your way through numerous limitations and frustrations.

RevenueCat makes it easy to build and manage iOS and Android in-app purchases at scale. With a few lines of code RevenueCat provides IAP infrastructure, customer analytics, data integrations, and gives you time back from dealing with edge cases and updates across the platforms.

Created by developers, for developers, thousands of the world’s best apps use RevenueCat to power their in-app purchases and subscriptions. Get started for free here.

RevenueCat

IAP Limitations #

The biggest limitations of IAP you are likely to come across are these:

  • Different iOS, Android IAP models and capabilities and likely a different model from a web product. For example, Google Play allows pausing of subscriptions to prevent voluntary churn, but iOS does not. This is one of the several differences between the two platforms.
  • Implementing IAP state changes to happen in a bullet-proof way. Customers will expect IAP effects to happen immediately. However, doing so might be more of a challenge. You could do a purely client-side implementation which can be simpler to implement, but that makes the subscription fully tied to the App Store account. It also opens up attack vectors for bad actors, such as setting back the device clock, or running a modified version of your app that “unlocks” IAP functionality. You could wait on backend callbacks, but this can mean delays, and having to deal with more edge cases. These edge cases will be unique to your app and your IAP functionality.
  • Rigid pricing. With Apple, you can only choose from predefined price tiers, and changing the pricing for subscriptions becomes complex. You will find it challenging to set prices per country if your pricing is different from the suggested guidelines. If you decide to implement IAP as a purely client-side approach, you will also have to hardcode your products in the binary.
  • Poor API documentation. The subscription APIs for iOS are under-documented. You will find yourself troubleshooting how certain aspects of this works. Android IAP APIs are better documented and you will have less trouble with them.
  • Reporting challenges. Answering the question of “how much revenue does a specific user generate for us” becomes unexpectedly challenging, if not practically impossible. The challenge is calculating the net proceeds from the gross purchases a user makes, including the proceeds from follow-up transactions. A common approach is saving the gross price information, and making estimates of net revenue from various data points such as gross prices, aggregated daily reports and the App Store pricing matrix.
  • Accounting, reconciliation and tax woes. Both iOS and Android do payouts differently and report/handle taxes differently. Apple’s fiscal calendar is crazy by itself, including a 35-day accounting month. Your accounting team will be pulling their hair trying to work their way through how things work, and someone from the mobile team will likely need to help them figure out how the numbers add up.
  • Subscriptions support. On iOS, you do not have the tooling to cancel or refund a subscription, even if the user asks you to do this. See the subscriptions page for Disney+ for an example of the type of awkward customer messaging this results in.
  • B2B use cases and supporting volume discounts, or providing VAT receipts. While Apple does have a volume purchase program for apps, there is nothing similar for IAP. For VAT invoices, you need to direct users to find this option in the App Store, or request this via Google Play.

IAP Edge Cases #

IAP edge cases and handling them should give you plenty of work. Most of these edge cases are not unique to IAP, but will be challenges on the web as well. You still need to validate these cases.

  • IAP states and handling them, such as cancelling a one-off purchase, cancelling a subscription or re-purchasing after cancelling.
  • Grace periods and trials for subscriptions. Can people extend their trial, if they need more time?
  • Upgrading, downgrading, changing subscriptions. The more tiers you have, the more edge cases to think about.
  • Discounts and working with these. You have to use promotional offers or subscription offers on iOS and promo codes on Android. Managing, keeping track and retiring discounts gets more difficult with each new one.
  • **Your IAP backend endpoints going down. If your IAP solution relies upon the App Store Server Notifications, or the Google Play real-time developer notifications for server-to-server events, you want to have close to 100% availability for persisting these events, even if your processing capability is down. The App Store might retry if your endpoint is not available, but this behavior is not documented for iOS, nor for Android.
  • Other edge cases such as refunds, credit card failures, account hold, grace period or paused subscriptions on Android.

Testing IAP #

Manually testing that in-app purchases work is a smaller challenge itself. Both Apple and Google provide ways to test IAPs; Apple offers their Sandbox on iOS and StorekitTest for unit testing. For Android, on Google Play you can test with license testers in the Play Store sandbox.

Note that the sandbox environment comes with limitations. There will be some real-world scenarios you cannot replicate in this setting. You will probably also have to tweak your backend to allow for sandbox testing.

Testing for various IAP scenarios is where validating in-app-purchase functionality can become complex.

  • One-off purchase testing is the most straightforward scenario. Still, you want to test for all purchase types to ensure they work.
  • Validating receipts content is an often overlooked step. The information on the customer receipt should be clear, in order to avoid unwarranted chargebacks or complaints.
  • Subscriptions upgrade testing means both testing for people upgrading from no subscription to a subscription tier and ensuring all subscription tiers work as expected.
  • Subscription upgrades and downgrades are things you should test for. Scenarios can especially be tricky when downgrading. Are there scenarios you need to pay attention to, where subscribers could lose some of the data they entered?
  • Crossgrade between subscriptions is a more rare case. However, if you have multiple subscription tiers that are not on an upgrade or downgrade path, for example, switching between a monthly and a yearly subscription, then you need to test for these cases.

Apple has a comprehensive overview of test scenarios you might want to test for and from which to take inspiration for Android.

Automating IAP testing is challenging, both due to the limited tooling available, and the complexity of manually testing IAPs. Automating should be a step easier if you have a well-documented manual testing process for IAP. Tools that you could use for IAP automation include StoreKit Test (iOS) or tools such as BrowserStack.

Other Challenges #

Multi-platform IAP challenges will be a recurring theme you need to deal with, assuming you sell across iOS, Android and possibly other platforms such as the web. Each platform will have different tax policies. You have to deal with a customer buying the IAP on one platform, then switching over to another one.

For example, what would happen when a user buys an IAP on iOS, and then buys a new Android phone, where they subscribe again? Would you build a flow to support “transferring” the subscription? Would your backend “detect” the same person subscribing on two platforms? Would you have a customer support runbook on what to advise people who are about to change phones? What does your competition do in this case - and can you do better?

The lack of IAP tooling support for any non-basic scenario is what will likely cause you the most headaches. Neither Apple, nor Google have built anything beyond a simple one-off or a subscription product. When you are building complex apps, or apps with many users, you’ll likely find the business wanting more options: and yourself looking at how to work around a limiting IAP feature set.

Collaborating with the backend team who “captures” IAP user data will be critical in building a solid product. The backend team will likely have to work with an iOS, Android and possibly a web team - each platform handling payments and subscriptions in a different way.

It will be down to you to educate the backend team on how iOS or Android handles IAP, and what edge cases you’ll need to test. Working with the backend team is also a good opportunity to get exposed to how IAP works on the “other” platform, and how the web handles the same problem space.

You are reading an early draft from the book Building Mobile Apps at Scale. For the final, expanded and improved content, grab the book now - it's free to download as a PDF until 31 May.

Building Mobile Apps at Scale

"An essential read for anyone working with mobile apps. Not just for mobile engineers - but also on the backend or web teams. The book is full of insights coming from someone who has done engineering at scale."
     - Ruj Sabya, formerly Sr Engineering Manager @ Flipkart

Get the book here