In-app payments and purchasing – cost and profitability

There are many methods of app monetization, but none are as palatable for users – and profitable for publishers – as in-app payments and in-app purchasing. Just like any lucrative revenue stream, however, there are many costs (both hidden and upfront) associated with implementing the ability to charge users while they are engaging with your app; and there are even more pitfalls that may pop up during the development and implementation of in-app purchasing and payments.

Below, you’ll find knowledge about the deployment, cost, and revenue potential of in-app payments and purchasing:

The difference between in-app purchases and in-app payments

There’s a lot of different ways for users to spend money in apps, and a plethora of platforms that facilitate payments. In-app purchases are distinguishable from in-app payments because they are used in situations where the user isn’t buying a product, but rather additional content for the app itself.

In-app payments refer to purchases made through an app – the most common example being eCommerce apps, or even retail apps like those for Target or Kroger. Both of these methods involve the user paying for a good or service – but both are implemented (technologically, and strategically) using different methods, and come with different associated costs, as well as revenue models.

Let’s look deeper into these two revenue-driving options:

In-app purchases

In-app purchases can be broken down into four categories:

1. Consumables: These are (usually) single pieces of content that are purchased once, depleted, and then purchased again. The most obvious example of a consumable purchase in an app would be lives, gems, or coins that many mobile games use as in-game currency. Another example of consumable purchases that is outside of the gaming sphere, however, is Tinder’s option to buy more swipes. Consumable purchases don’t just belong in games – if your consumable purchase can provide enough value, users will purchase it.
2. Non-Consumable: These are, not surprisingly, the direct opposite of consumable purchases. Once bought, these extra pieces of content, additional features, or extra services will never expire. A good example are filters in Instagram, or sticker packets in WhatsApp.
3. Auto-Renewing Subscriptions: Using this model of in-app purchasing, users buy access to services that regularly provide content updates, like Hulu. Other subscription services offer more utilitarian products, like cloud storage services such as dropbox, or productivity software like Monday. Users will be charged on a regular basis using this model.
4. Non-Renewing Subscriptions: Users will purchase access to services or content just like auto-renewing subscriptions – this method differs in one key factor however: content is not regularly updated, and the user is only charged once for the content or service, and not on a reoccurring basis. The most prevalent example of this would be the omni-present “season pass.” In order to access these services or content, users must pay for every release.

Note: For apps published to Apple’s App Store to make use of in-app purchasing (and payments), publishers must sign Apple’s Paid Applications Agreement, as well as set up their company’s baking and tax information with Apple.

There are two options when it comes to in-app purchasing APIs: StoreKit for iOS, and In-App Billing API for Android (always with the clever names, Android). These options are the only two available for implementing in-app purchasing through Apple and Google’s platforms, and both (just like the sale of any product or content through the App Store or Google Play) will take 30% of the profit from each in-app sale made through your app.

This form of app monetization is, so far, incredibly successful, if implemented respectfully and properly. According to a study conducted by App Annie, out of 1,200 developers, 50% of them used in-app purchases to drive their revenue, and the App Store’s top revenue-earning app of 2018, the game Fortnite, made $450 million that year – using a revenue model mainly based around in-app purchases of character costumes.

In-app payments

This is where your field of developmental and payment options begin to widen – the purchasing of goods, services, and content outside of the App Store or Google Play can be implemented through many different APIs, and the strategy behind the CTA changes based on the individual app.

On of the most popular apps to make use of in-app payments is Uber – riders need a way to pay drivers, and drivers need a way to receive payments. In the same manner as Apple and Android with in-app purchases, Uber takes a percentage of the profits from each transaction between riders and drivers.

This revenue model is also highly successful – Uber’s revenue in 2018 was $11.27 billion.

In-app payments are also the backbone of mobile eCommerce – an industry that boasted 500 billion individual sales in 2018.

While you can develop your own custom in-app payment processing system, there are APIs out there that can speed up development: two popular options being Stripe and Braintree. Both of these APIs provide end-to-end encryption, and charge a percentage for each credit or debit card transaction. Stripe charges 2.9% + $0.20 for non-European cards, and Braintree charges 2.9% + $0.20 as well.

In the near future, we’ll cover these (and more) in-app payment APIs in greater detail – so stay tuned for a deep dive into payment gateway APIs.

When implemented, and not imposed, in-app purchasing and payments are an un-stoppable revenue stream

The key to both in-app purchases and payments is to be honest, clear, and provide value. Remember – anyone can play Fortnite for free, and yet it made $450 million last year. While the in-app purchases in the form of costumes weren’t necessary to the gameplay, users were more than happy to purchase them. When users don’t feel pressured to pay for extra content or services, but are rather presented with the option, they are more likely to pay, and continue engaging with your app.