In-app payments open up all sorts of monetization possibilities for app-based businesses, from setting up subscription payments to unlocking exclusive content.
If your business is looking to implement in-app payment processing, you need to do so in a way that gives you the freedom to optimize user experience and limit the impact of commission, while still complying with app store guidelines.
In this article, we explain the different types of in-app purchases, how they differ from Apple Pay and Google Pay, the benefits and drawbacks, how the EU’s Digital Markets Act could impact the future of in-app payments, and where our Frames Mobile SDKs can help.
In-app payment processing allows merchants to take payments from users for goods and services directly from within a mobile application. Users simply enter their payment details on a secure in-app checkout, meaning they don’t have to leave the app to complete their purchase.
To enable in-app payment processing, merchants need to integrate mobile payments technology through a backend integration with a payments provider. However, they also need to make sure to comply with any rules and guidelines stipulated by Apple or Google’s app store platforms, depending on the type of in-app purchase. Below we lay out the different types of in-app purchases and the options you have to process each of them.
In-app payment processing allows for a number of types of purchases, including:
Because they all rely on digital devices to initiate a transaction, people often think in-app purchases and digital wallet payments, like Apple Pay or Google Pay, are the same thing.
However, they are completely different and involve different parties, functions and fee structures.
Let’s look at in-app purchases first. When a user downloads your paid app from the Apple App store, they will make the purchase by adding their card details to their Apple account. This purchase, as well as any subsequent in-app purchases, are processed by Apple and happen entirely within the Apple ecosystem, with no need for involvement from a third party.
As a result, Apple usually takes a 30% cut (or 15% depending on your in-app revenue and length of service) from any in-app purchase made using a card stored in its system. So, for example, if the user spends $10 in your app, you will receive $7 and Apple will take $3. The Google Play Store charges similar fees.
Now let’s look at digital wallet payments (like Apple Pay and Google Pay), which are designed to securely store payment card information on these wallets. When a user makes an online or in-app payment using their digital wallet, the card details are shared with a third-party payment processor. This means that, in contrast to in-app payments, app stores like Apple’s App Store or the Google Play Store do not benefit financially from the transaction.
You can think of in-app payments as a category of mobile payments, compared to Apple Pay and Google Pay as payment methods for multiple categories of payments.
By enabling in-app payments, merchants stand to benefit from:
However, there are some drawbacks you should consider when deciding whether or not in-app payments are right for your business.
The main downside is the substantial commission charged for native in-app payments. If your business makes more than $1 million in annual net app revenue on both the Apple App Store and Google Play Store, the commission is usually 30% of that revenue.
However, if you make less than $1 million in annual net app revenue or if you’re a subscription-based app that’s been in service for over 12 months, the corresponding fee is 15% of your revenue, which will apply to most app developers.
On both stores, this fee is tiered so that the 15% commission applies for the first $1 million in revenue within a calendar year. If you surpass $1 million, the 30% rate applies for the rest of that year, and if your revenue falls back below $1 million in the following calendar year, you will re-qualify for the 15% rate.
Another drawback is a lack of flexibility that you’d get from direct integration with a PSP like Checkout.com. You might require additional flexibility for in-app payments, such as offering alternative payment methods beyond Apple Pay or Google Pay, which is currently limited.
If you implement in-app purchases on iOS, you will be bound by Apple’s App Store guidelines. If you fail to meet these guidelines, you could be banned from the App Store, so we would strongly recommend doing your due diligence to understand how these could either restrict or affect the way you conduct business. The same applies to Google and their Play Store guidelines for payments.
The main thing to be aware of is that Apple or Google may require you to use their own In-App Purchase (IAP) mechanisms for purchases that unlock features or functionality within your app, including:
That means you cannot offer your users alternative ways - such as license keys, augmented reality markers, payment link QR codes, or cryptocurrencies - to unlock content. Apple and Google also tend to reject apps on the basis of including buttons, external links, or CTAs that direct users to alternative purchasing methods outside the app. Remember, that means you’ll be paying at least a 15% commission on any such purchases.
However, there are some exceptions. The following apps can offer alternative purchase methods as long as this is communicated to users outside the app.
The EU’s Digital Markets Act (DMA) came into force in November 2022. It aims to encourage fairness and competition in the EU’s digital sector by curbing the power of large digital companies that offer intermediary services, known as ‘gatekeepers’.
Due to their size, Apple and Alphabet (Google’s parent company) are examples of gatekeepers that fall under the scope of the DMA. When it comes to payments, the DMA prevents gatekeepers from requiring app developers to use particular payment systems and meet certain conditions to be featured on their respective app stores. The DMA may also require gatekeepers to give app developers access to features such as near-field communication technology, secure elements and processors, and authentication mechanisms.
Essentially, this new regulation raises the possibility that merchants could use third-party payment services when trading on gatekeepers’ platforms. This would give them more control over aspects of payments like acceptance rates, costs, settlement times, payment methods, and customer experience. Gatekeepers must have implemented the relevant measures to comply with the DMA by March 6, 2024, latest.
In October 2023, one of the EU’s antitrust watchdogs, the Dutch Authority for Consumers & Markets (ACM), ruled that Apple’s commission on certain app subscriptions in the App Store, violates the bloc’s antitrust rules.
The ACM ruling stated that such charges unfairly targeted subscription services with an “inexplicably higher fee” in comparison to apps that don’t offer paid digital content. It remains to be seen whether Apple will challenge the decision or reform its commission structure. However, the ruling could pave the way for the EU and its 27 members to scrutinize the fairness of gatekeepers’ app store fees further.
Beyond that, the ongoing Epic vs. Google case is also drawing a lot of attention to how in-app payments work for merchants today, and the high commission fees many are having to pay.
With Checkout.com’s native mobile SDKs (our Frames SDKs), you can process payments made in apps that don’t fall under Apple and Google’s IAP guidelines. For subscription payments, purchasing in-game currencies and payments to unlock game levels, premium content or full app versions, you must use the app stores’ native solutions to meet the terms and conditions, but outside of this, you can use the Frames SDKs.
However, there are other use cases, such as for multiplatform or person-to-person services where you can use our Frames SDKs for a direct integration with Checkout.com.
Given the DMA is coming into force in March 2024, this could mean that in the future merchants would have more choice and be able to use solutions such as Checkout.com’s Frames SDKs, or other mobile payment solutions, to support more in-app payment use cases.
To take non-IAP payments, all you need to do is integrate the Frames SDK into your app’s source code and display the payment forms Checkout.com provides to start taking payments in your mobile apps. Checkout.com’s Frames SDKs offer multiple levels of customization, so you can tailor in-app payments to your exact requirements, compliant with the latest PCI DSS.
Just always make sure you do your due diligence on how to implement in-app payments in compliance with app stores’ guidelines. Chat to a team member to learn more about in-app payments with Checkout.com.