In-app purchases – for what and why? Analyst’s view

I will share with you my experience in designing and preparing technical specifications for the implementation of in-app purchases, and for convenience I will do it in two parts:

1. In-app purchases – for what and why? Analyst’s view

2. In-app purchases – why and how? Analyst’s view

In the first article, we will look at what in-app purchases are and in what cases you can do without them, how stores regulate IAP and (suddenly) how important lawyers are in mobile development.

What are in-app purchases and why is it needed?

Of course, everyone is familiar with the concept of marketplace applications: these are e-commerce applications in which you can buy a variety of products. Most smartphone users have them. To make such purchases through the application, you can integrate the SDK, use WebView, or even simply redirect the user to the web version and continue the payment flow there.

It would seem that buying slippers for your grandmother at the dacha is like buying a subscription to Down Dog — the difference is not great, but there is one “but”:

It is impossible to implement the purchase of content in mobile applications using the same methods as the purchase of goods.

If you try to do this, you will not pass verification. Google Play And App store. Purchasing content should be carried out exclusively using stores, and more specifically, using in-app purchases or IAP.

For example, the company Paddle, inspired by the court decision in the Epic vs Apple case, announced work on an analogue of the App Store IAP. For Android, work is also underway to allow alternative billing systems. So far, this opportunity is available only for a limited list of countries, and along with the alternative billing system, the original one must still be implemented.

There is a possibility that stores will soon allow alternative ways to implement in-app purchases. For example, a company Paddle, inspired by the court decision in the Epic vs Apple case, announced work on an analogue of the App Store IAP.

For Android, work is also underway to allow alternative billing systems. So far like this The opportunity is available only for a limited list of countrieswhile along with the alternative billing system, the original one must still be implemented.

Examples of IAP products

To make it clearer what content falls under IAP, I have collected examples of such products:

• Content app subscriptions: Down Dog, ArtforIntrovert.

• Service subscriptions: for example, data storage applications like Microsoft OneDrivephoto editors like Canva:Design, Photo & Video.

• Premium Content and Features: Flo, LinkedIn.

• All kinds of purchases in gaming applications: Cut the Rope, Among Us.

• Virtual currency used within the application: candy Crush Saga, Roblox.

And a couple more tops with IAP applications: first And second. The IAP category includes almost all possible options for monetizing content. However, there is one exception.

“Reader” Apps

If you spend some time on forums dedicated to IAP, you will find that for some reason the participants in these forums are not very fond of Netflix (once, two, three).

And the point here is not at all in pop series, but in the fact that Apple’s Review Guidelines have one exceptionwhich does not require an IAP implementation – these are the so-called “Reader” Apps.

Essentially, this is a loophole for applications that also have web versions. “Reader” Apps may not implement the purchase of content through the application at all, or can transfer the user to their website to make purchases.

Google Payments policy there is approximately the same exception For Consumption-only (reader) apps. However, the presence of a web version is not a sufficient argument to be included in the “Reader” Apps category. There are clear characteristics that not all applications satisfy (unlike Netflix):

1. The application should specialize in the following content: magazines, newspapers, books, audio, video.

2. The application must not provide personal services (training courses, training, consultations, etc.).

Store commission

I think everyone can guess why stakeholders are jealous of applications that fall into the “Reader” Apps category. Of course, the point is the rather large commission that stores charge for purchases through IAP.

If the application owner received up to $1 million within 12 monthsThe commission fee is 15%. As soon as he exceeds the 1 million markthe commission increases to thirty%.

To accurately calculate the commission taking into account changes in subscriptions, promotional periods, and the like, you can use the article “How to determine Apple and Google Stores commission rates for in-app purchases“

Types of in-app purchases

Fortunately, IAP types do not differ between platforms (iOS And Android). There are four in total:

1. iOS: Consumable / Android: One-time consumable product — consumable and renewable products. For example, virtual currency or boost in the game. The user can buy such a product, then spend it and buy it again.

2. iOS: Non-consumable / Android: One-time non-consumable product – perpetual products. For example, additional filters for photos. This product is purchased once and is always available.

3. iOS: Auto-renewable subscriptions / Android: Subscription with auto-renewing base plan — automatically renewed subscriptions. For example, a music subscription. Payment will be charged until the user cancels the subscription.

4. iOS: Non-renewing subscriptions / Android: Subscription with non-renewing (prepaid) base plan – non-renewable subscriptions. For example, access to seasonal content. After the end of the paid period, the subscription will automatically end.

Unfortunately, their implementation is still different. I’ll tell you about the pitfalls we stumbled upon in the second article.

IAP in Russia today

Since March 2022, sanctions regarding payment systems began to apply in Russia: Visa and Mastercard suspended work in Russia, Russian banks were disabled from Swift. Of course, these changes affected the ability of Russian users to pay for subscriptions in applications.

In this regard, Google Play limited release and update capabilities paid applications in the Russian Federation.

The App Store did not directly prohibit developers from releasing such applications, but you need to understand that, although there are workaround payment methods (once And two), they are not always simple and accessible. Simply put, users from Russia need to try harder to pay for the content.

Therefore, if your application is designed for the Russian market, it makes sense to take a closer look at the analogues of the App Store and Google Play. For example, in RuStore Have an opportunity content monetization.

If you accept risks and want to release an application with IAP in the App Store, then I advise you to read the article “How can a Russian developer register in the App Store from scratch?“: there is an example of how this can be done.

Our experience in implementing IAP

Now that we know what in-app purchases are and why they are needed, let’s talk about our experience in implementing IAP (by the way, this was the team’s first experience). Along the way, we’ll look at the problems we encountered and possible ways to solve them.

Formulation of the problem

We implemented a native mobile application (MP) with content in the form of courses for the foreign market. The application also had a web version (the web front and general back were implemented by another contractor). The customer wanted to implement:

1. Possibility of subscription to all paid content via the web version and via MP. The subscription required was auto-renewable with three possible payment periods: a month, three months and a year.

2. Possibility of purchasing individual courses through the web version and through MP.

3. MP was also supposed to retain free content available to users without a subscription.

4. “Hard” paywall upon registration. The original requirement was: so that the user cannot register without purchasing a subscription. We will consider below what it transformed into later.

Well, the usual and painfully beloved one – the release is in two months, guys, let’s go!

IAP regulator

One of the first things that catches your eye when searching for information on IAP: stores, especially the App Store, very carefully review applications with such functionality, and almost no one manages to pass the review the first time.

Of course, having learned such introductory information, we tried to prepare properly. As it turned out later, this is not easy to do. The IAP regulator plays an important role in frequent rejections.

Stores have certain requirements for implementing in-app purchases. To put it succinctly: You must not mislead users about any service, subscription, or content you offer in your app.
For more details, see the requirements for Google Play there are even examples of how NOT to do it, App Store requirements are collected in the format of recommendations.

Many requirements are clear and easy to implement. I will focus on a few, but I will not list them all:

1. The amount that will be written off should be more noticeable than the marketing amount.

   For example, with an annual subscription there will be a discount: the amount per month will be less than with a monthly subscription. It makes sense to include this information on the subscription screen. BUT if the user chooses an annual subscription, he will be charged the amount FOR THE YEAR, and not for the month, which is why it is important that the real amount of the charge is obvious.

   

2. Information about the trial period must include information about its duration and the amount that will be written off at the end.

   

3. Subscription screens should include links to the Privacy Policy and Terms of Use.

The requirements listed above are quite clear. But in some places the documentation of the review requirements is very, very vague, so during the implementation process we had several questions to which we could not find answers.

Paywall

Here we need to return to the statement of the problem and remember that among the initial requirements was the implementation of the so-called “Hard” paywall.

What it is? Essentially, this is a “payment wall” that blocks access to the application until the user pays for the subscription. There are both “Soft” paywalls—walls that the user can skip and continue using the application—and “Hard” paywalls—walls that the user cannot skip.

I advise you to check out the excellent article on implementing Paywalls.

According to the original requirements, we should not even register a user without a subscription. This requirement turned out to be impossible: the subscription had to be made in an authorized zone. However, we could well not allow the registered user to go beyond the payment wall.

Everything was complicated by the fact that our application had an unauthorized zone, in which certain free content was also available. But if a “Hard” paywall was implemented, after registration the user would lose access to this free content of the unauthorized zone.

It would seem, what’s wrong? We fulfill customer requirements. However, in the guidelines Google Play we found an interesting phrase that if the user has the opportunity to use the content for free, then our subscription offers should clearly show this.

Our initial solution not only did not show such a possibility, it did not allow us to leave the paywall at all. I’ll tell you below how we solved this case, but for now you can think: how to satisfy the requirements of the customer and the store at the same time?

Restore purchases

Another question that tormented us for a long time: is the “Restore purchases” button needed in the application?

Restore purchases, or restoration of purchases – a requirement from the guidelines App Store.

Let’s imagine the situation. You bought a new phone, logged in to the store and re-downloaded your application in which you purchased the subscription. By tapping on this button, the method goes through your payment transactions and restores them: as if it is carried out again without the need for repeated payment. This way you get access to content you’ve already paid for.

Everything sounds great with one exception: purchases will already be restored without running this method. The user logs into a new device, logs into the store with his credits – at this stage the store already displays all his purchases. Then he downloads the application and logs into it – the back also remembers all the user’s purchases and, for its part, returns them, as well as access to the content. Done, you can use the application.

We puzzled over this problem for a long time, re-read the guidelines and forums. Everywhere the information was divided 50/50: somewhere it was written that without this function the application would definitely be rejected, somewhere that if alternative recovery methods were provided, it would be missed.

At first we decided not to implement this button at all, because we saw no point in it at all. Then they found a couple of very borderline cases where it could have worked, so the question remained open.

A very borderline case: the user launched a transaction, but for some reason the check failed to be validated. If the user remains with the same device, the application in the background will request re-validation. If the user changes the device, re-validation will not automatically start: in this case, the Restore purchases button will help to start it.

Contact support

Having collected several such ambiguous questions, we, like naive simpletons, went to write to the store support. iOS support seemed to promise to be useful: two free requests from the developer account, the next ones for a few dollars, a response within three days!

They answered us via a week and a half by the following letter:

In short: send your application for review, and we’ll see. We decided not to lose heart and write a letter in support of Android – even though Android and iOS position themselves as completely different platforms, through seven days We received a surprisingly similar response:

Thus, attempts to spread straw were in vain. We were asked to go straight into battle.

Our solutions

We solved the Paywall case quite simply: we added a Log out button to the screen. So we closed both requirements:

1. Registered users were not allowed to go beyond the paywall.

2. They left the option to log out and return to free content.

For Restore purchases, we decided to do things a little differently: we implemented a button, but hid it in the first build to check whether reviewers would let us through or not.

Spoiler: the iOS build passed review almost the first time! What does “almost” mean: the first time we were fired for a broken link to the Privacy Policy – an annoying bug. But otherwise, the reviewers had no comments on the assembly.

In fact, we are not fully aware of the review process, so there is a possibility that the reviewers saw the necessary methods for Restore purchases in the code, and based on this they skipped the build, not paying attention to the fact that the button is hidden in the UI.

Legal blockers

However, if the regulation of stores was an expected obstacle on our way, then the legal hassle that we had to face was not.

Google Play

Settings Payment profile in Google Play Console took a total of month and three days. It was an iterative process: the store requested documents, the customer’s lawyers sent them, then waited for the review and request for the next portion.

Without this setup, we could not launch products in the store; therefore, the development team was doing layout all this time and trying to blindly answer technical questions about the flow.

After we unlocked the Payment profile, we were able to create products in the store. But in order for the created products to come into the application, we also needed access to release test assemblies in internal testing. To do this, it was necessary to add a bunch of information to the store and also wait for a review – this took another 26 days.

App Store

There’s an interesting situation here: overall, we blocked less. But we couldn’t accept the Paid Applications Agreement not because of legal problems, but because of an Apple bug: the agreement acceptance button on the screen was disabled and we waited two weeks, Until the bug is fixed!

Conclusion

What conclusions can be drawn from the first part of our incredibly exciting and no less stressful adventure?

1. Make sure you really need to implement IAP
   You may be lucky and your app qualifies as a “Reader” app. Or it is designed for the Russian market and RuStore monetization will be a more suitable choice.

2. Make sure designers are familiar with the guidelines. There are quite a lot of requirements for IAP from an interface point of view, so it will be great if the design is created immediately taking them into account.

3. Don’t count on store support. Well, no comments here.

4. Get started on a feature as early as possible
   Not only is it difficult in itself, but it also has a lot of surprises from unexpected sides.

5. Get lawyers on your stories as soon as you find blockers in this area
   I’m actually not sure if it’s really a universal pain. Colleagues from other projects said that they did not have such legal problems. Here it is quite difficult for me to predict whether problems will arise specifically on your project, because the legal work is carried out by the customer and the development team is not particularly allowed there. In any case, try to get to the stores as early as possible and detect blockers from the legal side in order to solve them quickly.

6. Request access to App Store Connect and Google Play Console
   This conclusion to some extent follows from the previous one. I took care of this task too late, although it would have greatly helped save time, because a lot depends on the stores in this feature and you have to go there often.

In the next article we will look at the difficulties in the technical implementation of IAP.

More interesting content for developers → Telegram channel Surf BA Team

PS There we publish cases, best practices, news and Surf vacancies, and also conduct live broadcasts.