Content updated October 2021.
If you’re an entrepreneur or business leader looking to bring a mobile app to market, you should determine your pricing model before you begin development. If you plan to publish an app that isn’t free, you’ll need to not only decide on a fair pricing structure, but also think through how the users will pay for the app or app features.
Users typically pay for apps using one of two paths: Payment platforms or In-app purchases. It’s important to review the requirements for app payments, as well as pros and cons, in order to implement the right payment structure in your new app.
We'll be covering the following in our post about In-App Purchases:
There are two types of payment options available: Payment Platforms and In-App Purchases.
Payment Platforms, like Stripe, Paypal or Square, allow you to set up easy payment processing on your website and/or mobile app. These platforms are a good fit if your customers can pay for their account or make other purchases through your website.
In-App Purchases are different, in that they are only available for apps. Most people think of in-app purchases to mean annoying pop-ups asking for payment when you play a game on your phone, but the term in-app purchases actually means much more. In-app purchases can be used for Android and IOS app subscriptions, or premium features and services.
The Google and Apple App Stores will *require* you to use their in-app purchase options if your app doesn’t have a corresponding website where the user can access your app functions or update their account.
For example, an app called Parcel (a favorite of mine!) allows users to track their packages across carriers in the US. Parcel offers a free version that allows you to track up to 5 packages, and a paid version for unlimited tracking. Parcel has to use In-App Purchases, because they don’t have a website where a user can sign up and track packages as well. Their functionality is limited to their mobile app, so the purchase must happen there. (Note - I personally pay for Parcel, because I like to receive updates on all my Amazon or online purchases!)
On the other hand, the Nordstrom app (another favorite of mine - do you see the trend?) does not utilize in-app purchases, because I can go to Nordstrom.com and shop, create and manage my account, and check out.
Apple and Google both offer an easy-to-implement payment system for apps in their stores. App users can download and pay for the apps themselves and continual in-app purchases using payment information stored in their Apple ID or Gmail account.
Overall, In-App Purchases win out for the smoothest user experience. Since the user can quickly confirm the purchase with a password or fingerprint and bypass entering billing information, the purchase process is quick and painless.
However... this seamlessness comes with a hefty price: Apple and Google take 30% of your revenue for in-app purchases.
So while your user may pay $1.99 per month for your app, you’ll only make $1.39. Keep this in mind when you set the price of your app.
Here are other pros and cons of using in-app purchases in your mobile app:
Some developers or product leaders may suggest a workaround that won’t bode well for your app launch.
Let’s say that you don’t have a corresponding website for your app, but you want to avoid paying that 30% to Apple and Google. In the past, some developers could set up a website that has one purpose - account setup and collecting payment information. In theory, if you have a website that only serves the purpose of signing up and paying for a service, you could avoid in-app purchases.
However, Apple and Google have been cracking down on this practice. So heed my advice and steer clear of this potential “workaround.” Your app will likely get rejected, leaving you behind schedule and facing development re-work.
If you work as a developer and are implementing In-App Purchases for the first time, here are some items to think through from UI and implementation to testing and deployment.
With any application, product teams need to prioritize the user experience. With In-App Purchases, it is important to keep the user clearly informed about what in the application is free versus paid, as well as the value that the paid product might bring to them. In your app, consider adding a screen that explains the added benefits the user will gain by upgrading to a paid version, with a call to action button that leads them to the purchase.
Another important design choice is to always keep the user up to date on their subscription status in the settings portion of their app. This way, it is simple for the user to know which version of the app they are using.
Lastly, when a user is ready to cancel a subscription, clearly state that any subscription cancelations have to be done through the native store system. Subscription payments and cancelations are always handled through the Apple App Store and Google Play Store.
When beginning the initial development setup of IAPs, there are several things to consider.
Once requirements are made for your applications purchases, they can then be added to the development portals. For Apple products, you may insert the product purchases in the features tab of App Store Connect and for Android products navigate to the In-App products tab of the Google Developer Console. Once the purchase is set up, you may begin testing!
While the pricing options are generally easy to set up in the development consoles, they are more time consuming to test. Increase your typical estimate for testing! To help speed up your development time, here are 5 easy steps to follow:
If you need help determining which payment model is right for your app (or even help developing or designing the app!), contact us! We'd love to chat and provide whatever help we can for your idea and organization.