In-App Purchase vs Web Payment: How Apple and Google Commission Works

If your app sells digital content or subscriptions, you face a key decision when you set up payments: use in-app purchase or send users to a web payment page instead. In practice, this choice is not just a technical detail, it shapes your commission cost and your checkout experience at the same time. In our experience, Talha Aslan and the team see founders face this exact decision on almost every commerce-focused mobile app project. We break down the rule, the commission logic, and the right fit for your business model, based on Apple's and Google's official developer guidelines. In short, by the end you will have a short decision checklist you can apply to your own app.

For example, game currency, premium feature unlocks, digital gift cards, and most subscription tiers fall into this category. The user pays with a single tap, often confirmed by Face ID or a fingerprint, and never re-enters card details. In other words, this smooth flow tends to raise conversion rates. But you still need to build the commission into your pricing from day one.

This path also builds trust quickly, because the user's card number never touches your own servers. In exchange, you give up direct control over the collection process and depend on the platform's own payout schedule. Plan your cash flow around that schedule instead of around same-day settlement.

How Does Web Payment Work for Mobile Apps?

With web payment, you send the user to a browser, where they enter card details through your own payment stack, for example a payment gateway you picked yourself. Here, Apple's and Google's commission never enters this flow. So you collect the full amount yourself. In exchange, the user leaves your app for a moment, and that single extra step can cause some users to abandon checkout.

For instance, a commerce app that ships physical goods, or a service app that takes bookings, usually relies on this route. Digital content is not always free to sell this way, and the next section explains exactly where Apple and Google draw that line. Above all, this handoff creates a friction point in the user journey. So design the payment page for speed and for visible trust signals.

Pick your payment gateway carefully: compare transaction fees, refund handling, and fraud protection before you commit. Consequently, these factors decide whether the commission savings actually turn into real net profit. Choose a provider with proven, current anti-fraud tooling, since weak protection can erase any commission advantage you gained.

Why Do Apple and Google Require In-App Purchase?

Apple's official App Store Review Guidelines (currently guideline 3.1.1) require in-app purchase for any purchase that unlocks a feature or content inside your app. For example, game levels, premium features, and digital gift cards all fall under this rule. Apple frames this requirement around its secure payment stack, centralized refund handling, and cross-device subscription sync.

Google Play works on a similar principle: apps that sell digital goods or services must use Google Play Billing, and that use carries a service fee. Still, guideline numbers and policy text can change over time. So always check the current wording on the official developer page before you build your flow.

Specifically, both platforms defend this rule on the grounds of user trust and payment integrity. Yet both also carve out exceptions by app category. Read the general principle. Then check the specific clause for your own app category, because a wrong assumption at this stage can force a costly rebuild later.

Which Apps Must Use In-App Purchase?

Put simply, the rule mainly covers digital content and features that a user consumes inside your app. In practice, comparing your own app against this short list speeds up your decision.

• In-game currency, extra levels, or character unlocks.
• Premium feature unlocks bought from inside the app.
• Most subscription-based digital services (content, tools, personalization).
• Digital gift cards, coupons, and certificates.

Anything outside this list that a user consumes outside the app falls into a separate category, which the next section covers in detail. Pin down where your own app sits on this list first, since that single decision shapes your whole payment architecture. Walk through every uncertain feature against the official examples one by one rather than guessing.

Review this list together with your product team. Mark each feature one by one. Write down clearly which features fall under the mandatory scope. This short exercise saves you from a costly mix-up once development starts.

Why Are Physical Goods and Services Exempt From This Rule?

Specifically, Apple's guidelines (clause 3.1.3(e)) ask you to use Apple Pay or standard card entry, not in-app purchase, for any physical good or service a user consumes outside the app. Put simply, the logic is simple: the user consumes the product or service in the real world, not on the screen. So it does not depend on the platform's digital infrastructure.

If you sell clothing through a commerce app, or you take hair salon bookings through a service app, you can collect payment through your own payment gateway. Likewise, Apple also grants a similar exception for one-to-one personal services; group services can fall under a different clause. So confirm the current boundary on the official page.

Ask yourself one simple question for every mixed case: does the user finish the experience inside the app screen, or out in the real world? That answer usually points to the right path on its own. If you sell both digital content and physical goods in one app, you may need two separate payment flows, one for each category.

What Is the Commission Difference Between In-App Purchase and Web Payment?

First, with in-app purchase, the platform deducts a commission from the amount it collects and sends you the rest. With web payment, no platform commission applies. Instead you pay your own payment gateway's transaction fee. Check the current commission rate on Apple's and Google's official developer pages, since the rate varies by developer, revenue level, and program.

Above all, re-check every row of this table against your own product mix as it grows. Weigh the commission gap against user experience and operational load, not just the raw percentage, and you will land on a more balanced decision. Print this comparison and revisit it each time you add a new product type.

How Do Small Business Programs Affect Your Commission Rate?

Apple's small business program offers a reduced commission tier to developers who stay under a yearly revenue threshold, or who join the platform for the first time. Additionally, both the threshold and the reduced rate can change. So check current eligibility and the current rate on the official page rather than relying on a fixed number.

Likewise, Google Play runs a similarly tiered structure, where joining specific programs or reaching a certain revenue level can shift your service fee tier. On both platforms, you apply for these programs yourself from your developer account, the system never enrolls you automatically.

Once a platform approves your application, the reduced tier usually kicks in from the next billing cycle. So plan the transition early. Also factor in that you return to the standard rate once you cross the revenue threshold, which keeps your budget free of year-end surprises.

How Does Google Play's Service Fee Tier Work?

According to Google Play's official help page, in-app products sold through Google Play Billing or an alternative billing system carry a service fee. Google also offers a lower fee tier to developers who join certain programs.

Physical goods and services generally sit outside this service fee's scope. But read Google's payments policy to confirm the exact boundary for your own app. Meanwhile, Google updates this scope from time to time. So recheck whether the fee applies every time you add a new product category.

In practice, review your billing reports inside the Google Play Console on a regular basis. Check the service fee deduction every month. If you spot an unexpected change, check the official policy page first. Then contact developer support if the question remains open.

Finally, talk to your accountant about how this commission flows through your books and your tax filing. This article offers general guidance only, not tax or legal advice.

When Can You Link to External Payment Options?

Regulatory decisions in some countries and regions now let apps partly direct users to a payment page outside the app. In other words, this permission does not work the same way everywhere, and in some cases you need a specific entitlement from the platform first.

Confirm the current rule for your target region on the official developer page before you rely on this option in your own app. Above all, a misleading redirect, or any setup that tricks the user into an external link, carries a real risk of removal from the store.

If your app ships in more than one country, run a separate compliance check for each region. A flow approved in one storefront does not automatically carry over to every other storefront. Review this topic early with your legal and developer relations team whenever you plan to expand into a new market.

Does the Subscription Commission Change Over Time?

Yes, on most subscription models the commission rate can drop once a user keeps an active subscription for a set period without interruption. Consequently, this reduction applies automatically, you never need to file a separate request, though the exact period and rate differ between platforms.

Factor this time-based shift into your subscription pricing, since it makes your long-term profitability projection far more realistic. Example scenario: your net revenue from a long-time subscriber can run higher than from a brand-new signup. So confirm the current threshold and rate on the official page before you build a model around it.

If a user cancels and later restarts their subscription, the commission tier can reset. In practice, understanding this cycle helps you shape your retention strategy and your pricing model together, rather than treating them as separate projects.

Who Qualifies for the Reader App Exception?

Apple grants a separate exception to "reader" apps that give access to content the user already bought elsewhere, such as books, magazines, newspapers, music, audio, and video. These apps can include an informational link to your own website for account creation or account management.

That said, this exception stays narrow, and not every content type automatically qualifies. Read Apple's official review guidelines before you design your purchase flow. So you can confirm whether your own app actually fits this exception.

If you run a news, media, or content platform, a wrong read of this exception's limits can trigger a rejection during review. Instead, study how similar, already-approved apps in your category handle this flow before you launch your own version.

In-App Purchase or Web Payment: Which Should You Choose?

The right choice depends on what you sell, your audience's payment habits, and your growth goal. The table below compares both paths by business model.

Still, even when the rule does not force your hand, a smoother checkout can sometimes outweigh the commission cost. So judge the decision on conversion rate as well as on cost alone. Revisit this same table whenever your business model shifts, since the right answer can change along with it.

What Are the Risks of Violating This Rule?

Above all, a payment flow that breaks platform rules can lead to rejection during review, or removal of a live app from the store. That single outcome can cost you both revenue and user trust at the same time.

• Quietly routing content that should sell in-app out to the web instead.
• Building a misleading or hidden external payment link.
• Using an entitlement-gated redirect without actual authorization.

Trying to game the system with a rule-breaking method might save commission in the short term. But it risks your entire account or app in the long run. In practice, verify every unclear point against the official source before you ship it to production.

As your team grows and your payment flow gets more complex, build a standing habit of re-checking the relevant rules before every release. That habit catches similar risks early, well before they reach your full user base.

How Do You Build Commission Cost Into Your Pricing?

Rather than subtracting commission from your net margin after the fact, bake it into your price from the start, that approach gives you a far healthier model. First, pull the current rate from the official page and plug it into your own financial model. So your pricing decision reflects reality.

If you plan to cut commission by switching to web payment, also add the checkout friction and the possible conversion drop to your model. That lets you compare both paths side by side, under the same assumptions.

Example scenario: if your app earns recurring monthly revenue from digital content, track your net figure after commission alongside your marketing budget. So you can see the real return on your ad spend. Repeat this calculation on a regular schedule with the current rate, and your budget planning stays solid.

In other words, treat your price as a living number rather than a one-time decision. First, market conditions shift. Watch competitor pricing too. Reading all three signals together keeps your price genuinely accurate.

Can You Use a Hybrid Model: Show Price In-App, Sell on the Web?

In some cases you can display a price inside the app while you still collect payment through the web. But you must build this flow to match platform rules. Otherwise reviewers can flag it as a misleading redirect. The reader exception, or a region-specific entitlement, forms the legal basis for this hybrid setup.

First, before you build a hybrid flow, read Apple's and Google's current rules side by side, and design one flow that satisfies both platforms at once. A method one platform approves can still get rejected on the other.

Next, test the hybrid flow with a small user group first. Keep the group active through at least one review cycle. Second, log every piece of feedback. Skip this step and you risk finding the same problem later, in front of a far larger audience.

When Should You Plan Your Payment Model During App Development?

Decide your payment model during project planning, before you lock down the app's architecture. Otherwise a mid-development payment change costs you both time and budget. This choice ranks among the items that shape what determines mobile app development cost.

While you settle this decision, weigh app store optimization, user acquisition cost, and your long-term growth goal together; we cover this angle in our app store optimization (ASO) guide. If you need hands-on support, our mobile app development service helps you build a payment flow that matches platform rules from day one.

First, open a "payment model" section in your planning document. Write down which product sells through which path. Then, share this document with your developers early. That way everyone works from the same page before a single line of code gets written.

Does Native vs Cross-Platform Affect Payment Integration?

Yes, to some extent. In practice, payment library integration can feel easier or harder depending on your platform choice, a topic we compare in our native vs cross-platform guide. If your product also works as a Progressive Web App (PWA), the whole payment equation can change, an alternative we cover in our mobile app vs PWA comparison.

If a store rejects or removes your app, your payment flow goes dark along with it, a risk we detail in our most common app rejection reasons guide. Use our ROAS calculator to compare your net revenue after commission against your marketing spend, and our VAT calculator once you need to add tax to your price.

Above all, don't pick a tech stack purely on build speed. Also think about the long-term upkeep of your payment integration too. Every platform update can force a library update on your side. Planning for that upkeep up front saves you real time later.

Quick Decision Guide: Which Payment Method Should You Choose?

Put simply, naming one clear winner would be wrong, since the right path depends on what you actually sell. Work through these short steps in order to reach your own decision.

1. Decide whether what you sell gets consumed inside the app or outside it.
2. If it is digital content, check Apple's and Google's current mandatory rules on the official page.
3. Pull the current commission rate, and any small business tier, from the official developer page.
4. Build the commission cost into your pricing and your ROAS math.
5. Confirm separately whether external payment links apply in your target regions.
6. Review your decision once more, weighing both cost and user experience.

Finally, repeat these steps at every budget cycle. So your decision stays aligned with current rules and current rates. When you hit an unclear point, go back to the official source, that habit is the safest long-term approach. Our team plans this decision with clients early in a project, to cut both technical and business risk at the same time.

Above all, don't treat this guide as a one-time read. Repeat the same steps for every new feature or new market decision. Next, update your checklist whenever the rules change. That keeps your decision-making process current and solid at all times.

Finally, write your decision down in a short internal document. Note which product sells through which method, which source you checked, and the date you checked it. That small habit makes team communication easier, and gives you a ready answer whenever an audit or a partner asks.