Payment processing is one of the most common features of applications today - especially mobile apps. Just think about the number of games you played as a kid on your phone or tablet. "Watch this ad for another life". "Buy 150 V-bucks for $1.99". "Unlock unlimited lives for $0.99". These are just some examples.
With mobile apps specifically, native in-app purchasing is a pretty loaded subject. As the user of an application with in-app payment processing, it can be a very enjoyable thing. It's quick and easy to just purchase something right there and not have to navigate outside of the app. However, it's not as simple as it may seem. There are a lot of restrictions and regulations on each app store. And developing this software can be rather time-consuming.
Allow me to set the stage.
Let's say that we are developing an interactive React Native game. The purpose of the game is for users to find their way through a maze in a specific amount of time. If you succeed, you pass the level. If you run out of time, you fail the level. We want to have a few in-app purchases that allow users to continue playing the game. It's now time to integrate the in-app billing portion of the app.
Understanding In-App Purchases
First, you need to understand what an "in-app purchase" really is. There are several different specifications of in-app purchases depending on the platform that you are using. For this exercise, we are going to walk through what it is like to work with Apple IAPs. To put it simply, it's because Google is much more straightforward. To learn about Google Play In-App Products, click here.
On the App Store, there are four major classifications of in-app purchases: Consumables, Non-Consumables, Auto-Renewable Subscriptions, and Non-Renewing Subscriptions. The first two are one-time purchases, while the other two are specifically subscription-based. For our maze game, we are going to use a few Consumable options. These are one-time purchases that expire after a certain amount of time.
Integrating IAP functionality
So how do we set all of this up? There is a lot of documentation out there to help you get started. One thing to note: you MUST use a bare workflow. The reason for this is that you must configure iOS and Android differently. We recommend doing research at this time and finding some resources that outline all setup steps.
Let's assume our iOS settings are configured properly, the next step would be to create and submit the consumable in-app purchases on App Store Connect. Once approved, the final step would be to write the code in our app that handles all purchasing functionality. For React Native applications, we would recommend using the Expo InAppPurchases or React Native IAP libraries.
After all of the above steps have been taken, the app is ready to be tested and approved.
What is good about In-App Purchases?
1) The billing process is streamlined and seamless.
The nice thing about going native here is that Apple and Google handle all of the billing responsibilities. Once you set up a billing account and give them your banking information, that is pretty much it. Purchases by users will be sent to your billing account. Something important to note here is that Apple and Google Play do have different rules in terms of how developers are paid out. Be sure to fully understand their rules & guidelines.
2) Customer support is off of your hands.
If a customer has a complaint or dispute, you do not need to handle that. If it is something specific to billing, Apple and Google will be responsible for taking care of that, initially. They may reach out to you for further assistance. Since the customer is paying through Apple and Google, the disputes would have to go to their customer support team - saving you a lot of stress and time.
3) No need to deal with other payment processing services.
Since Apple and Google Play handle this process directly, there is no need to deal with any third-party vendors or develop your own REST APIs. There are plenty of React libraries that work with Apple and Google when it comes to in-app purchasing.
What is (not so) good about In-App Purchases?
1) There are fees.
Apple and Google do keep a percentage of all sales. The number is constantly changing, but at the moment, they take 15% of revenue. That number has recently come down from 30%. We'd recommend looking at both Apple's and Google's guidelines.
2) They control when you get your money.
Each platform is different in its payment schedule. Google is pretty straightforward. - all payments in a given month will be paid out on the 15th of the next month. So all payments received in May will be paid out to you on June 15th. Apple, however, is not so simple. Apple can take up to 45 days to payout. And that is only if you reach the minimum payment threshold of $150 (this varies per country). Therefore, you may not actually receive your money until you reach that figure.
3) Testing is rather difficult.
As if the configuration and development of this stuff were not hard enough, testing in-app purchases is a rather complex process. With React Native, testing in-app purchases can only be done on physical devices. Simulators will not work. You need to be running your app on a physical iOS or Android device, which can make debugging a much more frustrating process...
Do you even need to use in-app purchases?
It really depends on what your app needs to do. The unfortunate reality is if you intend on putting your app on the App Store or Google Play Store, they dictate whether your app will be approved and released. Google is pretty lenient with their approval process - we have not had any issues with them. However, Apple is incredibly picky (to put it nicely) with its approval process. They require that you use their in-app purchases when putting things on their store. If they review your app and determine that you have one-time purchases or subscriptions in your app, they will not approve your app until you use their in-app purchases. If you are just sending transactions or making payments, like PayPal or any retail store, you probably don't need to worry about this. But if your app is subscription-based, or has one-time in-app purchases (like our maze game example), chances are you won't be able to get around it.
Do you have an idea and need help turning it to a reality? Book an appointment with us today (for FREE !!). Why wait around?
Comments