Developing Payment Options in Your App

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:

• Know your payment options
• Pros & Cons of using In-App Purchases
• A Workaround you should skip
• Development Tips:
  • Design considerations
  • Set up for Dev Portals
  • How to Speed up Development & Testing Time

Know Your Payment Options

What payment options are available for my website and/or mobile app?

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.

How do I know which payment option to use? 

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.

In-App Purchases: Pros + Cons

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:

Pros of In-App Purchases:

• Users don’t have to set up additional accounts or enter billing information upon purchase.
• Users can conveniently pay with preferred GPay or Apple ID payment methods.
• Your paid customer acquisition process is faster. You won’t lose out on users that need to pause and go find their credit card to sign up, but never do.
• Developers will spend less development hours on setup, because of built-in settings that are easier to manage, like multiple pricing options, prices or availability for different countries.
• Developers can also easily implement a free phase leading to the in app purchase or subscription, like a free trial timeframe or a set amount of actions for free.
• It's easy to set up different pricing models to match your business plan, whether your app costs $3.99 up front or $1.99/month.
• Reporting on in app purchase revenue is easy, since Apple and Google both offer out-of-the-box dashboards to manage and report on paid or free users.

Cons of In-App Purchases:

• Apple and Google receive 30% of your in-app purchase revenue.
• Users cannot pause an in app subscription for a set amount of time. Users that need to “go on hold” will need to cancel.
• During development, additional testing is required across various scenarios on different device types to make sure in-app purchases are implemented correctly.

A Workaround...That Won’t Work

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.

Development Tips for In-App Purchases

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.

Design Choices to Consider

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.

Setup for Dev Portals

When beginning the initial development setup of IAPs, there are several things to consider.

• Know ahead of time that each app can have one of these pricing options, not a mix:
  • A subscription setup that gets renewed after a set duration of time
  • A product setup, where a single price is paid one time for one product
• Each product and subscription will have to have a unique SKU for the entire store
• An application may have multiple subscriptions and products if needed.

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!

Speed up Development & Testing Time

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:

1. Create a sandbox user
   • Navigate to the Apple and Google developer consoles to create sandbox users. Once created, use those credentials to test from your physical device. Currently the Apple simulators and Google emulators do not support testing of IAPs, so you must use a real device.
2. Check for a receipt
   • On the app initialization, check to see if the current user has any IAP receipts. If no receipts are found, you may assume that they have not made any IAPs.
3. Validate the receipt
   • On the other hand, if a receipt is found, you must validate it. Apple and Google both have public endpoints to send receipts to. This API will return if the receipt is legitimate. If the receipt is authentic, we can now determine if they have any active purchases.
4. Determine if the purchase is active
   • For the next step, you must determine if a receipt is still active. To do so, compare the expiration date with the current date. If the expiration date is later than the current date then the subscription is still active.
5. Display the correct views
   • Lastly, as a developer, you must determine what is displayed to the user. If a receipt is authentic and active, ensure that the user is able to view the paid content. Otherwise, display the original free portions of your application.

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.