Powstania Warszawskiego 15
31-539 Kraków
Before a line of code is written, the store rules have already decided how much of every payment you keep. Get the model right and a booking business pays the stores nothing. Get it wrong and a subscription hands over 30 percent it did not have to. There are really only two ways to collect money in an app, and which one you are allowed to use is decided for you. Here is how that works, without the developer jargon.
July 28, 20267 min readThe store's own payment system, on Apple and Google alike. Mandatory for anything digital your app sells: subscriptions, premium features, content.
A payment provider for everything the store's system must not touch: real world services, bookings, physical goods.
Both app stores apply the same one test to every payment in every app: where is the thing being consumed? If it is consumed on the phone, the payment must go through the store's billing. If it is consumed in the physical world, the payment must stay out of the store's system entirely. Apple's version of this rule is the stricter one, so the article works through Apple first and then shows where Google differs.
That single test sorts almost every business model. A subscription to workout videos is consumed on the phone, so it is in app purchase. A haircut, a training session, a delivered meal, a cleaning visit, all of these are consumed in the real world, so they are paid through a provider like Stripe and Apple takes nothing. Not because Apple is being generous, but because its own guideline 3.1.5(a) forbids using in app purchase for physical goods and services.
So before anyone debates tools, write down what your app charges money for. Each item on that list already has its payment path assigned by the guidelines. The tools follow.
Guideline 3.1.1 is the one that gets apps rejected. Any digital content, feature, or subscription sold inside the app must use Apple's in app purchase system. Routing a premium tier through your own checkout is among the most common rejection reasons in App Review.
The commission is less brutal than the headline 30 percent, if you use the mechanics:
One recent shift worth knowing: since a 2025 US court ruling, apps on the US storefront may link out to a web checkout for digital purchases. On most other storefronts the classic rules still apply. For a US heavy audience this opens a real alternative, at the cost of extra product work, so it is a scoping decision rather than a default.
Everything Apple's system is forbidden to touch runs through a standard payment provider, and in mobile projects that provider is usually Stripe. Bookings, marketplace transactions, payouts to service providers, refunds for cancelled appointments. When we built Evesport, a personal trainer booking platform, all of the payment engineering lived here: charging clients for sessions, paying trainers out, handling cancellations. Apple's commission never entered the picture.
There is one exception that surprises even experienced teams. Guideline 3.1.3(d) allows realtime one to one services between two individuals, and Apple's own examples include tutoring, medical consultations, and fitness training, to be paid outside in app purchase. A live video session between one coach and one client can go through Stripe, commission free. The same session streamed to a group cannot. One sentence in the guidelines, a 15 to 30 percent margin difference.
Those two options, in app purchase and Stripe, are the whole picture for how money enters an app. There is no third one hiding here. But if your business model runs on subscriptions, there is a tool worth recommending on top of in app purchase, and it is the one thing we tell almost every subscription client to use: RevenueCat.
RevenueCat does not move money and does not replace either payment path. It sits on top of the store billing and handles the machinery around subscriptions: validating receipts, knowing whether a given user is currently entitled to premium, keeping that answer identical across iOS and Android, subscription analytics, and paywall testing. Building all of that yourself is weeks of unglamorous engineering that every subscription app needs and no user ever sees, and it does not change what the store charges either way.
It slots cleanly into either stack we build in, whether that is a Flutter app or a React Native one, so the recommendation holds regardless of the technology. If your app has no subscriptions, you can skip it entirely: it solves a problem you do not have.
Put together, the choice between the two options is mostly made for you by your business model:
Everything above is framed around Apple because Apple's rules are stricter and its review is where teams get caught. Google Play applies the same core test, digital goods go through its billing, real world services stay outside it, but the numbers changed materially in 2026 and are worth knowing before you model revenue.
As of a June 2026 change in the US, UK, and European Economic Area, Google separated its charge into two parts: a service fee that applies no matter how you collect payment, and a billing fee that only applies if you use Google's own billing. For subscriptions the service fee is 10 percent, and Google's billing adds 5 percent on top, so most subscription apps still land at 15 percent, the same effective rate as before. The difference is that you can now route payment through your own checkout or a web link and skip that 5 percent, paying your processor instead.
Whether that saves money depends entirely on transaction size. On a small monthly plan, a card processor's fixed per transaction fee eats most of the 5 percent you saved. On a large annual renewal, the processor's percentage comes in under 5 percent and you keep the difference. So the honest answer for a prospect is that Android's lower headline rate is real, but it only shows up in your accounts on higher value transactions, and it is a decision to make per product rather than a blanket win.
No. Payments for services delivered in the physical world must be processed outside Apple's system, and Apple takes no commission on them. The 30 percent applies to digital content and features only.
Not inside the app on most storefronts. Digital subscriptions sold in the app must use in app purchase. The US storefront allows linking out to a web checkout since 2025, and subscriptions sold on your website have always been yours to process with Stripe.
No. Apple's StoreKit is enough on its own. RevenueCat replaces the custom backend work around subscriptions, which is why it earns its place on subscription products and adds little on apps without them.
The core logic is identical: digital goods through Google's billing, real world services outside it. The numbers differ. Since a June 2026 change in the US, UK, and EEA, Google splits its charge into a 10 percent service fee on subscriptions plus a 5 percent billing fee if you use Google's billing, so most apps still pay about 15 percent. Route payment through your own checkout and you skip the 5 percent, which pays off mainly on larger transactions.
It rarely comes down to fees. Launch where your users are. The fee difference between the two only becomes a real number at scale or on high value transactions, so for a first version it is not the deciding factor. What matters more is that your payment model is clean on whichever store you submit to first, because that is where a rejection would cost you a launch date.
Co-Founder and CEO, Apps Value
Thomas takes the first call on most Apps Value projects. He spends it working out what your operation actually needs, what belongs in version one and what does not, and whether building anything is the right move yet. If it is not, he will tell you on that call. If it is, you get a written scope and a fixed price before a line of code exists.
Tell us what your app will charge money for. We will tell you which payments run through Apple, which go through Stripe, whether RevenueCat belongs in the build, and what all of it does to your numbers.
Book an intro call30 minutes, no preparation needed.