Store Billing, Web Checkout and Shifting Rules: What App Founders Should Design For

Ask a room of founders what Apple and Google take from in-app sales and most will say "30 percent" without hesitation. That answer is a reasonable starting point. It is also incomplete, and in some markets it is increasingly out of date.

Store payment rules now depend on which store, which country, what you are selling and sometimes how large your business is. They have shifted through court rulings and regulation, and they are still moving.

This piece is not legal advice, and nothing here should replace checking current store policy and talking to a lawyer before you build your payment flow. What it offers is the engineering and product view: what to design for so your app can adapt as the rules change.

The baseline most people know

For digital goods sold inside an app, both major stores have long charged a standard commission, commonly 30 percent. Reduced rates, typically around 15 percent, have applied to smaller developers enrolled in the stores' programmes and, in many cases, to subscriptions after their first year.

That fee alone can decide whether a model works. A subscription priced with thin margins in mind can look very different once roughly a third of the price may go to the store.

What has been changing

Two broad developments have opened up options in some places.

In the United States, court rulings have required more freedom for developers to direct users to external purchase options.

In the European Union, the Digital Markets Act has introduced alternative distribution and payment arrangements, which come with their own fee structures and conditions.

The details differ between Apple and Google and between countries, and they have been revised more than once. That is exactly the point: anything you hard-code today may need to change.

What you sell matters more than people think

Before worrying about the latest ruling, sort what your app sells into the right bucket. As a general pattern:

• Physical goods and real-world services such as food delivery, ride-hailing, retail and bookings generally use ordinary payment processors rather than store billing.
• Digital goods consumed inside the app, such as premium features, content or AI credits, generally require store billing unless a specific exception or market rule applies.
• Reader and multi-platform apps may have more flexibility in how people sign up and pay.
• B2B apps often sell accounts entirely outside the app, with the mobile client included in a web-billed subscription, which sidesteps much of the question.

Many founders discover they are in a different bucket from the one they assumed, and that changes the whole fee picture.

Design principle one: abstract the payment layer

The single most useful architectural decision is to put every way of getting paid behind one interface.

Store billing on iOS, store billing on Android, and web checkout should all be adapters behind a common payment layer. Your product code asks "start a purchase for plan X" and does not care which rail completes it. When a market opens up web checkout, or a rule changes, you switch adapters per country rather than rewriting screens.

Design principle two: one entitlements service

Wherever someone paid, the question "what can this user access?" needs one answer.

A central entitlements service, fed by validated store receipts, store server notifications and your web payment provider, is that answer. Without it, a user who subscribed on the web and then logs in on an iPhone becomes a support ticket. With it, cross-platform access just works.

Design principle three: validate on the server

Never trust the client for purchase state. Validate store receipts server-side, and process the stores' server notifications for renewals, refunds, cancellations and billing problems. This protects revenue and keeps entitlements accurate when something changes outside the app.

Design principle four: configure, do not hard-code

Where checkout links appear, which markets see them, which prices apply and how paywalls behave should all live in remote configuration. Rules shift; your release cycle should not be the bottleneck in responding.

Model the fees before you set prices

When you plan pricing, run the numbers under several scenarios rather than one: standard commission, reduced-rate programme, web checkout in eligible markets, and B2B sales outside the app. Treating the store fee as a fixed constant is one of the more expensive monetization mistakes, both because it can make a viable model look unviable and because it can hide an opportunity.

Remember too that web checkout is not free. Payment processor fees, tax handling, fraud and a less familiar purchase flow for users all have costs. The right answer is often a mix that differs by market.

The short version

Know which bucket your product sits in. Abstract payments. Centralise entitlements. Validate on the server. Keep rules in configuration. And check current policy, with legal advice, before committing.

For the full picture, including subscriptions, freemium, in-app purchases, ads and how AI costs change pricing, read the full guide on TechCirkle. Our mobile app development team builds this payment architecture into apps from the first sprint.

Frequently Asked Questions

How much do app stores charge on in-app purchases?

The standard commission on digital goods has commonly been 30 percent, with reduced rates of around 15 percent for qualifying smaller developers and many subscriptions after the first year. Check current policy, as terms change.

Can apps link users to web checkout?

In some markets and situations, yes. US court rulings and the EU's Digital Markets Act have opened options, but conditions differ by store and country and continue to evolve. Take legal advice first.

Do physical goods need to use in-app purchase?

Generally not. Physical goods and real-world services typically use standard payment processors. Store billing rules mainly apply to digital goods consumed in the app.

What is a payment abstraction layer?

A common interface in your app's architecture that sits in front of store billing and web checkout, so you can switch payment methods per market without rewriting product code.

Why do apps need an entitlements service?

To give one consistent answer about what each user can access, regardless of whether they paid on iOS, Android or the web.

Is web checkout always cheaper than store billing?

Not necessarily. Processor fees, tax handling, fraud prevention and potentially lower conversion all add cost, so model each scenario before deciding.